Server死锁是否清晰？
Server死锁是否清晰？
提问于 2012-09-03 20:29:03
在阅读了this有趣的文章之后，我有一些问题。
此表显示了死锁情况：
T1在表t_lock1上使用c1=5对所有行保持X锁，而T2对表t_lock2上的所有行保持X锁。 现在，每个事务都希望更新先前被对方锁定的行。这会导致僵局。
问题1
- 交易是否获得锁？我知道对表的读取是由共享锁完成的，而对表的写入是使用独占锁完成的(我指的是默认的锁定设置)。
因此，从这个例子看来，事务也持有一个锁....is，对吗？
问题2
...T1在所有行上持有X锁，而c1=5在表t_lock1上.
- 正如我已经说过的，锁不是每一行(虽然可以做，但作者没有提到)-那么为什么他说:在所有行上使用C1=5？
回答 1
Stack Overflow用户
发布于 2012-09-03 20:36:11
对于问题1: Server使用U锁读取源表行，然后更新它们，仅在符合更新条件的行上将它们转换为X锁。注意读取多行的区别，然后将它们过滤到被写入的行。这两组的锁定方式不同。
由于查询中没有选择，所以只使用U和X锁。对于正在更新的表上的更新查询，不使用S-lock。这是一种启发式的避免死锁的方案。
问题2:锁定可以在不同的粒度上进行，但对于行计数较低的情况，通常是每行(这是强制的)。也许作者假设C1上有一个索引，这意味着只需要读取和锁定带有C1=1的行。其他的行都不会被碰的。
如果没有索引，Server确实会读取表中的所有行，在这样做时，U-锁它们，然后锁那些满足C1=1的行。作者确实提到，只有带有C1=1的行才是x锁定的。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/12253685
复制相关文章
相似问题
腾讯云开发者
