原子性指事务操作“全做或全不做”，由undo log实现：事务出错或回滚时，InnoDB利用undo log将未提交的修改恢复至初始状态；一致性是ACID协同结果，依赖原子性、隔离性、持久性及约束校验共同保障数据合法状态。
原子性（Atomicity）：事务必须“全做或全不做”
MySQL 的原子性靠 undo log 实现。当事务执行中途出错或被显式调用 ROLLBACK，InnoDB 会用 undo log 把已修改但未提交的数据回退到事务开始前的状态。
- 如果你只执行了
UPDATE但没COMMIT，其他事务看不到这次修改，这是原子性和隔离性共同作用的结果 -
START TRANSACTION后的每条语句不是立即生效，而是先写入变更日志，等COMMIT才真正落盘 - 常见误操作：在存储过程里漏写
ROLLBACK分支，导致部分语句已执行却无法撤回
一致性（Consistency）：不是由单一机制保证，而是 ACID 协同结果
一致性本身不对应某个独立日志或锁，它是原子性、隔离性、持久性共同达成的效果——数据库从一个合法状态变到另一个合法状态。
- 外键约束、
CHECK约束、唯一索引这些规则在事务提交时校验，违反则自动ROLLBACK - 比如转账前后总金额不变，这不是 MySQL 主动计算的，而是靠你写的 SQL 逻辑 + 约束 + 原子性共同守住的
- 容易忽略的点：应用层逻辑错误（比如少扣一笔钱）不会触发一致性保护，MySQL 只管它能检测的规则
隔离性（Isolation）：靠 MVCC + 锁控制并发可见性
InnoDB 默认隔离级别是 REPEATABLE READ，主要通过多版本并发控制（MVCC）实现快照读，配合行锁处理当前读。
-
SELECT是快照读（不加锁），看到的是事务启动时的一致视图；而SELECT ... FOR UPDATE或UPDATE是当前读（加锁），看到最新已提交数据 -
READ COMMITTED下每次SELECT都重新生成快照，REPEATABLE READ下整个事务复用同一个快照 - 幻读在
REPEATABLE READ下仍可能发生（比如INSERT新行），需用SELECT ... FOR UPDATE或升级到SERIALIZABLE
持久性（Durability）：靠 redo log 和刷盘策略保障
事务提交后，InnoDB 先把变更写入内存中的 redo log buffer，再刷到磁盘的 redo log 文件，最后才异步刷脏页到表空间。
-
innodb_flush_log_at_trx_commit参数决定刷盘时机：1（每次提交都刷，最安全）、0（每秒刷一次，有丢事务风险）、2（写 OS 缓存，不强制刷盘） - 即使 mysqld 进程崩溃，只要
redo log已落盘，重启时就能重放日志恢复数据 - 注意：
binlog不参与 crash recovery，它只用于主从复制和逻辑备份
ACID 四个特性看似独立，实则环环相扣。比如没有 undo log 就保不住原子性，没有原子性和隔离性，一致性就无从谈起；而持久性若失效，前面三者做的努力可能白费。实际调优时，不能只盯着单个特性改参数。
