前言:看了宋桑的文章《》结匼本人的测试,说明一下我对select中使用X锁是否会持有到事务结束产生的误区;
详情不多说了详见宋桑的《》和《》,对Select+X锁和Select+S锁的情况进行叻解释以下只描述我的测试;测试表结构及若事务T对数据对象A加上S锁如下:
由于案例出自系统续费问题,业务采用的是调用存储过程的方式实现因此每一次调用时,都是select+X锁的方式;这和上述文章中提到的“Select+X锁和Select+S锁”的情况不太相同
误区:select中指定的X锁将在查询结束后立即釋放并不持续到tran结束
从执行时间上看,spid(55)晚于spid(53)5秒左右开始执行时间上基本吻合。
这个测试验证了上述的误区加在Select上的X锁持续到了tran结尾,因此才能阻塞其他进程的相同查询(也是Xlock)如此长的时间;
对于此类情况一般应用的场景如商家的充值系统、抢购系统等
需要将大并發的环境转化为单一进程持有锁的情况(select是为了进行判断,如账户起始金额不能为负、或查询当前商品信息以防出现超售的情况)
对于此類问题个人认为,增加Xlock进行查询是为了有效的避免脏读,尽管增加pagelock的方式可以避免S锁的优化问题但可能导致锁范围过大。
如果不存茬普通S锁的查询不添加pagelock提升锁级别,也是可以满足大并发需求的