本质是流量切换打散原有请求路径与事务行为，暴露低概率锁竞争。需聚焦切流前后变化点：应用层查sql路径错位、锁顺序不一致、批量操作索引顺序差异、范围for update间隙锁扩大；数据库层验隔离级别、锁等待超时、索引缺失；抓innodb状态定位循环链；回放新旧逻辑复现死锁。
流量切换后数据库死锁频发，本质不是“流量变大了”，而是**原有请求路径、事务行为、并发模式被突然打散或重组**，暴露出原本低概率发生的锁竞争逻辑。排查要聚焦“切流前后变化点”，而非泛泛查死锁日志。
看应用层：比对切流前后的SQL执行路径是否错位
流量切换常伴随路由变更（如灰度分组、新老服务并行、API网关规则调整），导致同一类业务请求落到不同实例或不同代码分支。重点检查：
- 相同用户/订单ID的两次支付回调，是否一个走旧逻辑（先更新订单再扣余额），另一个走新逻辑（先扣余额再更新订单）——这直接触发经典“锁顺序不一致”死锁
- 新服务是否引入了未适配的批量操作（如用
IN (1,2,3,5,4)代替有序ID列表），导致索引扫描顺序与旧服务不一致，引发索引死锁 - 是否新增了带范围条件的
FOR UPDATE查询（如按时间分页加锁），而旧逻辑只锁单行——间隙锁范围扩大，碰撞概率陡增
查数据库层：确认隔离级别与锁行为是否因实例差异被隐式改变
不同MySQL实例（尤其跨环境、跨版本、跨云厂商）可能默认隔离级别不同。RR（Repeatable Read）下间隙锁是死锁高发推手，而RC（Read Committed）则无间隙锁。务必验证：
- 切流目标库的
transaction_isolation是否仍是REPEATABLE-READ？某些云数据库在创建只读副本或新集群时会默认设为READ-COMMITTED，但应用代码假设RR语义，导致锁范围误判 - 目标库是否启用了
innodb_lock_wait_timeout调小（如从50秒改为5秒）？虽不直接引发死锁，但会让锁等待更快超时，掩盖真实锁堆积，使死锁报错更“显眼” - 目标库表结构是否缺失关键索引？例如切流指向的新库未同步最新DDL，导致本该走唯一索引的
UPDATE退化为全表扫描+间隙锁
抓现场证据：用SHOW ENGINE INNODB STATUS\G定位循环链起点
不要只看“最近一次死锁”，要连续执行多次，观察高频重复出现的事务组合。重点关注：
- 死锁日志中两个事务的
MySQL thread id是否分别来自新旧服务进程（可通过应用日志中的traceId或机器IP反推） - 每个事务持有的
LOCK_DATA是否集中在同一张表的相邻主键值（如id=1001和id=1002），暗示间隙锁冲突 - SQL语句里是否有未参数化的字面量（如
WHERE order_no = 'ORD20260915001'）？这类硬编码让执行计划无法复用，加剧锁粒度不可控
验业务逻辑：回放典型请求，复现最小死锁场景
从监控中提取切流后高频报错的接口+参数，用脚本模拟两个并发请求：
- 请求A：按旧服务逻辑执行（如
UPDATE orders SET status=2 WHERE id=123→UPDATE users SET balance=balance-10 WHERE id=456） - 请求B：按新服务逻辑执行（如
UPDATE users SET balance=balance-10 WHERE id=456→UPDATE orders SET status=2 WHERE id=123） - 观察是否稳定复现死锁。若能复现，说明问题根因明确，修复只需统一锁顺序
不复杂但容易忽略：流量切换本身不产生死锁，它只是把潜伏的锁序矛盾、索引缺失、隔离假设偏差一次性暴露出来。盯住“变化点”，比堆砌监控指标更有效。
