分库分表下不存在MySQL原生全局死锁，因InnoDB死锁检测仅限单实例内；跨库循环等待属应用层问题，需业务逻辑与中间件协同解决。
分库分表场景下不存在 MySQL 原生的“全局死锁”——InnoDB 的死锁检测只作用于单实例内，跨库事务本身就不受同一死锁检测器管辖，所谓“全局死锁”其实是应用层事务协调失败导致的循环等待，必须靠业务逻辑和中间件协同解决。
为什么 SHOW ENGINE INNODB STATUS 看不到跨库死锁
InnoDB 的死锁检测是单实例、单存储引擎内部行为。它只会扫描当前 MySQL 实例中 INNODB_TRX 里活跃事务持有的锁和等待链。一旦事务拆到多个物理库（比如 db_order_01 和 db_user_02），每个库各自运行独立的 InnoDB 实例，彼此看不到对方的锁状态。所以：
- 两个分库事务互相等待（A 在库1锁了 order_id=100，B 在库2锁了 user_id=500，然后 A 要查 user_id=500，B 要查 order_id=100）不会触发任一实例的死锁检测
-
SHOW ENGINE INNODB STATUS只能告诉你本库内有没有死锁，对跨库阻塞完全无感 - 你看到的“卡住”，通常是连接池耗尽、应用线程阻塞在 JDBC
executeUpdate()、或分布式事务协调器（如 Seata）超时未响应
分库分表下真正会发生的“类死锁”现象
不是数据库报 Deadlock found when trying to get lock，而是应用层表现为：
- 接口响应时间持续飙升，但
SHOW PROCESSLIST里没有长等待的 SQL，只有大量Sleep或Updating状态的空闲连接 - 下游服务调用超时堆积，日志里反复出现
Connection wait timeout或Transaction timeout - 使用 ShardingSphere / MyCat 等中间件时，
SELECT * FROM sharding_db.sharding_table返回结果正常，但带FOR UPDATE的语句直接 hang 住 - Seata AT 模式下，
branch_register成功但branch_report卡在PhaseOne_Failed，且无错误日志
绕不开的三个落地动作
没有银弹，只有收敛路径：
-
强制统一资源访问顺序：哪怕分库，也要约定逻辑顺序。例如所有涉及订单+用户的操作，必须先操作
order库（按order_id % 4路由），再操作user库（按user_id % 8路由）。不能有的服务先查用户再扣订单，有的反过来 - 避免跨库强一致性事务：把“扣余额 + 生单”这种天然跨域操作，拆成最终一致。用本地消息表 + 定时任务补偿，或发 MQ 让下游异步执行；不要依赖 XA 或 Seata 全局事务扛高并发
-
显式控制锁粒度与生命周期：在分片键明确的前提下，确保 SQL 走到具体某个库的索引上。例如
UPDATE account SET balance = balance - 100 WHERE user_id = 12345 AND shard_key = 'shard_03'，避免因路由不明确导致全库广播或全表扫描锁升级
最容易被忽略的坑：中间件的锁感知盲区
ShardingSphere Proxy 或 JDBC 的 ShardingSphereDataSource 不会帮你做跨库锁等待判断。它只是把一条逻辑 SQL 拆成多条物理 SQL 并行下发。如果其中某条在库 A 上执行成功并加了行锁，另一条在库 B 上因索引缺失走了全表扫描，那库 B 就实际锁住了整张表——而 Proxy 完全不知道这事，还会继续转发后续请求，形成雪崩式阻塞。此时：
- 必须在每个物理库上单独执行
SELECT * FROM information_schema.INNODB_TRX查事务，不能只看逻辑库 - 所有分片表的
WHERE条件必须包含分片键，且该字段要有有效索引，否则行锁失效 - 禁用
SELECT ... FOR UPDATE跨库路由，这类语句应降级为应用层乐观锁（UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?）
真正的难点不在数据库配置，而在服务间契约——哪个服务负责发起、哪个服务提供幂等回调、超时后谁兜底。这些没法靠 innodb_deadlock_detect 开关解决，得写进接口文档，跑进集成测试用例里。
