统一表访问顺序可避免死锁，如按字母序或模块层级固定顺序加锁；缩小锁粒度需确保 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 订单状态——这期间订单主键可能被其他事务争抢。
合理使用锁提示与隔离级别
默认 READ COMMITTED 已适合多数场景，不必盲目升级到 SERIALIZABLE。对高冲突 热点 数据（如库存扣减），可用 SELECT … FOR UPDATE SKIP LOCKED 跳过已被锁的行，避免阻塞；或用 INSERT … ON DUPLICATE KEY UPDATE 替代“先查后更”逻辑，消除竞态窗口。注意：FOR UPDATE 在非唯一索引或范围查询时仍可能锁住间隙（Gap Lock），需结合实际执行计划评估影响。
基本上就这些。结构层面预防死锁，核心是让 并发 行为更可预测、更轻量、更收敛——不是靠事后排查，而是从建表、索引、sql写法、事务边界开始就埋下确定性。
