数据库的死锁问题在设计期就可以避免

Posted 2021-05-16 炼金士

前几天偶尔与一位数据库工程师谈起数据库的死锁(deadlock)问题。根据以往的经验，我一直认为：

　　1.MSSQL、DB2、Oracle之类的现代DBMS或者中间件可以帮助我们自动解决绝大部分死锁，其余一部分难以处理的死锁则由DBA在数据库控制端手工处理。就应用程序而言，不需要在源代码级过多考虑地考虑死锁问题。

　　2.死锁的发生对系统的性能和吞吐量有着明显的影响，但只要存在针对共享数据资源的大规模并发访问的情况，那么死锁是不可避免的。

　　理论上，预防死锁的最好的途径是：给每一个transaction设定一个优先级，同时确保较低优先级的事务不必等待较高优先级事务释放共享资源，反过来，也确保较高优先级的事务能够立刻取得相应的资源。如果开发人员无法判别事务的优先级，那么可以考虑在每个事务开始时赋予它一个的时间戳，依据时间戳的先后来判定事务的优先级，这类似于FIFO队列。在这方面，现代DBMS都提供了相应的语言支持。但是，假设由于网络故障而导致高优先级的事务无法commit或者rollback，那么是否其他低级别事务便要一直等待或者被抛弃？或者一个事务中的update操作施加了多个表级锁，并且占用了大量时间，那么即便这种事务从逻辑上并不合理，是否也要保持它的高优先级？

　　针对稀缺资源的竞争在任何场合都是正常的，死锁出现的因果关系给予我一个提示，就是不能盲目地依赖DBMS和DBA在死锁发生后再去解决死锁问题，那样必然已经对用户体验造成了消极影响。开发人员在设计过程中，需要更多地研判可能的并发访问问题。这些问题可能包括：

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

　　2.尽可能按同一顺序访问数据对象。如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。

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

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

　　5.考虑体系结构的优化与代码重构，提高系统整体的运行效率。例如尽可能不要采用类似EJB的效率低下的计算模型，或者将复杂的业务置于编译存储过程中执行。

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

　　7.将经常更新的数据库和查询数据库分开。定期将不改变的数据导入查询数据库中，这样查询和更新就可以分开进行，而降低死锁机率。

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

　　网上有很多关于死锁问题的讨论，在理论方面，R.Ramakrishnan的《Database management systems》也有非常精辟的阐述。就实际开发而言，不同的数据库环境有着不同的处理方法，不同的体系架构也会导致不同的结果，这些开发人员需要更多地考虑的。