分布式死锁是多服务跨mysql实例按不一致顺序操作共享资源形成的逻辑闭环等待，非innodb检测范围；需统一全局锁序、禁用跨分片for update、慎用间隙锁，并治理领域模型与共享表规范。
MySQL分布式架构下死锁和单机死锁不是一回事
分布式架构下，MySQL本身不直接产生“跨实例死锁”，因为InnoDB的死锁检测只在单个MySQL实例内生效。所谓“分布式死锁”，实际是多个应用服务（或微服务）在不同MySQL节点上按不一致顺序操作共享资源（如用户账户、订单、库存），再叠加本地事务锁行为，最终在应用层形成逻辑闭环等待。它不会被SHOW ENGINE INNODB STATUS捕获，也不会触发InnoDB自动回滚——系统只会卡住，直到超时或连接被杀。
避免跨服务资源访问顺序不一致
这是最常被忽视、也最致命的一点。比如订单服务先更新orders再扣减inventory，而退款服务却先释放inventory再更新orders，并发时极易形成A→B→A等待链。
- 所有服务对同一组业务实体的操作，必须约定全局统一的锁顺序，例如始终按“用户→订单→商品→库存”这个层级顺序执行写操作
- 避免在不同服务中用不同主键条件锁定同一张表：服务A用
WHERE user_id = ?更新account_balance，服务B却用WHERE id = ?更新同一行——即使物理行相同，InnoDB加锁路径不同，可能触发间隙锁冲突 - 对涉及多库的聚合操作（如分库分表下的转账），应在应用层引入协调者角色，或改用TCC模式将“尝试-确认-取消”逻辑显式拆解
慎用SELECT FOR UPDATE跨分片场景
在分库分表或读写分离架构中，SELECT ... FOR UPDATE若未命中索引、或落在非主库、或路由到多个分片，会导致不可预测的锁行为：部分节点加锁成功，部分失败或超时，后续UPDATE可能因锁缺失而破坏一致性，同时埋下死锁隐患。
- 禁止在分片键不明确的查询中使用
FOR UPDATE，例如SELECT * FROM orders WHERE status = 'pending' FOR UPDATE - 所有
FOR UPDATE语句必须走唯一索引或主键，并确保执行计划显示type=const或type=eq_ref - 若需批量锁定，优先用
UPDATE ... WHERE id IN (x,y,z)代替循环SELECT FOR UPDATE + UPDATE，减少网络往返与锁持有时间
隔离级别与gap锁在分布式环境更危险
MySQL默认的REPEATABLE READ会在范围查询中自动加Next-Key Lock（行锁+间隙锁）。在分布式调用链中，一个服务执行UPDATE product SET stock = stock - 1 WHERE category_id = 10，另一个服务紧接着执行INSERT INTO product (...) VALUES (...)插入category_id=10的新品——这两个操作可能落在不同数据库实例，但间隙锁逻辑仍会干扰彼此，尤其当分片规则未对齐时。
- 对纯写入类业务（如日志、流水），可考虑降级为
READ COMMITTED，彻底关闭gap锁 - 若必须用RR，所有范围操作务必建立覆盖索引，把
WHERE条件和UPDATE字段都包含进去，避免锁升级 - 禁止在分布式事务中混用
RC和RR隔离级别，会导致各节点可见性不一致，让应用层重试逻辑失效
真正难处理的不是锁本身，而是多个服务对“资源归属”和“操作边界”的隐含假设不一致。一次死锁报警背后，往往暴露的是领域模型划分模糊、服务职责重叠、或共享表缺乏治理规范。这类问题不会因加了重试就消失，只会延迟爆发。
