sql - SQL死锁问题

Question

在关系数据库中，这两个语句是否有可能陷入僵局？我正在尝试简化我的问题和示例-请仅假设这些选择（我认为通常只需要可共享的读锁定）现在需要排他的读锁定：

Concurrent Connection 1:
SELECT {...}
FROM A 
JOIN B ON {...}

Concurrent Connection 2:
SELECT {...}
FROM B 
JOIN A ON {...}

也就是说，联接的顺序重要吗？ SQL中的单个语句是原子的吗？是在第一个语句中先锁定A然后在B中锁定，然后在第二个语句中先锁定B然后在A中锁定吗？

我想不是-我的直觉告诉我，无论多么复杂，这样的两个语句都不会死锁。我认为对语句进行了整体分析，并且需要使用某些确定性的全局顺序（即，按字母顺序）锁定需要锁定的资源。但是我不仅需要直觉，还想办法证明它，也找不到文档。

我对MS SQL 2005感兴趣，但是我不认为问题是特定于实现的。

其次，由于它与MS SQL有关，所以我还想知道通用表表达式也具有这种保证-CTE主要是语法优势（+递归），由引擎合并为传统的单个语句。

Answer 1

SELECT不能与其他SELECT死锁，因为它们仅获得共享锁。您说我们应该考虑这些SELECT现在“需要排他读取锁”，但是我们无法考虑，因为1）没有exlusive read lock这样的东西，并且2）读取不获取排他锁。

但是您确实提出了一个更笼统的问题，即简单的语句是否会造成死锁。答案是肯定的，是肯定的。锁是在执行时获取的，无需预先分析并进行排序，然后按一定顺序获取。引擎不可能预先知道所需的锁，因为它们取决于磁盘上的实际数据，并且无法读取引擎需要的数据以锁定数据。

由于索引访问顺序不同，简单语句（SELECt与UPDATE或SELECT与DELETE）之间的死锁非常普遍，并且非常容易调查，诊断和修复。但是请注意，总是涉及写入操作，因为读取不能互相阻塞。对于此讨论，应将UPDLOCK或XLOCK提示添加到SELECT应该被视为写操作。您甚至不需要JOIN，二级索引可能会引入导致死锁的访问顺序问题，请参见Read/Write Deadlock。

最后，编写SELECT FROM A JOIN B或编写SELECT FROM B JOIN A完全无关紧要。查询优化器可以随意调整访问顺序，因为查询的实际文本不会以任何方式强加执行顺序。

更新


那我们怎样才能建立一个一般的
读提交策略
“多个实体”数据库
不会死锁吗？


恐怕没有千篇一律的食谱。解决方案将视情况而定。最终，在数据库应用程序中，死锁已成事实。我理解这听起来很荒谬，因为在“我们降落在月球上，但我们无法编写正确的数据库应用程序”中，但是在起作用的强大因素中，几乎可以保证应用程序最终会遇到死锁。幸运的死锁是最容易处理的错误，只需简单地再次读取状态，应用逻辑，重新写入新状态即可。既然这么说了，那么有一些好的做法可以极大地减少死锁的发生，甚至可以消除死锁：


尝试为Writes提供一致的访问模式。有明确定义的规则说明诸如“事务应始终按以下顺序表：Customers-> OrderHeaders-> OrderLines”之类的规则。请注意，必须在交易中遵守订单。基本上，对架构中的所有表进行排名，并指定所有更新必须按排名顺序进行。这最终归结为编写代码的个人贡献者的代码纪律，因为它必须确保编写的代码更新了事务中的正确顺序。
减少写入时间。通常的看法是：在事务开始时进行所有读取（读取现有状态），然后处理逻辑并计算新值，然后在事务结束时写入所有更新。避免使用类似“读取->写入->逻辑->读取->写入”的模式，而是执行“读取->读取->逻辑->写入->写入”的模式。当然，真正的技艺在于如何处理实际，真实，个别的情况，这些情况显然必须由中间事务来完成。这里必须特别说明一种特定的事务类型：由队列驱动的事务，按照定义，事务通过从队列中出队（=写）开始其活动。众所周知，这些应用程序总是很难编写并且容易出错（特别是死锁），幸运的是，有很多方法可以做到这一点，请参见Using tables as Queues。
减少读取量。表扫描是死锁的最普遍原因。正确的索引编制不仅可以消除僵局，而且还可以提高过程中的性能。
Snapshot isolation。这是避免死锁的最接近免费午餐的地方。我故意把它放在最后，因为它可能掩盖了其他问题（例如不正确的索引编制），而不是解决它们。


尝试使用LockCustomerByXXX方法解决此问题，恐怕不起作用。悲观锁定无法扩展。如果您想要获得任何不错的性能，则要采用Optimistic concurrency更新。