xa prepare成功后锁不释放，是因为innodb为维持隔离性与持久性，必须持有所涉行锁、表意向锁（ix）及元数据锁（shared_write），直至收到xa commit或xa rollback显式指令。
XA PREPARE 阶段卡住，不是“卡在 prepare”，而是 prepare 成功后事务滞留在 PREPARED 状态、未提交也未回滚——这才是锁问题的真正源头。MySQL 不会自动清理这类事务，锁也不会释放。
为什么 XA PREPARE 成功后还会锁表/锁行？
因为 XA PREPARE 是两阶段提交的第一阶段完成标志：InnoDB 已写入 undo log、刷盘标记事务为 PREPARED，并持有所涉及的行锁、表意向锁（IX）、元数据锁（SHARED_WRITE）。这些锁要等到 XA COMMIT 或 XA ROLLBACK 才释放。
常见诱因包括：
- 应用层调用
XA PREPARE后，网络超时或进程崩溃，没发后续指令 - 协调者（如 Seata、Atomikos）故障，未驱动第二阶段
- DBA 手动执行
XA START+XA END+XA PREPARE，但忘了XA COMMIT - MySQL 5.7 中存在 bug（如 bug#88534）：binlog prepare 成功但引擎 prepare 失败，导致状态不一致，事务“半悬挂”
怎么确认是 XA PREPARED 事务在作祟？
别只查 INFORMATION_SCHEMA.INNODB_TRX —— 它对 XA 事务基本不可见（trx_mysql_thread_id = 0）。必须用：
-
XA RECOVER：返回所有处于PREPARED状态的 XA 事务，含formatID、gtrid_length、bqual_length和二进制data -
SHOW ENGINE INNODB STATUS：搜索ACTIVE (PREPARED)字样，能看到事务 ID、持续秒数、锁结构数（哪怕row lock(s) = 0，也可能持元数据锁） -
SELECT * FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'GRANTED' AND SOURCE LIKE '%xa.cc%'：直接定位被 XA 事务持有的SHARED_WRITE锁
XA RECOVER 查到事务后，如何安全回滚？
XA RECOVER 返回的 data 是二进制，不能直接 decode，但可拆出 gtrid 和 bqual：
- gtrid =
LEFT(data, gtrid_length) - bqual =
SUBSTR(data, gtrid_length + 1, bqual_length) - formatID 来自
XA RECOVER输出第三列
构造命令示例：
XA ROLLBACK '10.220.17.74.tm163972871540800001', '10.220.17.74.tm3', 1096044365;
注意：
- 务必用
XA ROLLBACK（不是ROLLBACK），否则报错XAER_INVAL - 如果事务已 commit，强行
XA ROLLBACK会报XAER_NOTA，属正常现象 - MySQL 8.0.29+ 放宽了 XA 与本地事务互斥限制，但旧版本（≤8.0.28）下，只要存在
PREPAREDXA 事务，所有 DDL 都会被EXCLUSIVE元数据锁阻塞
如何避免下次再掉进这个坑？
根本解法不在 DBA 手动救火，而在应用层兜底：
- 所有 XA 流程必须配超时机制：从
XA START开始计时，超过阈值（如 30s）未进入COMMIT/ROLLBACK，就触发强制XA ROLLBACK - 禁止在交互式客户端中手动执行 XA 命令；若必须调试，执行完立刻
XA COMMIT或XA ROLLBACK - 监控告警项应包含：
XA RECOVER返回行数 > 0、SHOW ENGINE INNODB STATUS中ACTIVE (PREPARED)事务存活时间 > 60s - 不要依赖连接断开自动回滚——MySQL 对 XA 事务完全不处理连接异常清理
最易被忽略的一点：XA PREPARE 失败时，XA RECOVER 查不到记录，不代表事务“消失”了；它可能已被 InnoDB 自动回滚，此时无需干预。只有 XA RECOVER 能查到，才说明事务真实滞留且正在锁资源。
