MySQL通过undo log（原子性/一致性）、redo log（持久性）、lock+MVCC（隔离性）落地ACID；RR级别下next-key lock解决大部分幻读，但非唯一索引当前读可能漏；行锁依赖索引，无索引则退化为全表锁；死锁日志需重点分析WAITING/HOLDS段定位闭环。
事务的 ACID 怎么在 MySQL 里落地
ACID 不是抽象概念，而是由具体机制保障的。比如 undo log 支持原子性和一致性，redo log 保证持久性，而隔离性靠的是 lock 和 MVCC。
面试常问“为什么事务回滚能撤销已执行的 update？”——答案就是 undo log 记录了行修改前的镜像，rollback 时按链表反向恢复。
-
redo log是物理日志，记录“某个数据页上做了什么修改”，用于崩溃恢复 -
undo log是逻辑日志，记录“把某行从 A 改成 B，那回滚就是设回 A”，支持多版本和回滚 - 持久性不等于“刷盘即完成”：
innodb_flush_log_at_trx_commit=1才真正 fsync 到磁盘；设为 0 或 2 会丢事务
可重复读（RR）下为什么还有幻读
MySQL 默认隔离级别是 REPEATABLE READ，但标准 SQL 定义中，RR 应该完全避免幻读；而 InnoDB 的 RR 通过 next-key lock 解决大部分幻读，却仍可能在「非唯一索引 + 当前读 + 无锁匹配」场景漏掉。
典型例子：SELECT * FROM t WHERE c = 5 FOR UPDATE，如果 c 是非唯一索引且值 5 不存在，InnoDB 只锁住插入意向间隙，不锁整个范围，此时另一个事务插入 c=5 就能成功。
- 快照读（普通
SELECT）靠MVCC避幻读，不加锁 - 当前读（
SELECT ... FOR UPDATE、UPDATE、DELETE）才用next-key lock - 唯一索引等值查询只锁记录本身（
record lock），不锁间隙；范围查询或非唯一索引才触发next-key lock
行锁失效导致全表扫描和锁升级
明明写了 WHERE id = ?，结果却锁了全表？大概率是走了全表扫描，而没命中索引。InnoDB 行锁是在索引上加的，没索引就只能退化为表级锁（实际是每行都加锁，效果等价于锁表）。
常见诱因：WHERE 条件字段隐式类型转换、函数操作（如 WHERE YEAR(create_time) = 2023）、字符集不一致、联合索引没用最左前缀。
- 用
EXPLAIN看type是否为const/ref，key是否显示用了哪个索引 -
SELECT * FROM performance_schema.data_locks可查当前事务持有的锁（MySQL 8.0+） -
innodb_status_output_locks开启后，SHOW ENGINE INNODB STATUS会输出详细锁信息
死锁日志怎么看、怎么复现
MySQL 检测到死锁后会主动回滚其中代价小的事务，并把现场写进错误日志。关键不是“谁被回滚”，而是看 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 和 *** (2) HOLDS THE LOCK(S): 这两段。
它告诉你：事务 A 在等哪一把锁，而事务 B 持有它；同时事务 B 又在等事务 A 持有的另一把锁——闭环形成。
- 死锁复现常用套路：两个事务以不同顺序更新同一组行，例如事务1先改
id=1再改id=2，事务2反过来 -
innodb_deadlock_detect=ON（默认）开启死锁检测，但高并发下开销大；关掉后靠超时（innodb_lock_wait_timeout）兜底 - 避免方式优先考虑应用层统一 DML 顺序，其次用
SELECT ... FOR UPDATE ORDER BY pk强制顺序加锁
2024-04-10T10:22:33.123456Z 123456 [Note] InnoDB: Transactions deadlock detected, dumping detailed information. *** (1) TRANSACTION: TRANSACTION 123456789, ACTIVE 2 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 123 page no 10 n bits 72 index PRIMARY of table `test`.`t` trx id 123456789 lock_mode X locks rec but not gap waiting Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 80000001; asc ;; *** (2) TRANSACTION: TRANSACTION 123456790, ACTIVE 3 sec starting index read, thread declared inside InnoDB 1 mysql tables in use 1, locked 1 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1 *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 123 page no 10 n bits 72 index PRIMARY of table `test`.`t` trx id 123456790 lock_mode X locks rec but not gap Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 4; hex 80000001; asc ;;
真正难的不是理解锁类型，而是把执行计划、索引结构、事务生命周期、日志状态这几条线串起来看——多数人卡在“知道概念，但看不出哪句 SQL 触发了哪类锁”。