mysql的xa协议无法自动回滚失败分支，因其prepare后若参与者宕机或网络中断，事务将变为悬挂状态（in-doubt），需人工干预决策提交或回滚，且mysql不自动清理该状态、不记录失败上下文，仅能通过xa recover查询而无法自主处理。
MySQL 分布式事务本身不提供自动补偿能力，所有补偿逻辑必须由业务代码显式实现；依赖 XA 或 2PC 只能保证强一致，但一旦失败就会卡在 prepare 状态，需要人工干预或额外机制兜底。
为什么不能靠 XA COMMIT 自动回滚失败分支
XA 协议的 prepare 阶段完成后，如果某个参与者宕机或网络中断，协调者无法完成 commit 或 rollback，该事务就变成“悬挂事务（in-doubt transaction）”。MySQL 不会自动清理这些状态，XA RECOVER 能查到但不会帮你决策——是重试、强制提交还是回滚，全得你根据业务上下文判断。
- MySQL 8.0 中悬挂事务会一直占用连接和锁资源，可能拖垮其他查询
-
XA COMMIT执行失败时，错误信息通常是ERROR 1399 (XAE04): XAER_RMFAIL或XAER_NOTA，不代表数据已回滚，只是命令没发出去 - 没有内置日志记录“哪个分支在哪一步失败”，排查只能靠应用层埋点 + 数据库 binlog 对齐
TCC 模式下 Try/Confirm/Cancel 的落地要点
TCC 不是框架功能，而是对业务接口的契约约束。MySQL 本身不识别这三个阶段，所有状态控制、幂等写入、超时判断都得在应用层做。
-
Try阶段必须预留资源并写入明确的状态字段（如order_status = 'TRYING'），不能只靠数据库锁，否则 Cancel 时无法区分是未执行还是执行中 -
Confirm和Cancel必须是幂等 SQL，例如用UPDATE orders SET status = 'CONFIRMED' WHERE id = ? AND status = 'TRYING'，避免重复确认 - 超时治理不能只靠定时任务扫描：需在
Try写入时带expire_at时间戳，并在 Confirm/Cancel 前校验是否过期，否则可能 Confirm 一个早已被 Cancel 的操作
本地消息表 + 定时任务补偿的关键配置陷阱
本地消息表方案看似简单，但生产中最常出问题的是状态跃迁逻辑和轮询节奏不匹配。
- 消息表至少要有四个状态：
'pending'（刚写入）、'sending'（MQ 发送中）、'sent'（MQ 已接收）、'consumed'（下游确认）；少任何一个状态，就无法区分“没发”“发了一半”还是“发了但下游没收到” - 定时任务不能只查
status = 'pending'，必须加时间条件如created_at ，否则高并发下大量短事务会触发无效重试 - 更新消息状态的 SQL 必须带版本号或条件，比如
UPDATE msg SET status = 'sending' WHERE id = ? AND status = 'pending'，否则并发更新会导致状态错乱
消费者端幂等性不是可选项，而是补偿链的最后防线
无论上游用 XA、TCC 还是消息表，只要存在异步、重试、网络抖动，下游就一定会收到重复消息。MySQL 层面唯一可靠的幂等手段是“唯一索引 + INSERT IGNORE”或“先 SELECT 再 UPDATE”，不能只靠应用内存缓存或 Redis 计数。
- 例如积分变更场景，不要用
UPDATE user_points SET points = points + 10 WHERE user_id = 123，而应建唯一联合索引(user_id, biz_order_id)，再用INSERT IGNORE INTO points_log (user_id, biz_order_id, amount) VALUES (123, 'ORD-789', 10) - 如果业务要求严格顺序（如账户余额），消息表里必须存
seq_no字段，消费时按序号检查前一条是否已处理，跳号即暂停后续处理并告警 - MySQL 的
REPEATABLE READ隔离级别下，SELECT 后直接 UPDATE 可能幻读，建议用SELECT ... FOR UPDATE显式加行锁
补偿机制真正的复杂点不在代码怎么写，而在于“什么时候该补”和“补到什么程度”。比如库存扣减失败后，是立即取消订单，还是允许用户稍后手动重试？这取决于业务 SLA，而不是技术方案本身。别把补偿逻辑写死在事务脚本里，留好运营开关和人工干预入口才是关键。
