7.MySQL-InnoDB

架构

内存结构

• Buffer Pool (缓冲池)：最核心的区域。Buffer Poll缓存了经常操作的真实数据，MySQL 读取数据时会先看 Buffer Pool，修改数据也是先改 Buffer Pool（标记为脏页），再通过 Checkpoint 机制异步刷盘。
  • free page：空闲页，未被使用
  • clean page：被使用page，数据没有被修改过
  • dirty page：脏页，被使用page，数据被修改过，数据与磁盘数据不一致
• Change Buffer (写缓冲区)：针对非唯一二级索引的修改，如果数据页不在内存中，先缓存修改动作，减少磁盘 IO。
• 自适应哈希索引：优化对Buffer Pool数据的查询，监控对索引页的查询，观察到可以hash进行加速，无需人工干预，系统自己完成
• Log Buffer (日志缓冲区)：用来保存Redo Log、Undo Log，先存在缓存，再定期刷盘。

磁盘结构

• 系统表空间：系统表空间是更改缓冲区的存储区域
• 文件每张表空间：每张表生成表空间文件，包括单个InnoDB表的数据和索引，存在单个数据文件中
• 通用表空间：需要手动创建，建表是指定使用
• Undo表空间：撤销表空间，MySQL在初始化时会自动创建两个默认的undo表空间，存储Undo log日志
• 临时表空间：用来存储用户创建的临时表
• 双写缓冲区：Buffer Pool在刷盘前，先写到双写缓冲区文件中，以便系统异常时恢复数据。
• Redo Log：重做日志，是用来实现事务的持久性。该日志文件由两部分组成，重做日志缓冲以及重做日志文件，前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中，用于在刷新脏页到磁盘时，发生错误时，进行数据恢复使用。

后台线程

• Master Thread：核心后台线程，负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性还包括脏页的刷新、合并插入缓存、undo页的回收。
• IO Thread：在InnoDB存储引擎中大量使用了AIO来处理IO请求，这样可以极大地提高数据库的性能，而IOThread主要负责这些IO请求的回调
• Purge Thread：主要用于回收事务已经提交了的undolog，在事务提交之后，undolog可能不用了，就用它来回收。
• Page Cleaner Thread：协助 Master Thread 刷新脏页到磁盘的线程，它可以减轻Master Thread 的工作压力，减少阻塞。

核心机制：从修改数据到落盘的过程

1. 查询：先查 Buffer Pool，不在则从磁盘加载页。
2. 修改：先写 Undo Log（用于回滚）。
3. 写内存：修改 Buffer Pool 里的页，变成脏页。
4. 写日志：记录修改动作到 Log Buffer，并根据策略（如事务提交）刷到磁盘上的Redo Log。
5. 刷脏：后台线程异步将 Buffer Pool 里的脏页根据 Checkpoint 机制刷入.ibd数据文件。

面试重点

1. Buffer Pool 的 LRU 优化（必考）

• 追问：为什么不能用普通的 LRU？
• 重点：防止预读失效和全表扫描导致的热点数据被剔除。通过冷热分区（Old/Young）和时间窗口（1秒）来保护热数据。

2. 为什么需要 Redo Log？它和 Binlog 有什么区别？

• 重点：Redo Log 是 InnoDB 引擎特有的，物理日志，用于Crash-Safe (崩溃恢复)；Binlog 是 MySQL Server 层的，逻辑日志，用于归档和主从复制。
• 核心逻辑：写磁盘太慢，写 Redo Log 是顺序 IO，极快。有了 Redo Log，即使脏页还没刷到磁盘时宕机，重启后也能根据日志重做修改。

3. 双写缓冲区 (Doublewrite Buffer) 的价值

• 追问：有了 Redo Log 为什么还要双写缓冲区？
• 重点：Redo Log 记录的是对页的操作，但如果页本身已经损坏（断电导致页断裂），Redo Log 无法在损坏的页上进行修复。双写缓冲区提供了页的完整副本。

4. Change Buffer 的适用场景

• 重点：适用于写多读少且非唯一索引较多的业务。
• 陷阱：如果是唯一索引，插入时必须校验唯一性，这要求必须把数据页读入内存，此时 Change Buffer 就失效了。

5. Checkpoint 机制

• 重点：它决定了什么时候将脏页刷回磁盘。目的是缩短数据库的恢复时间（只重做 Checkpoint 之后的日志）以及在缓冲池不够用时腾出空间。

事务实现原理

redo log -解决持久性

修改数据后，先存在Redolog Buffer中，记录物理变化，事务提交时将Redolog Buffer写到磁盘的Redo Log中，如果后续刷新脏页出错，根据磁盘的RedoLog实现恢复。核心在于写RedoLog是顺序写，如果写脏页，那么是随机IO，性能差。

