SQL死锁预防设计策略_SQL结构层面避免冲突

统一表访问顺序可避免死锁，如按字母序或模块层级固定顺序加锁；缩小锁粒度需确保WHERE条件命中索引，避免全表扫描导致锁升级。

统一访问顺序，避免循环等待

多个事务同时操作多张表时，若各自按不同顺序加锁，极易形成死锁。例如事务A先锁表X再锁表Y，事务B却先锁表Y再锁表X，二者相互等待即触发死锁。解决方法是强制所有业务逻辑按同一约定顺序访问表——比如按字母序（customer → order → product）、或按模块层级（基础表 → 关联表 → 汇总表）。应用层调用DAO前可做简单排序，数据库侧可在存储过程开头显式按固定顺序SELECT FOR UPDATE。

缩小锁粒度与范围

尽量避免全表扫描和无索引UPDATE/DELETE，否则可能升级为表级锁或锁住大量无关行。确保WHERE条件命中有效索引，让数据库只锁定真正需要的行。例如UPDATE orders SET status = 'shipped' WHERE id = 123比UPDATE orders SET status = 'shipped' WHERE create_time 安全得多——后者若未在create_time建索引，很可能锁住成千上万行甚至整张表。

减少事务内操作数量与时长

事务越长，持锁时间越久，冲突概率越高。把非数据库操作（如HTTP调用、文件读写、复杂计算）移出事务块；批量更新拆分为小批次（每次50~200条），配合显式COMMIT释放锁；避免在事务中等待用户输入或外部响应。一个典型反例：事务里先INSERT订单，再调用支付网关，等回调成功才UPDATE订单状态——这期间订单主键可能被其他事务争抢。

标签： 解决方法 热点