隔离级别+MVCC是MySQL深度面试的镇场题，中高级后端岗必问。能不能把"隔离"这个抽象概念落到存储引擎层面——大部分候选人能背四个级别，但讲不清Read View的可见性判定。
先讲SQL标准的四个级别和各自防止的异常：读未提交（允许脏读）、读已提交（不脏读但不可重复读）、可重复读（不可重复读也防住了，标准允许幻读）、串行化（全加锁、无并发异常）。
定义三种异常：脏读看到别人未提交的数据；不可重复读同事务内两次读同一行结果不一样；幻读同事务内两次读相同WHERE条件返回的行数不一样。
点出MySQL特殊性：InnoDB默认RR，而且跟SQL标准不同——MySQL的RR通过MVCC（快照读）+ 间隙锁（当前读）把幻读也解决了。
讲MVCC：每行有隐藏列trx_id（最后修改它的事务ID）和roll_pointer（指向undo log构成的版本链）。快照读时InnoDB构造Read View——活跃事务ID列表的一个快照（RR下事务开始时一次性构造）。
讲可见性规则：某版本可见当且仅当trx_id < min_trx_id，或trx_id == 当前事务，或（trx_id < max_trx_id AND trx_id 不在活跃列表）。否则顺着roll_pointer看更早的版本。这样每个事务有稳定视图，读写互不阻塞。
SQL定义了四个隔离级别。读未提交允许看到别人未提交的数据，就是脏读。读已提交防住了脏读但防不住"不可重复读"——A事务里两次读同一行，中间B提交了更新，A两次读到不同值。可重复读防住不可重复读，同一行读多次结果一致，但SQL标准下仍允许"幻读"——范围查询两次行数不一样。串行化全加锁，正确但并发极差。InnoDB默认RR，而且MySQL很特殊——MySQL的RR把幻读也解决了，快照读靠MVCC，当前读靠间隙锁（Gap Lock）和临键锁（Next-Key Lock）。MVCC是InnoDB实现读写不阻塞的核心。每行有两个隐藏列：trx_id（最后修改它的事务ID）和roll_pointer（指向undo log里的上一版本）。undo log按版本串起来，每次update都把旧版本推入链。快照读时构造Read View——RR下Read View在事务第一次读时构造并复用，RC下每条语句都重新构造一个。Read View包含当前活跃事务列表、最小活跃事务ID（low-water）、下一个待分配的事务ID（high-water）。可见性判定：某版本的trx_id如果小于low-water，说明对应事务在Read View构造前就已提交，可见；如果trx_id等于当前事务自己，可见（自己改的自己能看到）；如果trx_id大于等于high-water，不可见（构造Read View之后才开始的事务）；如果trx_id在活跃列表里，不可见；否则可见。不可见就顺着roll_pointer往前看，直到找到可见版本。这样每个事务的视图和自己的Read View时间戳一致，读不阻塞写、写不阻塞读。当前读——SELECT ... FOR UPDATE、UPDATE、DELETE——不走MVCC，直接读最新已提交版本，并加行锁+间隙锁防止并发修改。
一定要明确点出"MySQL的RR连幻读也防住了"，大部分候选人不知道MySQL偏离了SQL标准。
能把undo log版本链画出来，指着一个trx_id说它怎么和Read View比较，是加分项。
要区分快照读（SELECT）和当前读（SELECT FOR UPDATE / UPDATE）——前者走MVCC后者走锁。
RC和RR的Read View构造时机差异容易忘，即答侠可以实时提示"RR只构造一次，RC每条语句一次"。
历史原因——早期MySQL的binlog是statement模式，RR才能保证复制一致性。MySQL 8开始row-based binlog普及，很多业务会手动调到RC。
临键锁（Next-Key Lock = 记录锁+间隙锁）不但锁住匹配行还锁住行之间的间隙，别的事务不能插入到这个范围内。
读写不阻塞是巨大的并发收益。代价是undo log要保留所有还可能被Read View看到的版本——长事务会让undo暴涨，这是MySQL的经典坑。