统一表访问顺序可避免死锁，如按字母序或模块层级固定顺序加锁；缩小锁粒度需确保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写法、事务边界开始就埋下确定性。
