MySQL本身不支持跨库事务原子性，所谓“跨库死锁”实为误解；真正问题是本地事务退化为多个独立事务，缺乏全局协调，导致数据不一致，而报错Deadlock均发生在单库内部。
MySQL 本身不支持跨库事务的原子性保障，所谓“跨库事务容易死锁”，其实是误解——根本不是死锁，而是事务无法成立。真正的问题是：分库后，本地事务退化为多个独立事务，缺乏全局协调机制，导致数据不一致风险剧增；而你看到的“死锁报错”，往往来自单库内部（比如某个分片上的 UPDATE 冲突），或是应用层重试逻辑不当引发的二次竞争。
SHOW ENGINE INNODB STATUS 看不到跨库死锁，因为它压根不存在
-
InnoDB的死锁检测只作用于单个实例内的事务等待图。跨库操作（如db1.order和db2.inventory）在物理上是两个独立的mysqld进程，彼此无锁状态感知。 - 你遇到的报错
Deadlock found when trying to get lock，一定发生在某一个分库内部，比如：- 分库 A 中两个事务以不同顺序更新同一张分表的两行；
- 分库 B 中因缺失索引触发全表扫描，锁升级为表级锁；
- 应用层发起“伪分布式事务”（先提交 A 库，再提交 B 库），中间失败后手动回滚时，A 库已提交不可逆，B 库又尝试加锁冲突。
分库后事务拆分导致的“类死锁”现象怎么识别
这类问题常被误认为死锁，实际是业务逻辑卡在中间态 + 锁等待叠加：
- 应用层执行两阶段提交（TCC 或 Saga）时，第一阶段成功，第二阶段超时或失败，后续重试请求撞上第一阶段残留的未释放锁（如
SELECT ... FOR UPDATE持有间隙锁未提交）； - 同一用户并发下单，路由到不同分库，但库存扣减逻辑未对齐（比如 A 库按
user_id % 4路由，B 库按order_id % 4），造成多点更新顺序不可控； - 使用
XA协议强行跨库？别这么做。MySQL 对XA支持弱、性能差、故障恢复复杂，且XA RECOVER在主从切换后极易丢失 prepared 事务。
分库场景下真正要防的不是“跨库死锁”，而是锁竞争放大和事务断裂
-
索引失效在分库中更致命：每个分库都是独立实例，若某分片表缺失关键查询字段的索引，
WHERE条件会触发全表扫描 → 行锁升级为表锁 → 多个事务排队等锁 → 表现像“大面积阻塞”，日志里却只报一次Deadlock（其实是其中一个事务被检测到循环等待，其余是普通锁等待超时）。 -
间隙锁（Gap Lock）范围不可预测：分库后数据分布变化，原本在单库中安全的范围查询（如
WHERE created_at > '2026-09-01'），在某个分片中可能命中大量空隙，导致多个事务争抢同一 gap，触发死锁。 - 事务粒度失控：为“保证一致性”把订单创建+库存扣减+积分变动全塞进一个本地事务，结果这个事务横跨多次 RPC、外部 HTTP 调用、JSON 解析——锁持有时间从毫秒级拉长到秒级，极大增加冲突概率。
最常被忽略的一点：分库不是银弹，它把单点锁竞争，转化成了多点、异构、不可观测的锁竞争。你得在每个分片上单独调优，而不是指望一套 SQL 走天下。
