会卡住。XA START 后未执行 END 或 COMMIT/ROLLBACK 即断连，事务滞留在 XA RECOVER 中呈 PREPARED 状态，锁不释放、DDL 可能阻塞，且不会自动回滚。
XA START 后没执行 END 就断开，事务会卡住吗
会。MySQL 的 XA 事务在 XA START 后进入 ACTIVE 状态，此时不显式调用 XA END 或直接执行 XA COMMIT/XA ROLLBACK，连接断开后事务不会自动清理，而是滞留在 XA RECOVER 列表里，状态为 PREPARED（部分资源已锁定）。
这种“半悬挂”状态会导致：表级锁或行锁持续占用、后续 DDL 可能被阻塞、INFORMATION_SCHEMA.INNODB_TRX 中看不到它（因为不属于普通事务），但 XA RECOVER 能查到。
- 实操建议：应用层必须保证
XA START→XA END→XA PREPARE→XA COMMIT/ROLLBACK链路完整；网络超时或进程崩溃时，需有兜底机制主动扫描并清理XA RECOVER中的孤儿事务 - 不要依赖连接关闭自动回滚 —— MySQL 不做这事，和普通事务完全不同
-
XA RECOVER返回的data字段是二进制格式，无法直接解读，只能用于后续XA COMMIT ...或XA ROLLBACK ...
XA PREPARE 失败时，为什么有时查不到事务记录
因为 XA PREPARE 是两阶段提交的“第一阶段”，它要求所有参与节点完成本地写入并持久化 undo log，同时将事务状态刷盘标记为 PREPARED。如果在这一步失败（比如磁盘满、binlog 写入失败、InnoDB crash），事务可能只停留在 ACTIVE 状态，甚至根本没注册进 XA 系统。
典型现象：XA RECOVER 查不到记录，但客户端收到 ERROR 1397 (XAE04): XAER_RMFAIL 或 ERROR 1205 (HY000): Deadlock found；这时事务其实已被引擎层自动回滚，无需人工干预。
- 常见误判：看到
XAER_RMFAIL就去查XA RECOVER，结果为空，误以为“丢失了状态”—— 实际是压根没走到 PREPARE 成功那步 -
XA PREPARE成功才意味着真正进入 2PC 流程；失败则退化为单机事务处理逻辑 - 检查
SHOW ENGINE INNODB STATUS的 LATEST DETECTED DEADLOCK 或 LOG SECTION，有时能看到 PREPARE 过程中崩溃的线索
XA COMMIT 执行一半失败（如 coordinator 挂了），从库会不一致吗
不会。MySQL 的 XA 提交强依赖 binlog + InnoDB redo 的一致性，XA COMMIT 是原子操作：只有当 binlog 写入成功且 fsync 完成后，InnoDB 才会清除 prepare 日志并提交。从库靠 relay log 回放 binlog 事件，所以只要主库上 XA COMMIT 成功落盘，从库最终一定同步到相同状态。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
但要注意：如果 XA COMMIT 在写 binlog 途中失败（如磁盘 IO hang），整个语句报错，事务仍处于 PREPARED 状态，不会提交也不会丢数据 —— 这正是 XA 的安全边界。
- 真正的风险点在“协调者（应用）发起
XA COMMIT后网络中断，不知道是否成功”：此时必须先查XA RECOVER，再决定是重试 COMMIT 还是执行 ROLLBACK - MySQL 本身不提供“XA 事务状态查询 API”，应用需自己维护 XID 映射关系，或借助外部事务日志表记录每一步动作
- 5.7+ 支持
xa_recover_admin权限控制XA RECOVER输出，生产环境建议限制该权限
MySQL 8.0 的 binlog_transaction_dependency_tracking 对 XA 有影响吗
没有直接影响。该参数控制的是基于 write-set 的并行复制依赖判断逻辑，只作用于普通事务的 binlog event 分组，而 XA 事务的 XA START/XA END/XA PREPARE/XA COMMIT 全部作为独立 event 写入 binlog，且每个 XA 事务天然具备全局唯一 XID，replica 会按 XID 串行回放整个事务链路。
不过间接影响存在：若一个 XA 事务内修改大量数据，开启 WRITESET 可能导致 replica 上该事务被错误地与其他非 XA 事务并行执行，从而破坏跨事务的一致性假设（比如 XA 修改了配置表，后面普通事务读取它）。
- 推荐做法：对涉及 XA 的业务库，设置
binlog_transaction_dependency_tracking=COMMIT_ORDER，避免 write-set 引入不确定性 - XA 事务默认不参与 write-set 计算，但它的 commit event 仍会被当作一个“同步点”，影响后续事务的并行窗口
- 升级到 8.0.30+ 后，
XA RECOVER输出新增formatID和gtrid_length字段，方便与外部 TCC 或 Seata 对齐
XA 的麻烦不在语法多难，而在“事务状态游离于连接之外”——一旦 XID 泄露或上下文丢失，就只能靠人工核对 XA RECOVER 和业务日志来回溯。没人能靠直觉猜出哪个 0x313233... 对应哪笔支付订单。
