ACID 四特性需协同实现：原子性靠 undo log 回滚，一致性依赖约束与事务配合，隔离性由 MVCC 和锁机制保障，持久性通过 redo log 刷盘确保；必须正确配置引擎、参数、约束及事务控制逻辑。
原子性（Atomicity）：为什么转账不能只扣不加？
原子性不是“尽量全做”，而是“要么全做，要么全不做”。MySQL 用 undo log 实现它——事务执行中每改一行，都先记下“怎么 undo”；一旦中途出错（比如 UPDATE 失败、连接断开、服务器宕机），InnoDB 就靠这些日志把已做的修改全部抹掉，退回到事务开始前的状态。
- 常见错误现象：
START TRANSACTION后只执行了扣款 SQL，没来得及加款就崩溃，结果钱没了但对方没收到 → 原子性被破坏（实际不会发生，因为 InnoDB 自动回滚） - 实操建议：别依赖应用层 try-catch 后手动补救，必须用数据库原生事务控制；
BEGIN/COMMIT/ROLLBACK要成对出现，且确保 rollback 路径真正触发（比如存储过程中要用DECLARE EXIT HANDLER FOR SQLEXCEPTION） - 容易踩的坑：在 autocommit=1 模式下，每条 SQL 都是独立事务，
UPDATE a; UPDATE b;看似一组操作，实则无法回滚前者 → 务必先SET autocommit = 0或显式START TRANSACTION
一致性（Consistency）：不是数据库“保证”的，是你和它一起守的
一致性不是 MySQL 自己能单方面实现的特性，它是原子性、隔离性、持久性 + 你写的约束共同作用的结果。比如你建表时加了 CHECK(balance >= 0)，又在事务里做转账，那“总余额不变”“余额不为负”这些规则，才可能被守住。
- 使用场景：银行系统、库存扣减、积分变更等任何要求业务规则不被绕过的场景
- 实操建议：不要只靠代码校验余额是否足够，一定要在数据库层加
CHECK约束或外键；否则并发请求下，应用层判断“余额够”和执行“扣款”之间存在时间窗口，可能超卖 - 性能影响：
CHECK约束在 MySQL 8.0.16+ 才真正生效（旧版本只是语法忽略），务必确认版本；外键会带来额外锁开销，高并发写入时需权衡
隔离性（Isolation）：READ COMMITTED 和 REPEATABLE READ 差在哪？
隔离性解决的是“多个事务同时跑，彼此看到什么”的问题。MySQL 默认用 REPEATABLE READ（通过 MVCC + next-key lock 实现），它能防止不可重复读，但不防幻读；而 READ COMMITTED 只保证读到已提交数据，每次 SELECT 都可能看到新提交的行。
- 常见错误现象：事务 A 查两次同一张表，第二次多出几条记录（幻读），或发现某行值变了（不可重复读）→ 很可能是隔离级别设太低，或没理解 MVCC 的快照时机
- 实操建议：普通 Web 应用用默认
REPEATABLE READ即可；但如果你做实时报表、资金对账等强一致性读，考虑加SELECT ... FOR UPDATE或临时切到SERIALIZABLE（代价是并发大幅下降） - 容易踩的坑：在
REPEATABLE READ下，UPDATE 语句仍可能触发 gap lock，导致莫名其妙的锁等待；用SELECT * FROM information_schema.INNODB_TRX查当前事务，比猜更靠谱
持久性（Durability）：commit 成功后，真的就“永不丢失”了吗？
持久性靠 redo log 保证：事务 commit 时，MySQL 先把变更写进 redo log（顺序 IO，快），再异步刷盘到数据文件。只要 redo log 写成功，即使断电，重启后也能恢复。
- 参数差异：
innodb_flush_log_at_trx_commit是关键开关：设为 1（默认）最安全，每次 commit 都刷盘；设为 0 或 2 会提升性能，但有丢事务风险（最多丢 1 秒数据） - 实操建议：金融类业务必须保持 1；内部后台系统若能接受极小概率丢失，可设为 2（log buffer 每秒刷一次，但 commit 不强制刷）
- 容易忽略的点：即使
innodb_flush_log_at_trx_commit=1，如果磁盘本身开了 write cache 且没配电池/电容，断电仍可能丢 log → 硬件层也要配合
MySQL 的 ACID 不是黑盒承诺，而是由你选的引擎（必须是 InnoDB）、写的 SQL、设的参数、加的约束，一层层搭出来的保障。最常出问题的地方，往往不在“不懂 ACID”，而在“以为开启了事务就万事大吉”，却忘了关 autocommit、漏了约束、压根没查过当前隔离级别。
