MySQL事务的ACID由InnoDB引擎、redo log、undo log、binlog和锁系统协同实现；redo log通过WAL机制保障crash-safe；undo log支撑回滚与MVCC；锁系统解决写冲突并防止幻读。
MySQL 事务靠什么保证 ACID？
MySQL 事务的 ACID 特性不是靠单个模块实现的，而是由 存储引擎（主要是 InnoDB）、redo log、undo log、binlog 和 锁系统 协同完成的。其中，InnoDB 是唯一完整支持事务的默认引擎，其他引擎（如 MyISAM）不支持事务，强行执行 BEGIN 或 COMMIT 也不会生效。
redo log 怎么确保 crash-safe？
redo log 是物理日志，记录“在某个数据页的某个偏移量上做了什么修改”，用于崩溃恢复。它写入是顺序的、先写日志再改内存（Write-Ahead Logging），所以即使数据库突然宕机，重启后也能通过重放 redo log 把已提交但未刷盘的数据页补全。
-
innodb_log_file_size太小会导致频繁 checkpoint，影响性能；太大则恢复时间变长 - redo log 是循环写入的，由
innodb_log_files_in_group控制文件数量，默认 2 个 - 事务提交时，必须等
redo log buffer刷到磁盘（由innodb_flush_log_at_trx_commit控制：0=每秒刷、1=每次 commit 都刷、2=commit 后写 OS cache）
SET GLOBAL innodb_flush_log_at_trx_commit = 1;
undo log 如何支撑回滚和 MVCC？
undo log 是逻辑日志，记录“怎么回退一条 SQL”，比如 INSERT 对应的 undo 是 DELETE，UPDATE 对应的是反向更新。它不仅用于回滚（ROLLBACK），更是 MVCC 的基础——每个读视图（Read View）都依赖 undo log 链找到对应版本的数据行。
- 长事务会阻止 undo log 被清理，导致
ibdata1文件持续膨胀（尤其在innodb_file_per_table = OFF时） -
SELECT不加锁时读的是快照，背后依赖的是当前事务开始时刻的read view+ undo 链遍历 - undo log 存储在
undo tablespace（MySQL 8.0+ 可独立配置），而非系统表空间内嵌
为什么有时候 SELECT 还要加锁？
因为 MVCC 只解决“一致性非阻塞读”，不解决“写冲突”。当执行 SELECT ... FOR UPDATE 或 UPDATE 时，InnoDB 会在索引记录上加 record lock，或在间隙上加 gap lock，组合成 next-key lock 来防止幻读。这些锁信息存在每个事务的 trx_locks 结构中，由锁子系统统一管理。
- 没有索引的 WHERE 条件会触发全表扫描 + 行锁升级为表锁（实际是每行加锁，但效果类似）
-
REPEATABLE READ隔离级别下，普通SELECT不加锁，但当前读（如SELECT ... LOCK IN SHARE MODE）会加锁 - 死锁检测由
lock_sys->wait_locks图算法实时触发，一旦发现环就回滚代价更小的事务
真正容易被忽略的是：事务的生命周期从第一个 SQL 开始（非 BEGIN），到 COMMIT 或 ROLLBACK 结束；中间任何未提交的锁、undo、redo 都不会释放。长时间空闲的事务，可能悄无声息地拖垮整个并发性能。
