跨分片死锁无法通过单节点SHOW ENGINE INNODB STATUS排查，因其仅反映本地事务锁等待，不感知跨节点锁依赖；必须依赖全局死锁检测服务结合加锁全序与重试策略。
跨分片死锁根本查不到 SHOW ENGINE INNODB STATUS
单节点 SHOW ENGINE INNODB STATUS 只能看到本机事务的锁等待，对跨分片死锁完全无感。你执行完命令，翻遍 LATEST DETECTED DEADLOCK 部分，只会看到“没死锁”或“只有本地等待”，但业务已经卡住几十秒——这不是误判，是架构限制。TiDB、CockroachDB 或 MySQL 分库分表中间件（如 ShardingSphere、Vitess）中，每个分片都是独立的 InnoDB 实例，它们不共享锁状态，也不同步等待图。
真正的问题在于：死锁环横跨多个物理节点，而传统 MySQL 工具只管自己那一亩三分地。
- 不要浪费时间反复执行
SHOW ENGINE INNODB STATUS查各分片——它无法拼出全局视图 - 别依赖
information_schema.INNODB_LOCK_WAITS：该表只反映当前节点内阻塞链，跨节点关系为NULL - 错误日志里也找不到跨分片死锁记录，
innodb_print_all_deadlocks = ON依旧只写本机死锁
必须启用集群级死锁检测服务
生产环境真正有效的方案，是部署一个独立的全局死锁检测控制面（Deadlock Detector Service），它持续收集各分片上报的本地锁等待事件，实时构建 Global Wait-For Graph。这个图不是靠猜，而是靠结构化上报：
- 每个分片需开启
innodb_status_output_locks = ON（MySQL 8.0.29+）或通过 Performance Schema 暴露data_lock_waits视图 - 上报内容至少包含：
trx_id、blocking_trx_id、wait_lock_mode、wait_table、wait_index、wait_data（主键值） - 检测服务每 10ms 执行一次 Tarjan 算法，识别强连通分量（SCC）——出现长度 ≥2 的 SCC，即确认存在分布式死锁环
例如，检测到 [T1 → T2] 和 [T2 → T1] 同时存在，且 T1 在 Node A、T2 在 Node B，就可断定是跨分片死锁。
应用层能做的关键补救：加锁全序 + 重试策略
即使有全局检测，也得让业务尽快恢复。不能等检测服务发现再通知应用——那已经晚了。核心是把死锁从“不可控事故”变成“可预期重试路径”：
- 所有涉及多分片更新的事务，强制按统一规则排序资源：比如用户 ID 和商品 ID 拼接后取哈希模分片数，或严格按
MIN(id)升序加锁 - 应用捕获
ERROR 1213 (40001): Deadlock found when trying to get lock后，**不做静默失败**，而是立即重试（最多 3 次），且每次重试前 sleep 10–50ms 避免雪崩 - 避免在事务内调用外部 RPC 或 sleep：长事务会拉长锁持有窗口，显著增加跨分片冲突概率
注意：ORM 自动生成 SQL（如 MyBatis 动态条件顺序不固定、GORM 批量更新字段顺序随机）是加锁全序的最大破坏者，必须收口为确定性 SQL 模板。
最容易被忽略的坑：间隙锁在分片边界引发隐式死锁
RR 隔离级别下，范围查询触发的间隙锁（Gap Lock）在分片场景中会制造“看不见的依赖”。比如：
分片规则是 user_id % 4，事务 A 查询 WHERE user_id BETWEEN 1000 AND 1005 落在分片 0，事务 B 查询相同范围落在分片 1 —— 表面看无交集，但若两个事务都尝试插入 user_id = 1003（实际路由到不同分片），而各自已在本地加了间隙锁，就可能因分布式 2PC 提交阶段协调失败，形成类死锁的长时间阻塞。
这类问题不会出现在 SHOW ENGINE INNODB STATUS 中，也不会被 Tarjan 检出，因为没有显式锁等待边。唯一解法是：在分片键上避免范围操作，改用等值 + 显式枚举；或降级隔离级别至 READ COMMITTED（牺牲部分一致性换取可观察性）。