Undo Log - 解决原子性

回滚日志，用于记录数据被修改前的信息，作用包含两个:提供回滚和MVCC(多版本并发控制)。
undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
Undo log销毁:undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC。
Undo log存储:undo log采用段的方式进行管理和记录，存放在前面介绍的rollback segment 回滚段中，内部包含1024个undo logsegment.

MVCC

重点概念

当前读：

读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如:select...lockin share mode(共享锁), select...for update update、insert、delete(排他锁)都是一种当前读。

快照读

简单的select(不加锁)就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。

• Read Committed:每次select，都生成一个快照读。
• Repeatable Read:开启事务后第一个select语句才是快照读的地方。
• Serializable:快照读会退化为当前读。

MVCC

全称 Multi-Version Concurency Control多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。

底层实现基础

① 隐藏字段

InnoDB 会在每一行记录后面自动加上几个隐藏列，其中最核心的是：

• DB_TRX_ID(6字节)：最近一次修改（插入或更新）这条记录的事务 ID。
• DB_ROLL_PTR(7字节)：回滚指针。指向这条记录在上一个版本（Undo Log）中的地址。
• DB_ROW_ID：如果表没有主键，InnoDB 会自动生成一个自增主键。

② Undo Log版本链

回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undolog日志只在回滚时需要，在事务提交后，可被立即删除。
当一个事务修改某行数据时：

1. 会先用锁锁住该行。
2. 把修改前的值复制一份到Undo Log中。
3. 修改当前行的数据，并将DB_TRX_ID更新为当前事务 ID。
4. 将DB_ROLL_PTR指向刚才拷贝到 Undo Log 的旧版本地址。
   这样，不同事务对同一行记录的修改，就会在 Undo Log 中形成一个类似单向链表的版本链。

③ Read View

Read View 是 MVCC 在执行查询时产生的“快照”，它决定了当前事务能看到版本链中的哪个版本。Read View 包含四个关键属性：

• m_ids：生成 Read View 时，当前系统内活跃（未提交）的事务 ID 列表。
• min_trx_id：m_ids中的最小值。
• max_trx_id：系统即将分配给下一个事务的 ID（当前最大事务 ID + 1）。
• creator_trx_id：创建该 Read View 的事务 ID。

版本可见性判断算法（核心逻辑）

当事务执行SELECT时，会拿着当前记录的trx_id去跟 Read View 里的规则比对：

1. trx_id == creator_trx_id： 这个版本是你自己改的，可见。
2. trx_id < min_trx_id： 说明这个版本在生成 Read View 前已经提交了，可见。
3. trx_id >= max_trx_id： 说明这个版本是在生成 Read View 后才开启的事务改的，不可见。
4. min_trx_id <= trx_id < max_trx_id：
   • 如果trx_id在m_ids列表中：说明事务还没提交，不可见。
   • 如果不在：说明事务已提交，可见。
     如果当前版本不可见，就顺着DB_ROLL_PTR找上一个版本，直到找到可见的版本为止。

面试重点：MVCC (多版本并发控制)

1. MVCC 能解决幻读吗？（必考点）

• 标准回答：MVCC部分解决了幻读。
  • 对于快照读（普通SELECT），MVCC 通过 Read View 确保你读不到别人新插入的数据。
  • 对于当前读（SELECT ... FOR UPDATE），必须配合Next-Key Lock（记录锁+间隙锁）才能解决幻读。
  • 特殊场景：如果一个事务先快照读，然后另一个事务插入并提交，接着原事务执行UPDATE更新了那条新插入的记录，由于UPDATE产生了新版本，再次快照读时幻读就会出现。

2. 快照读 vs 当前读

• 重点：面试官会问“为什么你更新数据时不会读到旧版本？”
• 要点：
  • 快照读：走 MVCC，读取的是历史快照。
  • 当前读：走锁机制，读取的是最新记录。UPDATE、DELETE、INSERT都是当前读。

3. Undo Log 的清理机制

• 追问：Undo Log 会无限膨胀吗？
• 要点：不会。InnoDB 有专门的Purge 线程。当系统检测到没有事务再需要某个旧版本（即没有任何 Read View 的min_trx_id小于该版本的trx_id）时，该 Undo Log 就会被标记为可清理并回收。

4. 为什么 MVCC 不支持 Serializable 隔离级别？

• 要点：Serializable 要求所有事务串行化执行。MVCC 的初衷是提高并发，而 Serializable 强制所有读操作都加锁（S 锁），这与 MVCC 的无锁读目标相悖，因此在该级别下 MVCC 失去意义。