数据库死锁预防规范

在开发或维护的过程当中查询数据库的时候经常会遇到发生死锁的问题，这里总结一些预防死锁的规范。

1. 应尽量缩短事务。在同一DB中并发执行多个须要长时间运行的事务时，发生死锁的几率较大。事务运行时间越长，其持有排它锁（exclusive锁）或更新锁（update锁）的时间便越长，从而堵塞了其它活动并可能致使死锁。保持事务在一个批处理中，能够最小化事务的网络通讯往返量，减小完成事务可能的延迟并释放锁。同时，涉及多个表的查询更新操做，若比较耗时，尽可能不要放在一个事务内处理，能分割便分割。若不能分割，便尽量使之在业务量较小的时间(例如子夜或者午饭时间)执行。

2. 应按同一顺序访问数据对象。若是全部并发事务按同一顺序访问对象，则发生死锁的可能性会下降。例如，若是两个并发事务得到 Supplier 表上的锁，而后得到Part表上的锁，则在其中一个事务完成以前，另外一个事务被阻塞在Supplier表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于全部的数据修改能够标准化访问对象的顺序。

3. 必须避免编写包含用户交互的事务。由于运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，若用户不能及时反馈，则此事务将挂起。于是将严重下降系统的吞吐量，由于事务持有的任何锁只有在事务提交或回滚时才会释放。即便不出现死锁的状况，访问同一资源的其它事务也会被阻塞，等待该事务完成。

4. 可以使用低隔离级别。肯定事务是否能在更低的隔离级别上运行。执行提交读容许事务读取另外一个事务已读取（未修改）的数据，而没必要等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）能够缩短持有共享锁的时间，从而下降了锁定争夺。

5. 可考虑体系结构的优化与代码重构，提升系统总体的运行效率。例如尽量不采用效率低下的计算模型，复杂的业务应采用异步任务调度处理。

6. 可经过程序控制事务提交的时机。若是一次检索出了10万条记录但只更改了其中的100条，就能够经过代码来执行100个update。或是用分段提交，即全部的修改使用多个事务进行提交，但这样会使事务不完整，应酌情使用。

7. 宜将常常更新的数据库和查询数据库分开。按期将不改变的数据导入查询数据库中，这样查询和更新就能够分开进行，而下降死锁机率。

8. 在进行数据库模式设计时，应注意外键引用的完整性，并对外键加索引。若是更新了父表的主键，因为外键上没有索引，因此子表会被锁定；若是删除了父表中的一行，整个子表也会被锁定。

 

"重要的不是治愈，而是带着病痛活下去。"