数据库死锁

RN.*_*RN. 18 database database-design deadlock

我们遇到数据库死锁的一个经典原因是两个事务以不同的顺序插入和更新表.

例如,事务A在表A中插入,然后在表B中插入.

事务B插入表B后跟A.

这种情况总是存在数据库死锁的风险(假设您没有使用可序列化的隔离级别).

我的问题是:

  1. 您在设计中遵循哪种模式,以确保所有事务都以相同的顺序插入和更新.我正在阅读的一本书 - 建议您可以按表格的名称对语句进行排序.你有没有做过类似或不同的事情 - 这会强制所有插入和更新的顺序相同?

  2. 删除记录怎么样?删除需要从子表开始,更新和插入需要从父表开始.你如何确保这不会陷入僵局?

Kar*_*arl 13

  1. 所有事务都以相同的顺序插入\ updates.
  2. 删除; 识别要在事务外删除的记录,然后在尽可能小的事务中尝试删除,例如通过在查找阶段识别的主键或类似物查找.
  3. 一般的小交易.
  4. 索引和其他性能调整既可以加速事务,也可以促进对表扫描的索引查找.
  5. 避免使用"热表",例如,一个表具有递增计数器,用于其他表主键.任何其他"交换机"类型配置都存在风险.
  6. 特别是如果不使用Oracle,请详细了解目标RDBMS的外观行为(乐观/悲观,隔离级别等)确保您不允许行锁升级为表锁,就像某些RDMS一样.


Seu*_*ewa 7

死锁并不重要.只是准备好在失败时重试您的交易.

并保持简短.由触摸极少数记录的查询组成的短事务(通过索引的魔力)是最小化死锁的理想选择 - 锁定的行数更少,并且时间更短.

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

您还可以通过使用MVCC和CONSISTENT READ事务隔离级别来避免锁定:某些线程只会看到陈旧数据,而不是锁定.