在开发或维护的过程中查询数据库的时候常常会遇到发生死锁的问题，这里总结一些预防死锁的规范。
1. 应尽可能缩短事务。在同一DB中并发执行多个需要长时间运行的事务时，发生死锁的概率较大。事务运行时间越长，其持有排它锁（exclusive锁）或更新锁（update锁）的时间便越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。同时，涉及多个表的查询更新操作，若比较耗时，尽量不要放在一个事务内处理，能分割便分割。若不能分割，便尽可能使之在业务量较小的时间(例如子夜或者午餐时间)执行。
2. 应按同一顺序访问数据对象。如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得Part表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在Supplier表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
3. 必须避免编写包含用户交互的事务。因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，若用户不能及时反馈，则此事务将挂起。因而将严重降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
4. 可使用低隔离级别。确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
5. 可考虑体系结构的优化与代码重构，提高系统整体的运行效率。例如尽可能不采用效率低下的计算模型，复杂的业务应采用异步任务调度处理。
6. 可通过程序控制事务提交的时机。如果一次检索出了10万条记录但只更改了其中的100条，就可以通过代码来执行100个update。或是用分段提交，即所有的修改使用多个事务进行提交，但这样会使事务不完整，应酌情使用。
7. 宜将经常更新的数据库和查询数据库分开。定期将不改变的数据导入查询数据库中，这样查询和更新就可以分开进行，而降低死锁机率。
8. 在进行数据库模式设计时，应注意外键引用的完整性，并对外键加索引。如果更新了父表的主键，由于外键上没有索引，所以子表会被锁定；如果删除了父表中的一行，整个子表也会被锁定。
"重要的不是治愈，而是带着病痛活下去。"