14.5.5.3 How to Minimize and Handle Deadlocks 如何减少和处理死锁 这个部分建立在概念信息关于deadlocks 在章节 14.5.5.2, “Deadlock Detection and Rollback”. 它解释了如何组织数据库操作来减少死锁和随后的错误处理 Deadlocks 是一个经典的问题 在事务性数据库,但是他们不是危险的 除非它们是如此频繁你根本不能运行某个事务。 通常情况下,你必须写你的应用以便他们总是准备重新执行一个事务 如果由于死锁被回滚 InnoDB 使用自动行锁,你可以得到死锁 甚至在只有插入和删除单条记录的情况。 那是因为那些操作不是真正的原子的,他们自动设置锁在(可能的多个)index records上 你能处理死锁和降低他们的发生的可能性使用下面的技术: 1.在任何时候,执行SHOW ENGINE INNODB STATUS命令来确定最近的死锁的原因。那个可以帮助你调整你的应用来避免死锁: 2.如果频繁的死锁警告导致顾虑,收集更多的调试信息通过启用 innodb_print_all_deadlocks 配置选项, 信息关于每个死锁,不只是最新的,是被记录在MySQL error log. 3.总是准备重新执行一个事务 如果它回滚由于死锁,Deadlocks 不是危险的,只需要重新尝试 4. 让事务小的和短的让它们不易冲突 5. 在做了一组相关的改变立即提交让他们不易发生冲突。 特别的, 不要把一个活动的mysql session 保持open 对于一个长时间允许的未提交的事务 如果你使用锁定读(SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE), 尝试使用较低的隔离级别 比如READ COMMITTED. 6.当修改多个表在一个事务里,或者不同的行集在相同的表, 做这些操作在一个一致性的顺序。 然后事务形成良好定义的队列,不会死锁。 7.增加好的索引到你的表, 然后呢查询需要扫描很少的记录,从而设置更少的锁 使用 EXPLAIN SELECT 来确定哪个index 你的查询在使用 8.使用较少的锁,如果你可以负担允许一个SELECT 返回记录从一个老的快照, 不要增加FOR UPDATE or LOCK IN SHARE MODE子句。 使用 READ COMMITTED 隔离级别是好的在这里,因为每个一致性读在相同的事务 读取他自己的最新的快照 9.如果没有其他的帮助, 序列化你的事务使用表级锁。 正确的方式是使用LOCK TABLES,比如InnoDB 表,开始事务设置autocommit = 0