事务提交卡在prepare阶段主因是redo log fsync慢，commit阶段卡顿多因binlog fsync延迟，xa事务加重2pc开销，崩溃恢复可能掩盖真实提交失败。
事务提交卡在 prepare 阶段，通常是 redo log 刷盘慢
当 innodb_flush_log_at_trx_commit=1 时，MySQL 必须把 redo log 从 buffer fsync 到磁盘，才算完成 prepare。这个操作阻塞整个提交流程，且无法并行化。
常见诱因包括：
- 磁盘 I/O 延迟高（如使用机械盘、云盘吞吐不足、IOPS 被打满）
- redo log 文件过小导致频繁 checkpoint，引发刷脏页竞争
- 大量小事务并发提交，造成 redo log buffer 竞争和频繁 fsync
- 系统级干扰：其他进程占满 I/O 带宽，或
fsync被内核调度延迟（尤其在某些 Linux kernel 版本下）
验证方式：查 SHOW ENGINE INNODB STATUS 中的 Log sequence number 和 Last checkpoint at 差值；配合 iostat -x 1 观察 %util 和 await 是否持续偏高。
事务卡在 commit 阶段，大概率是 binlog fsync 拖延
prepare 完成后，MySQL 需把 binlog cache 写入文件并调用 fsync，才允许将 redo log 状态由 PREPARE 改为 COMMIT。若 sync_binlog=1（8.0+ 默认），这步就是硬性瓶颈。
注意点：
- binlog 写入路径是否落在慢盘上（比如挂载了 NFS 或低性能云盘）
- binlog 格式影响大小：
ROW比STATEMENT日志体积大得多，fsync 压力更高 - 多个事务共享一个 binlog 文件，但 fsync 是串行的——高并发下会排队等待
- 某些云厂商的存储后端对
fsync实现较重（如部分对象存储网关），响应时间可达数十毫秒
可临时设 sync_binlog=0 对比延迟变化（仅测试环境），若明显改善，就坐实 binlog fsync 是瓶颈。
XA 事务参与时，prepare 阶段额外耗时不可忽略
普通单库事务的 2PC 是 InnoDB + Server 层协作；而启用 XA（如跨库事务）后，prepare 阶段要协调多个参与者，每个都需独立 fsync 日志并返回确认。
典型问题：
- 任意一个 XA 参与者响应超时（默认
xa_timeout为 60 秒），整个事务卡住 - 网络抖动导致 prepare 指令重试，叠加日志刷盘延迟
- MySQL 仅 InnoDB 支持 XA，若混用 MyISAM 表，prepare 会直接失败并报错
XAER_RMFAIL - XA 事务无法被 query cache 或复制过滤规则跳过，所有节点都必须执行完整 2PC 流程
生产环境除非真有跨库原子性需求，否则应避免 XA START/XA PREPARE ——它不是“更可靠”，只是“更重”。
崩溃恢复期间的 2PC 回滚可能掩盖真实提交延迟
MySQL 启动时会扫描 redo log，发现处于 PREPARE 状态但无对应 binlog 的事务，会自动回滚。这类事务在监控中表现为“提交成功但数据丢失”，容易误判为应用层逻辑错误。
真正要警惕的是：
- 主库异常宕机前最后一批事务，其 binlog 写入失败但 redo log 已 prepare → 恢复后被丢弃
- 从库 IO thread 拉取 binlog 不及时，导致 relay log 缺失，即使主库 commit 成功，从库也无法重放
- 监控只看
Com_commit计数，却忽略Innodb_buffer_pool_wait_free或Binlog_cache_use等隐性压力指标
2PC 的延迟从来不在代码里，而在磁盘、网络、配置三者的咬合缝隙中——盯住 fsync 耗时，比优化 SQL 更接近真相。
