MySQL单机事务不用二阶段提交，因其依赖undo log、redo log和锁/MVCC实现本地原子性与崩溃一致性；2PC仅用于跨库或跨服务的分布式场景，代价高且复杂。
MySQL 单机事务本身不依赖二阶段提交（2PC）来保证一致性——它用的是 undo log + redo log + 锁/MVCC 这套本地原子机制。所谓“结合二阶段提交与补偿机制”，只在跨服务、跨数据库的分布式场景下才有意义，而这时 MySQL 本身已退居为一个参与者角色，不再主导一致性保障。
为什么 MySQL 本地事务不用二阶段提交
二阶段提交是协调多个独立资源管理器（如不同数据库实例、消息队列、外部支付系统）的协议，代价高、阻塞强、存在单点协调者故障风险。InnoDB 的事务完全在单实例内完成：所有 DML 在同一事务中由同一存储引擎执行，靠 XA START/XA COMMIT 虽可接入 2PC，但日常业务几乎不用——因为没必要。
- 普通
BEGIN/COMMIT已通过redo log的 WAL 和undo log的回滚能力，确保原子性与崩溃一致性 -
XA事务需显式开启，且要求客户端/中间件支持 XA 协议，运维复杂度陡增 - 一旦引入 XA，在 prepare 阶段持有锁时间拉长，极易引发锁等待甚至死锁，反而降低并发能力
真正需要 2PC 或补偿的场景：跨 MySQL 实例 or 跨系统
比如订单服务写主库 A，库存服务写主库 B，同时还要调用第三方物流接口——这三个操作必须“全成或全败”。这时 MySQL 只是其中一个参与者，不能自己决定全局成败。
- 若用 2PC：需部署独立事务协调器（如 Seata AT 模式、Atomikos），MySQL 实例以 XA 方式注册；但 prepare 后若协调器宕机，可能卡在“悬挂事务”状态，需人工干预
- 更常用的是补偿机制（Saga）：把大事务拆成一系列本地事务 + 对应的逆向操作，例如 ——
1. 创建订单（本地事务）→ 记录order_created事件
2. 扣减库存（本地事务）→ 失败则触发cancel_order补偿
3. 发货通知（异步调用）→ 超时未确认则重试或告警 - 关键点：每步都需幂等，补偿操作必须可重入；事件日志（如 Kafka）要落盘再更新业务表，避免消息丢失导致补偿断链
MySQL 内部一致性不靠补偿，靠隔离级别与正确用法
很多人误以为“并发更新导致余额算错”是 MySQL 不一致，其实这是应用层没用对事务或隔离级别。InnoDB 本身不会让两个 UPDATE 同时修改同一行而不加锁。
- 默认隔离级别
REPEATABLE READ下，UPDATE ... WHERE id = 1会自动加行级X 锁，后续事务必须等待 - 但若写成
SELECT balance FROM account WHERE id = 1; UPDATE account SET balance = ?（即先查后改），就可能被其他事务插队修改，造成覆盖写——这不是 MySQL 的 bug，而是应用没用原子操作 - 正确做法是用一条语句完成校验与更新：
UPDATE account SET balance = balance - 100 WHERE id = 1 AND balance >= 100，靠 WHERE 条件和行锁双重保障 - 如果业务逻辑复杂无法单 SQL 完成，必须用
SELECT ... FOR UPDATE显式加锁，并确保整个事务块短小、快速
最终一致性的“最终”，往往取决于补偿链路是否健壮、超时策略是否合理、日志是否可追溯——这些都不是 MySQL 自己能兜底的。别指望给 innodb_flush_log_at_trx_commit 设成 2 就能解决跨库不一致；真正的难点永远在边界上：服务怎么切、状态怎么记、失败怎么退、重试怎么控。
