With(ReadPast)就不会被阻塞吗？

在生产环境中，会有很多使用ReadPast查询提示的场合，来避免正在被其它事务锁定的行对当前查询造成阻塞，而又不会获取到“脏数据”。

可是很多人都疑惑，为什么我使用了ReadPast仍然有时会被阻塞？

首先我们找到联机帮助：

READPAST

指定数据库引擎不读取由其他事务锁定的行。如果指定了 READPAST，将跳过行级锁。也就是说，数据库引擎将跳过这些行，而不是阻塞当前事务直到锁被释放。例如，假设表 T1 包含一个单精度整数列，其值为 1、2、3、4 和 5。如果事务 A 将值 3 更改为 8，但尚未提交，则 SELECT * FROM T1 (READPAST) 将生成值 1、2、4 和 5。使用 SQL Server 表实现工作队列时，READPAST 主要用于减少锁定争用。使用 READPAST 的队列读取器会跳过被其他事务锁定的队列项，跳至下一个可用的队列项，而不是等待其他事务释放锁。

一切看起来都很美好，但是请看如下场景：

表名[IP]，聚集索引字段：BIP

会话一：

BEGIN TRANSELECT * FROM ip WITH(XLOCK) WHERE BIP='1.10.8.0'

然后去会话二，执行：

SELECT * FROM ip WITH(READPAST)

发现会话二被阻塞了

Why？

我们通过系统视图sys.dm_tran_locks来看看发生了什么：

SELECT request_session_id, resource_type,     request_status, request_mode,    resource_description, object_name(p.object_id) as object_name,p.index_idFROM sys.dm_tran_locks left join sys.partitions pon sys.dm_tran_locks.resource_associated_entity_id = p.hobt_id

上图中可以看到，会话二(ID61)中的select妄图获取page(1:23952)上的S共享锁，却被会话一(ID56)在该page上的IX意向排它锁给拦住了

为什么？说好的会跳过其它事务锁定的行呢？

“等等，你刚才说的最后一个字是什么？”

“呢”？

“不是，再上一个！“

”行“？

”对了！“

指定数据库引擎不读取由其他事务锁定的行。如果指定了 READPAST，将跳过行级锁。

在会话二中，我们使用了select * ，并且没有where条件，执行计划会使用聚集索引扫描：

扫描意味着什么？在每个扫描过的page上都会加S共享锁！！

而，如果指定where条件，并且执行计划是聚集索引查找的话，则只会在所查找的页面上获取IS意向共享锁!

（该查询返回空结果集）

知道了以上区别，我们再来看看SQLServer锁兼容图表：

再来回想一下整个过程，在会话一中，我们使用XLOCK提示，使得SQLServer获取了一个Page上的意向排它锁IX，并且保持事务。

在会话二中我们使用了聚集索引扫描的查询计划，使得在每一个页面上都会申请S共享锁，从上面的图红圈处可见，S是与IX互斥的，故该查询会被阻塞，而指定了where条件的查询，申请的是page上的IS意向共享锁，上面图绿圈处可见，IS与IX是不冲突的，故不会被阻塞。

说到这里，我有想起了锁提示ROWLOCK，联机丛书解释如下：

ROWLOCK

指定通常采用页锁或表锁时，采用行锁。在从 SNAPSHOT 隔离级别操作的事务中指定时，除非将 ROWLOCK 与需要锁的其他表提示（例如，UPDLOCK 和 HOLDLOCK）组合，否则不会取得行锁。

听这解释，貌似可以解决我们上面说的阻塞的问题啊，那让我们来试一下：

SELECT * FROM ip WITH(ROWLOCK)

果然可以！！

我们看一下这个查询提示获取的是什么锁：

噢！它获取的是PAGE上的意向共享锁，和指定where条件时在查找的页上获取的锁是相同的，所以没有被阻塞！

总结：

SQLServer每个阻塞都是有原因的，瞬间的、少量的阻塞并不是不可原谅的，在高并发的系统中都是正常的，但是频繁的，长时间的阻塞（个人认为200ms以上都是值得注意的），就应该引起DBA的重视，搞清楚原因是什么。阻塞源没有尽快完成事务的原因多种多样，可能是事务内的的语句效率问题，可能是程序端调用时出现了交互或者中途错误、可能是数据库服务器系统资源出了问题。

总之，DBA会一直和阻塞、死锁做着长期的、不懈的斗争。。。。。

转载于:https://www.cnblogs.com/zc_0101/p/3924982.html

With(ReadPast)就不会被阻塞吗？相关推荐

SQL with(unlock)与with(readpast) (转)
所有Select加 With (NoLock)解决阻塞死锁,在查询语句中使用 NOLOCK 和 READPAST 处理一个数据库死锁的异常时候,其中一个建议就是使用 NOLOCK 或者 READPA ...
SQL Server脏读方式数据提取---NOLOCK和READPAST
当对数据库中的数据进行读操作或修改时,数据库引擎使用专门的控制类型来保持数据库的完整性,称为锁机制.锁机制通过确保包含在一个事务中的数据库记录在该事务提交之前不能被其它事务修改来保证数据库的一致性. ...
SQL with(unlock)与with(readpast)
所有Select加 With (NoLock)解决阻塞死锁,在查询语句中使用 NOLOCK 和 READPAST 处理一个数据库死锁的异常时候,其中一个建议就是使用 NOLOCK 或者 READPAS ...
Redis 笔记（12）— 单线程架构（非阻塞 IO、多路复用）和多个异步线程
Redis 使用了单线程架构.非阻塞 I/O .多路复用模型来实现高性能的内存数据库服务.Redis 是单线程的.那么为什么说是单线程呢? Redis 在 Reactor 模型内开发了事件处理器,这个 ...
Redis 笔记（04）— list类型（作为消息队列使用、在列表头部添加元素、尾部删除元素、查看列表长度、遍历指定列表区间元素、获取指定区间列表元素、阻塞式获取列表元素）
Redis 的列表是链表而不是数组.这意味着 list 的插入和删除操作非常快,时间复杂度为 O(1),但是索引定位很慢,时间复杂度为 O(n). 当列表弹出了最后一个元素之后,该数据结构自动被删除, ...
同步与异步，阻塞与非阻塞的区别
1.概念剖析相信很多从事linux后台开发工作的都接触过同步&异步.阻塞&非阻塞这样的概念,也相信都曾经产生过误解,比如认为同步就是阻塞.异步就是非阻塞,下面我们先剖析下这几个概念分 ...
MySQL 5.6中如何定位DDL被阻塞的问题
在上一篇文章<MySQL 5.7中如何定位DDL被阻塞的问题>中,对于DDL被阻塞问题的定位,我们主要是基于MySQL 5.7新引入的performance_schema.metadata ...
Go 学习笔记（43）— Go 标准库之 os/exec（执行外部命令、非阻塞等待、阻塞等待、命令输出）
1. 概述 golang 下的 os/exec 包执行外部命令包执行外部命令.它包装了 os.StartProcess 函数以便更容易的修正输入和输出,使用管道连接I/O,以及作其它的一些调整. 与 ...
kafka实现异步发送_Kafka 异步消息也会阻塞？记一次 Dubbo 频繁超时排查过程
线上某服务 A 调用服务 B 接口完成一次交易,一次晚上的生产变更之后,系统监控发现服务 B 接口频繁超时,后续甚至返回线程池耗尽错误 Thread pool is EXHAUSTED.因为服务 B ...

With(ReadPast)就不会被阻塞吗？

With(ReadPast)就不会被阻塞吗？相关推荐

最新文章

热门文章