XA事务在PREPARE阶段不释放锁，是因为InnoDB必须维持隔离性与持久性：既不能提交（避免binlog缺失破坏主从一致性），也不能回滚（防止redo中已写数据丢失）；锁将一直保留直至收到XA COMMIT或XA ROLLBACK显式指令。
XA事务Prepare阶段为什么一直不释放行锁和表锁
因为XA事务进入PREPARED状态后，InnoDB必须维持事务的隔离性——它既不能提交（否则binlog可能缺失，破坏主从一致性），也不能回滚（否则已写redo的数据丢失，违反持久性）。所以锁会原封不动保留，直到收到XA COMMIT或XA ROLLBACK显式指令。
常见错误现象：SELECT ... FOR UPDATE或UPDATE执行完XA PREPARE后，其他会话对同一行/表的DML持续阻塞，information_schema.innodb_trx中trx_state为PREPARED，且trx_started时间极长。
- 意向锁（IX）会持续持有，导致
ALTER TABLE等DDL被卡住 - 行级X锁不会因连接断开自动释放——MySQL不认为客户端断连等于事务终止
- 如果mysqld在prepare后崩溃重启，该事务会进入“悬挂状态”，需人工干预
如何快速定位并清理卡在Prepare阶段的XA事务
不是所有XA PREPARE都会出问题，但一旦服务异常中断（如kill -9、电源故障、容器被强制删除），就极易残留。关键在于先确认、再操作，避免误提交脏数据。
第一步查悬挂事务：XA RECOVER返回所有处于PREPARED状态的XID，格式为gtrid_length,bqual_length,formatID,gtrid,bqual。注意：若bqual_length非0，gtrid和bqual是二进制字节，需转十六进制再拼接（例如0x1234... + 0x5678...）才能用于后续命令。
- 安全做法：先用
XA COMMIT 'gtrid' 'bqual' FORMATID尝试提交；若报错Unknown XID，说明该XID已不在内存中，但undo段仍存在，此时应改用XA ROLLBACK - 禁止直接删
mysql.ibd或清空undo_001——这会导致InnoDB启动失败 - Docker环境要特别注意：容器重启不等于mysqld进程恢复XA上下文，必须手动
XA RECOVER
innodb_flush_log_at_trx_commit=1 和 sync_binlog=1 如何影响Prepare行为
双一模式下，XA PREPARE会触发一次fsync()刷redo log，确保prepare标记落盘；而XA COMMIT时还会再刷一次binlog。这意味着：prepare阶段已完成绝大部分持久化工作，只差一个“最终拍板”。
性能影响明显：每笔XA事务至少两次磁盘强制刷写，TPS显著低于普通事务。但在金融、订单类场景中，这是必须付出的代价。
- 若设为
innodb_flush_log_at_trx_commit=2，prepare只write不fsync，崩溃后可能丢失prepare状态，导致重启后该事务被自动回滚（即使binlog里有记录） -
sync_binlog=0会使commit阶段binlog仅write，若此时crash，从库可能多出数据（主库没commit，但从库重放了binlog） - 两参数不匹配（如一个1一个0）会破坏2PC原子性边界，MySQL官方明确不推荐
为什么崩溃恢复时MySQL能自动决定是commit还是rollback
核心依据只有两个文件：redo log中的TRX_UNDO_PREPARED标记 + binlog中是否存在对应事务的完整event。恢复流程是单向判定，没有交互。
具体逻辑：
— 若redo中有prepare标记，但binlog里找不到该事务的完整写入 → 安全起见，回滚
— 若redo中有prepare标记，且binlog里也存在该事务的完整event（含COMMIT或XID事件）→ 提交
— 若binlog有但redo无（极端情况），则忽略该binlog event（因数据页根本没改）
这个机制决定了：你永远不该手动去“修复”binlog内容来匹配redo，也不该用mysqlbinlog --flashback反向生成SQL去覆盖——那会彻底破坏崩溃恢复逻辑。
