事务的 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 触发了哪类锁”。
