死锁主因是事务对多表加锁顺序不一致，而非并发量高；应强制按表名字典序统一加锁顺序，并通过日志、性能视图和埋点持续验证。
死锁为什么总在并发更新多张表时发生
根本原因不是并发高，而是事务以不同顺序申请行锁。比如事务A先锁orders再锁inventory，事务B反过来，就卡死。MySQL检测到循环等待后回滚其中一个，但业务层往往没做重试或兜底，直接报错Deadlock found when trying to get lock。
- 只要两个及以上事务修改相同行集，且加锁顺序不一致，死锁概率随并发线程数指数上升
- 常见于订单创建（扣库存+写订单+记日志）、积分变更（用户表+流水表+规则表）等跨表操作
- 即使所有SQL都走索引，只要顺序乱，照样死锁——索引只是让锁粒度更细，不解决顺序问题
如何强制统一所有事务的资源锁定顺序
核心是把“哪张表先更新”变成硬性约定，而不是靠开发人员凭经验写SQL。最可靠的方式是在应用层抽象出锁序规则，而非依赖SQL书写顺序。
- 对涉及的表名做字典序排序，每次按
ORDER BY table_name ASC确定更新先后。例如inventory、orders、user_log→ 必须按此顺序执行UPDATE/SELECT ... FOR UPDATE - 避免在同一个事务里用JOIN跨表更新，拆成多个单表语句，并显式按序调用
- 如果用ORM（如MyBatis、Hibernate），不要依赖
@Transactional自动包裹多方法——每个方法应明确声明它操作哪张表，上层协调器按表名排序后串行调用 - 注意：
INSERT ... SELECT这类语句隐式锁多张表，需单独分析其锁范围，不能简单按主表判断
哪些看似安全的操作其实会破坏锁序
最容易被忽略的是触发器、外键约束和自增主键生成逻辑。它们在你没意识到的时候悄悄加了额外锁。
- 带外键的
INSERT会自动对父表加S锁（共享锁），若父表更新顺序与子表不一致，立刻引入新锁序分支 - 触发器里执行的SQL完全脱离主事务的控制流，可能按任意顺序访问表。必须检查所有触发器，确保其内部SQL也遵守全局锁序
-
INSERT INTO t1 VALUES ()+INSERT INTO t2 VALUES (LAST_INSERT_ID())看似合理，但如果t2的插入逻辑又触发了对t3的更新，而t3不在原锁序列表里，就破防了 - 批量操作如
INSERT ... ON DUPLICATE KEY UPDATE，MySQL会对所有命中唯一键的行加X锁，实际锁范围可能远超预期，务必用SHOW ENGINE INNODB STATUS观察死锁日志里的*** WE WILL ROLL BACK TRANSACTION (1)段落确认锁对象
验证锁序是否真正生效的实操方法
别信代码注释，要看InnoDB实时行为。本地压测很难复现，必须在线上低峰期用真实流量+可观测手段交叉验证。
- 开启
innodb_print_all_deadlocks = ON，定期扫error log，提取死锁日志中TRANSACTION ... holds the locks部分，统计出现频次最高的表组合和顺序 - 用
SELECT * FROM performance_schema.data_locks（MySQL 8.0+）查当前持有锁的事务与对象，配合data_lock_waits看等待链，确认是否存在逆序等待 - 在关键事务入口加埋点，记录本次事务涉及的表名数组并排序后上报，对比实际执行顺序是否恒定。一旦发现
["user", "order"]和["order", "user"]同时存在，说明有路径绕过了锁序校验 - 测试时故意用
SLEEP(1)延长事务时间，在两个并发请求里分别模拟不同SQL顺序，观察是否还能复现死锁——能复现，说明锁序没落地；不能复现，再压测高频路径
锁序不是加个注释或文档就能生效的机制，它是需要被代码强制、被日志验证、被上线后持续监控的一条铁律。任何绕过它的快捷方式，最后都会变成凌晨三点的告警电话。
