mysql 8.0.23+修复了6个xa关键bug，包括prepared锁重建失败、xtrabackup备份错乱、xa commit超时后状态不一致、ftwrl无法阻塞xa commit、jta跨资源半提交残留及主从gtid不一致；但bug #84297和#87560在8.0.33中仍未修复。
MySQL 8.0 中已修复的 XA 关键 Bug 清单
MySQL 8.0（特别是 8.0.23 及后续小版本）修复了多个曾导致生产事故的 XA 核心缺陷，其中直接影响事务一致性、锁行为和主从同步的有 6 个已确认修复项。这些不是边缘 case，而是金融、支付类系统高频触发的问题。
-
Bug #84345：PREPARED 状态事务的表锁未在崩溃恢复后正确重建 —— 导致XA RECOVER能查到 XID，但INFORMATION_SCHEMA.INNODB_TRX中无对应记录，锁实际丢失却无法释放 -
Bug #84442：XTRABACKUP 备份期间执行XA PREPARE，可能跳过 undo log 刷盘，造成备份不可用或恢复后事务状态错乱 -
Bug #84499：XA COMMIT因锁等待超时失败后，事务进入 inconsistent state，XA RECOVER返回 XID，但后续XA ROLLBACK报XAER_NOTA -
Bug #84323：FLUSH TABLES WITH READ LOCK（FTWRL）无法阻塞XA COMMIT，破坏强一致性场景下的备份原子性 -
Bug #87385：外部 XA（如 JTA 管理的跨 MQ + MySQL 事务）中，部分分支 prepare 成功、部分失败时，未触发全局回滚，残留半提交状态 -
Bug #87389：XA 事务的复制位点（gtid_executed / binlog position）未在XA PREPARE阶段持久化，主库 crash 后从库可能跳过该事务，引发主从数据不一致
仍需警惕的未修复 XA Bug（8.0.33 仍存在）
截至 2026 年 6 月发布的 MySQL 8.0.33，以下两个 XA 相关问题仍未修复，且影响面广：
-
Bug #84297：InnoDB 引擎层的prepare调用发生在 binlog flush 阶段之后 —— 违反 2PC 顺序，极端情况下（如磁盘满）会导致 binlog 已写但引擎未 prepare，事务“消失” -
Bug #87560：XA 事务在主从复制中，XA PREPARE的 binlog event 顺序与实际执行顺序不一致，造成从库 apply 时死锁或无限重试
这两个 bug 在高并发写入 + 主从延迟波动的场景下极易复现，且无法通过参数调优规避。官方文档仍标注为 “Verified”，但无排期修复计划。
如何验证你用的 MySQL 版本是否包含这些修复
别只看版本号。MySQL 8.0.x 的小版本修复策略是 selective backport，同一 patch 可能只合入 8.0.29+，而 8.0.28 不含。实操判断方法如下：
- 执行
SELECT VERSION();确认内核版本（例如8.0.33） - 查官方 Changelog：访问 https://www.php.cn/link/4c1ed2facc7f349e4810f522a6ea9990，搜索 bug 编号（如
84345），确认其 Fixed in 字段是否包含你的版本 - 关键验证命令：
XA RECOVER输出中若含formatID=1且data字段长度稳定（非随机截断），说明Bug #84442和#84499已修复；若SHOW ENGINE INNODB STATUS的 LOG section 显示XA prepared transactions: 1且对应 trx_id 可在INNODB_TRX中查到，则#84345已生效
最易被忽略的一点：所有修复都依赖 innodb_support_xa = ON（MySQL 8.0 兼容层强制检查），即使你没显式设置，也要确认它没被代理层或配置模板静默关闭 —— 关掉它，XA RECOVER 就永远返回空，不是没悬挂，是压根不记。
