MySQL通过ACID特性协同保障事务一致性：原子性依赖undo log实现回滚，隔离性由MVCC与Next-Key Lock支持四种级别，持久性靠redo log确保崩溃恢复，应用层需合理控制事务范围与操作。
MySQL 通过 ACID 特性 和底层机制协同保障事务一致性，核心在于原子性、隔离性与持久性的严格实现，而非仅靠单一功能。
事务的原子性（Atomicity）是基础
一个事务中的所有操作要么全部成功，要么全部回滚。MySQL 借助 undo log（回滚日志） 实现：事务执行过程中，每条修改语句都会生成对应的 undo 日志记录；一旦事务失败或显式执行 ROLLBACK，系统依据 undo log 撤销已做的变更，确保数据库状态不出现“半完成”现象。
- 开启事务需显式使用 BEGIN 或 START TRANSACTION
- 避免在事务中混用非事务型存储引擎（如 MyISAM），否则该部分操作无法回滚
- 长事务会持续占用 undo log 空间，可能影响性能和空间回收
隔离级别控制并发一致性
MySQL 默认隔离级别为 REPEATABLE READ，通过 MVCC（多版本并发控制） + Next-Key Lock（间隙锁） 防止脏读、不可重复读和幻读。不同级别对应不同一致性强度：
- red">READ UNCOMMITTED：允许脏读，一致性最弱，极少使用
- READ COMMITTED：每次 SELECT 都生成新快照，解决脏读，但可能不可重复读
- REPEATABLE READ：事务内多次查询结果一致（基于首次快照），配合间隙锁防幻读
- SERIALIZABLE：最高隔离，所有读加读锁，强制串行执行，牺牲并发换取强一致性
选择合适级别需权衡一致性要求与并发性能，多数业务 REPEATABLE READ 已足够。
持久性（Durability）支撑一致性落地
事务提交后，数据必须永久保存，即使发生崩溃也不丢失。MySQL 依赖 redo log（重做日志） 实现：事务提交前，先将变更写入 redo log（顺序 I/O，高效），再异步刷盘到数据文件。崩溃恢复时，InnoDB 通过 redo log 重放未落盘的已提交事务，确保数据最终一致。
- innodb_flush_log_at_trx_commit = 1（默认）：每次 commit 都刷盘，保证强持久性
- 设为 0 或 2 会提升性能但有丢事务风险，仅适用于可容忍少量数据丢失的场景
- 定期备份 + binlog 是持久性之外的重要兜底手段
应用层配合不可或缺
数据库机制再完善，也需应用正确使用才能保障端到端一致性：
- 事务范围要合理——避免跨服务、跨库操作放在同一事务（分布式事务需额外方案如 Seata、XA 或最终一致性）
- 及时提交或回滚，防止长事务阻塞、锁表或耗尽连接
- 读操作若需强一致，应避免在事务外读取刚写入的数据（尤其在 READ COMMITTED 下）
- 检查 SQL 是否真正受事务保护（例如 DDL 语句会隐式提交当前事务）
