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 都不会释放。长时间空闲的事务，可能悄无声息地拖垮整个并发性能。
