只读行可以触发数据库死锁吗？

Question

跟进https://stackoverflow.com/a/16553083/14731..。

我理解，为了减少死锁的频率，维护表的组成锁定顺序是很重要的，这影响到UPDATE和SELECT语句1。但是，对只读行是否同样有效？。

如果一个行在初始化时被填充了一次，而没有人再次修改它，那么我们访问它的顺序有什么关系吗？

给定两个事务: T1、T2和两个只读行( R1、R2 )

T1读取R1，R2 T2读取R2，然后R1

即使我使用SERIALIZABLE事务隔离，事务死锁也可以吗？

1如果事务隔离为REPEATABLE_READ、T1 SELECTs R1、R2，而T2 UPDATE的R2、R1则可能出现死锁。

CLARIFICATION：这个问题不是关系数据库管理系统特有的.我的印象是，没有任何实现可以在只读行上死锁.如果你有一个反例(对于一个具体的供应商)，请张贴一个答案演示，我会接受它。或者，发布一个可以证明不会死锁的所有具体实现的列表(最完整的列表将被接受)。

Answer 1

这个问题是不可能回答所有可能的RDBMS的，因为锁定策略是一个实现细节。尽管如此，有用的RDBMS将有一些共同的特性：

对于没有应用提示的SELECT语句(FOR UPDATE，WITH (UPDLOCK)，.)任何合理的RDBMS都不会使用写锁。可能需要读锁。实际上，除了Hekaton表之外，至少Server对SERIALIZABLE也这样做。

读锁从不冲突。如果只执行读取，则不可能出现死锁。

但是，只读行可能导致死锁，即使它们从未写入Server中的.，

UPDATE T SET SomeCol = 1 WHERE ID = 10 AND SomeCol = 0

如果SomeCol不是0，则立即释放锁，不会写入任何东西。但是U锁是一种可能发生冲突并导致死锁的锁类型。如果ID为10的行没有出现，则不可能出现死锁。