数据库死锁

Question

数据库死锁的典型原因之一是两个事务以不同的顺序插入和更新表。

例如，事务A插入表A，然后插入表B。

在表B中插入事务B，后面是A。

这样的场景总是存在数据库死锁的风险(假设您没有使用可序列化的隔离级别)。

我的问题是：

1. 在您的设计中遵循什么样的模式，以确保所有事务都按照相同的顺序插入和更新。我正在读的一本书--有一个建议，就是你可以根据表格的名字对这些陈述进行排序。您做过类似或不同的事情--这会强制所有插入和更新都按照相同的顺序执行吗？
2. ，删除记录怎么样？删除需要从子表开始，更新和插入需要从父表开始。如何确保这不会陷入死锁？

Answer 1

所有事务都在同一order.

• Deletes；中插入\更新要在事务之外删除的记录，然后尝试在最小的可能事务中删除该记录，例如在查找阶段通过主键或类似项查找。

• 小事务generally.

• Indexing和其他性能调优以加快事务速度，并促进对tablescans.

• Avoid‘热表’的索引查找，例如，一个表具有其他表主键的递增计数器。任何其他“交换机”类型的配置都是risky.

• Especially，如果不使用Oracle，请详细了解目标RDBMS的外观行为(乐观/悲观、隔离级别等)。确保不允许行锁像某些RDMSes那样升级到表锁。

Answer 2

死锁没什么大不了的。只要准备好在失败时重新尝试您的事务即可。

把它们留短点。包含很少记录(通过索引的魔力)的查询组成的短事务是最小化死锁的理想方法--更少的行被锁定，并且时间更短。

您需要知道，现代数据库引擎不会锁定表；它们会锁定行；所以死锁的可能性要小一些。

您还可以通过使用MVCC和一致的读取事务隔离级别来避免锁定:一些线程将只看到陈旧的数据，而不是锁定。

Answer 3

1. 仔细设计数据库进程，以尽可能消除涉及多个表的事务。当我拥有数据库设计控制时，从来没有出现过死锁的情况，而无法设计导致死锁的条件。这并不是说它们不存在，也许在我有限的经验之外的情况下也是如此；但我并不缺少改进设计的机会，这导致了这些问题。一个明显的策略是从一个只使用时间顺序写入的表开始，插入没有相互依赖关系的新的完整原子事务，并在有序的异步process.
2. Always中应用它们的效果--使用数据库默认隔离级别和锁定设置--除非您完全确定它们会带来什么风险，并且已经通过测试证明了这一点。重新设计你的过程，如果可能的话，首先。然后，施加最低限度的保护，以消除风险(并测试以证明它)。不要“以防万一”增加限制--这往往会导致意想不到的后果，有时是你想要避免的那种后果。
3. 从另一个方向重复这一点，你在这个网站和其他网站上读到的大部分信息都是误导和/或错误的，因为它们是如此频繁地相互冲突，倡导修改数据库设置以应对交易风险和锁定问题。遗憾的是，特别是对于Server，我没有发现任何文档来源是无可救药的混乱和不足。