Seata 分布式事务“挂起”之谜：RM 客户端断连导致数据库 Global Lock 被锁死 10 小时的惨案

🚨 案发现场：数据库“假死”

周五下午 4 点，监控报警：某核心订单表的 Update 操作全部超时。

现象极其诡异：

1. 数据库层面：SHOW PROCESSLIST显示大量连接处于Sleep或Query状态，但没有长时间的Lock wait。
2. 死锁日志：MySQL 的innodb_status里没有任何 Deadlock 记录。
3. 应用日志：报错Global lock wait timeout。
4. 影响范围：只有特定的一条订单记录无法更新，其他记录正常。但由于业务重试机制，这条记录拖垮了整个连接池。

这就奇怪了：MySQL 没锁，为什么应用层报锁等待？

🔍 一、 抽丝剥茧：谁锁住了我的数据？

在排除了 MySQL 本地锁（Record Lock / Gap Lock）之后，我们将目光锁定了Seata。

Seata AT 模式的核心机制是“两阶段提交”，为了隔离脏读写，Seata 维护了一张逻辑锁