mysql是怎么样运行的：从根儿上理解mysql

重新认识MySQL

1. 启动 MySQL 服务器程序。

2. 启动 MySQL 客户端程序并连接到服务器程序。

3. 在客户端程序中输入一些命令语句作为请求发送到服务器程序，服务器程序收到这些请求后，会根据请求的 内容来操作具体的数据并向客户端返回操作结果。

客户端进程向服务器进程发送并得到回复的过程本质上是进程间通信的过程。

服务器处理客户端要求

MySQL的调控按钮-启动选项和系统变量

系统变量

乱码的前世今生-字符集和比较规则

客户端和服务器中的字符集

比较规则的应用

从一条记录说起-InnoDB记录结构

1. 磁盘 (Disk /硬盘 / SSD)
• 类比： 你的文件柜或仓库。
• 作用： 长期、持久地存储数据。即使电脑断电，存储在磁盘上的文件、应用程序、操作系统本身等数据也不会丢失。
• 特点：
• 容量大： 通常比内存大得多（几百GB到几TB）。
• 速度慢： 相对于内存和CPU，读写速度要慢很多个数量级。机械硬盘（HDD）尤其慢，固态硬盘（SSD）快很多，但仍远慢于内存。
• 非易失性 (Non-volatile)： 断电后数据依然存在。

2. 内存 (Memory / RAM - Random Access Memory)
• 类比： 你的办公桌或工作台。
• 作用： 临时存储正在运行的程序和当前需要处理的数据。CPU（中央处理器，相当于你大脑）直接从内存中读取指令和数据进行计算和处理。
• 特点：
• 容量小： 通常比磁盘小（几GB到几十GB，甚至上百GB，但仍远小于磁盘）。
• 速度快： 读写速度极快，CPU可以快速访问。
• 易失性 (Volatile)： 断电后数据会丢失。

3. 操作系统 (Operating System - OS) 的作用
• 类比： 你（或者说你的工作流程管理者）。
• 核心任务： 管理计算机的所有硬件资源（包括CPU、内存、磁盘等）和软件资源，并充当用户/应用程序与硬件之间的桥梁。
• 在磁盘和内存之间的关系：
• 加载程序/数据： 当你打开一个应用程序（比如Word）或一个文件时，操作系统会找到存储在磁盘上的程序代码和数据，并将需要的部分复制到内存中。为什么？因为CPU只能直接、快速地与内存交互。如果CPU每次都要去慢速的磁盘上找数据，电脑会卡得无法使用。
• 运行与处理： CPU在内存中执行程序指令，处理数据。所有正在进行的工作都在内存这个“工作台”上完成。
• 数据交换（分页/交换）： 内存是有限的。如果需要运行的程序和数据超出了物理内存的大小，操作系统会使用一种叫做虚拟内存的技术。它会在磁盘上开辟一块特殊区域（称为交换分区或页面文件），把内存中暂时不用的数据暂时存放到磁盘上（Swap Out），腾出内存空间给更急需的数据。当需要用到被换出的数据时，再从磁盘读回内存（Swap In）。这个过程比直接用内存慢，但能让系统运行超出物理内存限制的程序。
• 保存数据： 当你在应用程序中保存文件时，操作系统会将内存中修改过的数据写回到磁盘上，这样数据才能被永久保存。

• InnoDB 深知磁盘慢，内存快。

• 它使用内存中的缓冲池 (Buffer Pool) 作为主要的工作区域，尽可能地在内存中完成数据的读写操作，以提高性能。

• 对于读取，尽量从内存缓冲池命中，避免读磁盘。

• 对于写入，先修改内存缓冲池，并通过快速的顺序写 Redo Log 到磁盘来保证事务的持久性。

• 最终，内存中修改过的数据会由后台线程异步地刷回到磁盘上的数据文件中，完成数据的最终落盘。

InnoDB行格式

• 作用： 指示该行中哪些列的值是 NULL。

• 存储方式： 使用一个或多个字节作为位图（bitmap）。每个允许为 NULL 的列对应位图中的一个比特位。如果该列值为 NULL，则对应的比特位置为 1；如果不为 NULL，则为 0。注意：定义为 NOT NULL 的列不在此位图中占用比特位。

Redundant行格式

• 核心特点：

• 存储所有列（包括定长列如 INT, CHAR）的长度信息在记录头部的“字段长度偏移列表”中。这是其“冗余”的主要原因，因为定长列的长度本可通过表结构得知。

• 对于 NULL 值，即使不存实际数据，也在偏移列表中占位。

• 对于 VARCHAR, TEXT, BLOB 等变长字段，如果数据太大无法完全放在数据页内，它会在数据页内存储该字段的前 768 个字节，然后用一个 20 字节的指针指向存储剩余数据的溢出页（Off-page）。

• 缺点： 存储空间利用率最低，特别是对于包含很多定长列或 NULL 值的表

Dynamic和Compressed行格式

• 核心特点：

• 与 Compact 共享许多头部和 NULL 处理的优化。

• 关键区别在于处理溢出页数据： 对于 TEXT, BLOB 等大字段，Dynamic 不再强制在数据页内存储 768 字节的前缀。它会根据行的大小等因素判断：如果数据非常大，或者行内数据已经放不下，它可能只在数据页中存储一个 20 字节的指针，将所有实际数据都存放在溢出页中。

• 优点：

• 避免了 768 字节前缀可能带来的空间浪费。

• 数据页可以容纳更多的行（因为不被大字段前缀填充），提高了 B+ 树索引的紧密度和查询效率（特别是范围扫描）。

• 更适合包含大量 TEXT 或 BLOB 列的表

InnoDB数据页结构

• 状态管理: 通过 delete_mask 实现逻辑删除，支撑 MVCC 和延迟清理。

• 结构区分: 通过 record_type 和 min_rec_mask 区分 B+ 树的不同节点类型和特殊记录，支撑索引结构。

• 性能优化: 通过 n_owned 配合页面目录实现页内快速查找；通过 next_record 维护逻辑顺序链表，支持高效的顺序扫描和范围查询。

• 物理定位: heap_no 提供了记录在页面堆中的物理标识。

页目录

• InnoDB 会将页面内的所有用户记录（加上 Infimum 和 Supremum 这两个虚拟记录）划分成若干个组 (Group)。

• 第一个组（Infimum 组）只包含 Infimum 记录。

• 最后一个组（Supremum 组）包含 1 到 8 条记录（包括 Supremum 记录本身）。

• 中间的其他组，每组包含 4 到 8 条记录。这个数量范围是为了平衡目录大小和查找效率。

• 页目录并不存储每个组的所有记录信息，而是为每个组存储一个槽 (Slot)。

• 每个槽里存放的是该组中主键值最大的那条记录在页面内的相对位置（通常是该记录的 heap_no 或相对于页面起始位置的偏移量）。

• 关键点： 槽指向的是组内“最大”的那条记录。

• 页面目录本身存储在数据页的尾部，紧邻文件尾 (File Trailer) 之前。

• 槽是逆序存放的。也就是说，第 0 个槽（对应 Infimum 组）存放在最靠近文件尾的地方，第 1 个槽次之，依此类推，最后一个槽（对应 Supremum 组）最靠近空闲空间区域。

• 槽本身存储的值（记录位置）是按照主键顺序排列的，这使得可以对槽进行二分查找

• 使用目标主键值，对存储在页面尾部的槽数组进行二分查找。

• 目标是找到第一个主键值大于或等于目标主键值的槽。例如，如果要查找主键为 50 的记录，二分查找到的可能是指向组内最大记录主键为 60 的那个槽。

• 这个二分查找的时间复杂度是 O(log M)，其中 M 是槽的数量（远小于记录总数 N）。

• 二分查找确定了目标记录可能存在的那个组。

• 根据找到的槽（指向组内最大记录）和前一个槽（指向前一个组的最大记录，可以由此推断出当前组的起始记录），InnoDB 知道了在这个组内需要查找的记录范围。

• 然后，InnoDB 在这个非常小的组内（最多 8 条记录），通过遍历记录的 next_record 指针进行顺序查找，直到找到目标记录或者确定该记录不在这个组（也就不在这个页面）中。

• 这一步的时间复杂度是 O(k)，其中 k 是组的大小（一个很小的常数，最多是 8）

快速查询的秘籍-B+树索引

没有索引的查找

1. 确定 目录项记录 页 我们现在的存储目录项记录的页有两个，即页30和页32，又因为页30表示的目录项的主键值的范围是 [1, 320) ， 页32 表示的目录项的主键值不小于 320 ，所以主键值为 20 的记录对应的目录项记录在页30 中。

2. 通过 目录项记录 页确定用户记录真实所在的页。 在一个存储目录项记录的页中通过主键值定位一条目录项记录的方式说过了，不赘述了～

3. 在真实存储用户记录的页中定位到具体的记录

聚簇索引

二级索引

1. 独立的B+树结构：每个二级索引在MySQL中对应一棵独立的B+树。

2. 叶子节点存储主键值：二级索引的叶子节点存储的是主键值，而不是完整的数据行。

3. 回表查询：通过二级索引查询时，通常需要先找到主键值，然后再通过主键到聚簇索引中查找完整数据，这个过程称为“回表”。

4. 支持多个字段的联合索引：可以对多个列创建联合二级索引

1. 确定 目录项记录 页 根据根页面，也就是页44，可以快速定位到目录项记录所在的页为页42（因为2 < 4 < 9）。

2. 通过 目录项记录 页确定用户记录真实所在的页。 在页42 中可以快速定位到实际存储用户记录的页，但是由于c2列并没有唯一性约束，所以c2列值为4的 记录可能分布在多个数据页中，又因为2 < 4 ≤ 4 ，所以确定实际存储用户记录的页在页34和页35中。

3. 在真实存储用户记录的页中定位到具体的记录。到页34 和页35 中定位到具体的记录。

4. 但是这个 B+ 树的叶子节点中的记录只存储了c2 和c1 （也就是主键）两个列，所以我们必须再根据主键值去聚簇索引中再查找一遍完整的用户记录 —> 回表

好东西也得先学会怎么用-B+树索引的使用

索引的代价：

1. 先把记录按照 name 值进行分组，所有 name 值相同的记录划分为一组。

2. 将每个 name 值相同的分组里的记录再按照 birthday 的值进行分组，将 birthday 值相同的记录放到一个小 分组里，所以看起来就像在一个大分组里又化分了好多小分组。

3. 再将上一步中产生的小分组按照 phone_number 的值分成更小的分组，所以整体上看起来就像是先把记录分成一个大分组，然后把大分组分成若干个小分组，然后把若干个小分组再细分成更多的小小分组。然后针对那些小小分组进行统计，比如在我们这个查询语句中就是统计每个小小分组包含的记录条数。如果没有索引的话，这个分组过程全部需要在内存里实现，而如果有了索引的话，恰巧这个分组顺序又和我们的B+树中的索引列的顺序是一致的，而我们的B+树索引又是按照索引列排好序的，这不正好么，所以可以直接使用B+ 树索引进行分组

回表的代价

1. 从索引 idx_name_birthday_phone_number 对应的 B+ 树中取出 name 值在 Asa ～ Barlow 之间的用户记录。

2. 由于索引 idx_name_birthday_phone_number 对应的 B+ 树用户记录中只包含 name 、 birthday 、phone_number 、 id 这4个字段，而查询列表是 * ，意味着要查询表中所有字段，也就是还要包括 country字段。这时需要把从上一步中获取到的每一条记录的id字段都到聚簇索引对应的B+树中找到完整的用户记录，也就是我们通常所说的回表，然后把完整的用户记录返回给查询用户

如何挑选索引

MySQL的数据目录

单表访问方法

const

ref

ref_or_null

range

index

all

复杂搜索

索引合并

• 触发条件：通常发生在 WHERE 子句中包含多个条件，这些条件通过 AND 连接，并且每个条件都可以利用表上的不同索引时。

• 工作原理：
1. MySQL 对每个涉及到的索引分别进行扫描（通常是 range 扫描），获取满足各自条件的行指针（如主键 ID）。
2. 然后，它计算这些从不同索引扫描得到的结果集的交集（Intersection），也就是找出同时出现在所有结果集中的行指针。
3. 最后，根据这些交集中的行指针去读取实际的数据行。

• 示例： 假设 mytable 表在 col1 和 col2 上分别有独立的索引 idx_col1 和 idx_col2。 如果优化器选择 index_merge intersection，它会：
• 使用 idx_col1 找到所有 col1 = 'value1' 的行。
• 使用 idx_col2 找到所有 col2 = 100 的行。
• 找出同时满足这两个条件的行（取交集）。

• EXPLAIN 输出： type 列会显示 index_merge，并且 Extra 列会包含类似 Using intersect(idx_col1, idx_col2); Using where 的信息。

• 优点：当每个单独的 AND 条件都能通过索引过滤掉大量数据时，取交集可以快速定位到最终的目标行，避免只用一个索引然后对结果进行二次过滤或者全表扫描。

• 触发条件：通常发生在 WHERE 子句中包含多个条件，这些条件通过 OR 连接，并且每个条件都可以利用表上的不同索引时。

• 工作原理：
1. MySQL 对每个涉及到的索引分别进行扫描（通常是 range 扫描），获取满足各自条件的行指针。
2. 然后，它计算这些从不同索引扫描得到的结果集的并集（Union），也就是合并所有结果集并去除重复的行指针。
3. 最后，根据合并后的行指针去读取实际的数据行。

• 示例： 同样假设 mytable 表在 col1 和 col2 上分别有独立的索引 idx_col1 和 idx_col2。 如果优化器选择 index_merge union，它会：
• 使用 idx_col1 找到所有 col1 = 'value1' 的行。
• 使用 idx_col2 找到所有 col2 = 100 的行。
• 合并这两个结果集，并确保每行只包含一次（取并集）。

• EXPLAIN 输出： type 列会显示 index_merge，并且 Extra 列会包含类似 Using union(idx_col1, idx_col2); Using where 的信息。

• 优点：当 OR 连接的条件各自只覆盖表中的一小部分数据，但没有一个单一索引能高效处理所有条件时，合并各自索引扫描的结果通常比全表扫描快得多。

• 这是 Union 合并的一种变体。当 OR 条件中的某些索引扫描（例如范围扫描）不能保证返回有序的行指针时，MySQL 会先分别获取各个索引扫描的行指针，然后对它们进行排序，最后再执行合并去重操作。

• EXPLAIN 输出： Extra 列会包含 Using sort_union(...)。

• Intersection 合并用于处理 AND 条件，寻找共同满足所有条件的行。

• Union 合（包括 Sort-Union）用于处理 OR 条件，寻找满足任意一个条件的行。

连接的原理

• 定义：在 JOIN 操作中，驱动表是首先被访问和处理的表。MySQL 会先从驱动表中读取符合条件的记录。

• 角色：它是整个 JOIN 操作的起点。查询执行器会从驱动表中取出一条记录，然后拿着这条记录的关联字段（JOIN Key）去被驱动表中查找匹配的记录。

• 选择：MySQL 优化器会根据成本估算（考虑表大小、索引、WHERE 条件过滤后的结果集大小等因素）来尝试选择最优的驱动表。通常，优化器倾向于选择经过 WHERE 条件过滤后，剩余记录数较少的表作为驱动表。

• 定义：在 JOIN 操作中，被驱动表是在驱动表之后被访问的表。

• 角色：对于从驱动表中取出的每一条符合条件的记录，查询执行器都会拿着这条记录的关联字段去被驱动表中查找匹配的行。

• 访问次数：被驱动表会被访问多次，访问的次数理论上等于驱动表中满足条件的记录数。

• 执行顺序：驱动表先查，被驱动表后查。

• 访问次数：驱动表通常只需要扫描一次（或部分扫描），而被驱动表则可能根据驱动表的结果集大小被访问多次。

• 性能关键：
• 驱动表的选择至关重要：如果驱动表过滤后的结果集很大，那么对被驱动表的访问次数就会很多，即使被驱动表上有很好的索引，整体查询效率也可能很低。目标是让驱动表的结果集尽可能小。
• 被驱动表的连接列索引非常重要：因为被驱动表会被反复查询，如果在连接列（JOIN Key）上有合适的索引，MySQL 就可以快速定位匹配的行（例如使用 ref 或 eq_ref 访问类型），而不是进行全表扫描 (ALL)。如果被驱动表的连接列没有索引，性能会急剧下降，可能导致慢查询。

• INNER JOIN：优化器有较大的自由度来选择哪个表作为驱动表。它会估算不同顺序的成本，选择最低的那个。

• LEFT JOIN：左边的表（LEFT JOIN 左侧的表）通常强制作为驱动表，右边的表作为被驱动表。

• RIGHT JOIN：右边的表通常强制作为驱动表，左边的表作为被驱动表。（实践中 RIGHT JOIN 较少使用，常改写为 LEFT JOIN）。

• EXPLAIN 命令：EXPLAIN 输出结果中，表的列出顺序通常（但不绝对保证）就是 MySQL 实际执行时访问表的顺序，即排在前面的通常是驱动表。你可以观察每个表的 rows 估算值和 type（访问类型）来判断优化器的选择是否合理。

• STRAIGHT_JOIN 关键字：如果你认为优化器的选择不是最优的，或者想强制指定连接顺序，可以在 SELECT 语句中使用 STRAIGHT_JOIN。STRAIGHT_JOIN 会强制让其左边的表作为驱动表，右边的表作为被驱动表。但这需要你对数据和查询有深入理解，否则可能适得其反。

内连接和外连接

连接的原理

MySQL基于成本的优化

1. 根据搜索条件，找出所有可能使用的索引

2. 计算全表扫描的代价

3. 计算使用不同索引执行查询的代价

4. 对比各种执行方案的代价，找出成本最低的那一个

• 聚簇索引占用的页面数

• 该表中的记录数

InnoDB的Buffer Pool

1. 加载到Buffer Pool 中的页不一定被用到。

2. 如果非常多的使用频率偏低的页被同时加载到Buffer Pool 时，可能会把那些使用频率非常高的页从Buffer Pool 中淘汰掉

事务

锁

• InnoDB首先在B+树中定位到该记录的位置

• 然后获取该记录的排他锁（X锁）

• 最后直接在原位置上修改该记录

• 这个定位过程实际上是一个获取X锁的"锁定读"操作

• InnoDB首先在B+树中定位到该记录的位置

• 然后获取该记录的排他锁（X锁）

• 将原记录完全删除（移入垃圾链表）

• 插入一条包含更新值的新记录

• 原记录的定位过程是一个获取X锁的"锁定读"

• 新插入的记录由INSERT操作的隐式锁进行保护

• 这相当于先执行DELETE操作然后再执行INSERT操作

• 锁定操作分别遵循DELETE和INSERT的规则

• 原记录使用适当的锁进行删除

• 新记录使用适当的锁进行插入

• 如果有领导要参观教学楼，也就是想在教学楼门口前放S锁（表锁）时，首先要看一下教学楼门口有没有IX锁 ，如果有，意味着有教室在维修，需要等到维修结束把IX锁撤掉后才可以在整栋教学楼上加S锁。

• 如果有考试要占用教学楼，也就是想在教学楼门口前放X锁（表锁）时，首先要看一下教学楼门口有没有IS锁 或 IX锁 ，如果有，意味着有教室在上自习或者维修，需要等到学生们上完自习以及维修结束把IS锁和IX锁 撤掉后才可以在整栋教学楼上加X锁。

事务隔离级别 (Transaction Isolation Levels)

1. 脏读 (Dirty Read): 看到别人“铅笔草稿”
• 场景： 厨师 A 看到厨师 B 在菜谱上用铅笔写了个新的糖量（B 还没最终确认，只是个草稿，即未提交的修改）。厨师 A 信以为真，按这个草稿去配料了。结果厨师 B 突然把铅笔字迹擦掉了（事务 B 回滚了）。
• 后果： 厨师 A 基于一个从未正式生效的“脏”数据做了操作，可能导致后续错误。
• 比喻： 读到了未提交的数据。

2. 不可重复读 (Non-Repeatable Read): 发现菜谱内容变了
• 场景： 厨师 A 第一次看菜谱，盐量是 5 克。他去忙了点别的，回来再次看同一页菜谱，发现盐量变成了 7 克！这是因为在他离开期间，厨师 B 完成了修改并用墨水确认了（事务 B 已提交）。或者更糟，厨师 B 把这页菜谱撕掉了（事务 B 已提交 DELETE）。
• 后果： 在同一个任务（事务）中，前后两次读取同一份数据，结果却不一样了（数据被 UPDATE 或 DELETE）。
• 比喻： 同一事务内，多次读取同一行数据，值或存在状态发生变化。

3. 幻读 (Phantom Read): 发现多出来新菜谱
• 场景： 厨师 A 向管理员查询：“列出所有‘牛肉’相关的菜谱”，得到了 3 个结果。过了一会儿，他用完全相同的条件再次查询，却得到了 4 个结果！原来在他两次查询之间，厨师 B 新增了一道“香辣牛肉盖饭”并且用墨水确认了（事务 B 已提交 INSERT）。
• 后果： 在同一个任务（事务）中，按相同条件范围查询，结果集里的记录数量变了（好像多出来“幻影”一样）。
• 比喻： 同一事务内，多次按范围查询，结果集中出现了新增的行。

1. 读未提交 (Read Uncommitted) - “规则：随便看”
• 规则描述： 最宽松的规则。允许一个厨师直接看到其他厨师正在写的“铅笔草稿”（未提交的修改）。
• 能解决的问题： 基本解决不了上述任何问题。允许脏读、不可重复读、幻读。
• 性能： 并发性能最好，因为几乎没有限制。
• 用途： 极少使用，除非对数据一致性要求极低。
• 比喻： 后厨一片混乱，谁的草稿都可以随便看。

2. 读已提交 (Read Committed) - “规则：只看墨水字迹”
• 规则描述： 只能读取其他厨师已经用“墨水”确认（已提交）的修改。忽略所有“铅笔草稿”。
• 能解决的问题： 避免了脏读。
• 仍存在的问题： 允许不可重复读和幻读。（因为你看完一次墨水字迹，下次再看时，别人可能已经用墨水更新了内容或增加了新页）。
• 实现： 很多数据库（如 Oracle, SQL Server）的默认级别。通常利用 MVCC 实现：总是读取最新已提交的版本。
• 比喻： 比较礼貌，不看别人草稿，只看定稿。但别人随时可能发布新定稿。

3. 可重复读 (Repeatable Read) - “规则：看自己任务开始时的快照”
• 规则描述： 当一个厨师开始一项任务（事务开始）时，他会得到一个当时所有菜谱的“快照”（Read View）。在整个任务期间，他总是参考这份“快照”来读取数据。他看不到其他厨师在他开始任务之后提交的任何修改或新增内容。
• 能解决的问题： 避免了脏读、不可重复读。
• 仍存在的问题： 标准定义下，可能允许幻读。（虽然你看不到内容的修改，但别人新增的符合你查询条件的新菜谱页，理论上可能被你第二次范围查询时看到）。
• 实现： MySQL InnoDB 的默认隔离级别。InnoDB 通过 MVCC 实现。特别注意： MySQL 的 InnoDB 在可重复读级别下，通常使用间隙锁 (Gap Locks) 来额外防止幻读，使得它比 SQL 标准定义的可重复读更严格。
• 比喻： 任务开始时拍个照，之后一直看照片工作，不受外界干扰（基本不受，除了理论上的幻影）。

4. 可串行化 (Serializable) - “规则：独占使用，排队来”
• 规则描述： 最严格的规则。当一个厨师要对某些菜谱页进行操作时，他会把这些页面（或整个相关区域）完全锁住，不允许任何其他厨师进行任何读或写操作，直到他完成任务为止。
• 能解决的问题： 避免了脏读、不可重复读、幻读。提供了最高级别的一致性，效果等同于所有事务一个接一个排队执行。
• 性能： 并发性能最差，因为锁的粒度和时间最长，等待最多。
• 实现： 通常通过添加更多的锁（如范围锁、表锁）来实现。
• 比喻： 极其严格，要用哪几页菜谱就先锁起来，别人碰都不能碰，直到你用完。

• 取决于你的应用对数据一致性的要求有多高，以及对并发性能的需求有多大。

• MySQL InnoDB 默认的可重复读 在很多场景下是一个很好的平衡点，因为它提供了较高的一致性（通常还防止了幻读），同时通过 MVCC 保持了不错的并发性能。

• 如果需要绝对的隔离保证，且能接受性能损失，可以选择可串行化。

• 如果能容忍不可重复读和幻读，但不能容忍脏读，读已提交也是常见的选择（尤其是在其他数据库系统中）。

• 回忆一下： 可重复读级别下，厨师 A 开始任务时，会拿到一个“厨房快照”（Read View）。之后他所有的读取操作，都基于这个快照。

• 效果： 如果他第一次读取“红烧肉”菜谱，盐量是 5 克。即使在他看快照期间，厨师 B 把实际菜谱（最新版本）的盐量改成 7 克并提交了，厨师 A 再去看他的“快照”，看到的盐量仍然是 5 克。同样，如果厨师 B 删除了这道菜，厨师 A 看快照时，菜谱仍然存在（是旧版本）。

• 结论： MVCC 的快照机制，很好地保证了对于事务开始时已经存在的数据行，其内容不会在事务执行期间发生变化（不会读到更新或删除）。这就避免了不可重复读。

• 问题所在： 快照记录的是事务开始时“有哪些数据行，它们是什么状态”。它主要关注的是已经存在的行的版本。

• 场景： 厨师 A 用他的快照查询“所有牛肉类菜谱”，快照显示有 3 道。

• 漏洞： 这个快照本身，并没有明确记录“在‘酱牛肉’和‘葱爆牛肉’之间不允许出现新菜谱”或者“‘西冷牛排’后面不允许再有牛肉类菜谱”这样的信息。它只知道当时存在的具体是哪几道菜。

• 发生幻读（理论上）： 如果厨师 B 在厨师 A 的快照生成之后，插入了一道新的“水煮牛肉”并提交了。当厨师 A 在同一个事务中，再次执行“查询所有牛肉类菜谱”时，按照最纯粹的 MVCC 逻辑，数据库需要根据查询条件（“牛肉类”）重新扫描一遍相关范围。这时，它发现了新插入且已提交的“水煮牛肉”。由于这个插入事务已经提交，对于这次新的扫描操作来说是可见的。结果，厨师 A 的第二次查询就得到了 4 道菜谱——“水煮牛肉”像个幻影一样冒了出来。

• 认识到问题： MySQL InnoDB 的开发者显然也认为允许幻读会带来很多麻烦。

• 解决方案： InnoDB 在实现可重复读级别时，除了使用 MVCC 来保证读一致性外，还额外使用了间隙锁 (Gap Locks) 和/或 临键锁 (Next-Key Locks)。

• 工作方式（简化理解）：
• 当厨师 A 执行“查询所有牛肉类菜谱”时，InnoDB 不仅仅是基于快照返回结果。对于这种范围查询，它还会悄悄地在索引里，把“牛肉类”这个范围**“锁住”**。
• 这不仅仅是锁住现有的“酱牛肉”、“葱爆牛肉”、“西冷牛排”这几行，更重要的是，它会锁住这些行之间的“间隙”，以及最后一个“牛肉”菜谱之后的位置。
• 效果： 现在，如果厨师 B 想要插入新的“水煮牛肉”（这条记录会落在被锁定的间隙或末尾位置），他的 INSERT 操作就会被阻塞，必须等待厨师 A 的事务结束（提交或回滚）后才能执行。
• 结果： 由于插入操作被阻塞了，厨师 A 在他的事务中无论执行多少次“查询所有牛肉类菜谱”，都不会看到那个“幻影”——因为它根本就没能成功插进来！

• 标准的可重复读 (RR)： 主要靠 MVCC 快照保证对已存在行的读取一致性，防止内容更新或删除（防不可重复读），但快照本身难以阻止符合查询范围的新行插入，故理论上允许幻读。

• MySQL InnoDB 的可重复读 (RR)： 结合了 MVCC 和 间隙锁/临键锁。MVCC 保证读快照一致性 (防不可重复读)，而锁机制则阻止了其他事务在当前事务的查询范围内插入新行，从而额外地、通常有效地防止了幻读。

ACID定义

1. 从账户 A 扣除 100 元。

2. 给账户 B 增加 100 元。

1. A - Atomicity (原子性)：
• 是什么？ 事务是一个不可分割的工作单位。事务中的所有操作，要么全部成功执行，要么全部失败回滚。不会出现只执行了一半的情况。
• 银行转账比喻： 要么转账完全成功（A 减 100，B 加 100），要么转账完全失败（A 和 B 的余额都没变），绝不会出现 A 减了 100，但 B 没加上的情况。就像一个原子，不可再分。
• 一句话理解： All or Nothing.

2. C - Consistency (一致性)：
• 是什么？ 事务执行前后，数据库都必须处于合法的、符合规则的状态。数据不会因为事务的执行而被破坏。
• 银行转账比喻：
• 规则 1：转账前后，银行系统里钱的总量是不变的（只是从一个账户流向另一个）。
• 规则 2：账户余额不能是负数（假设有此规定）。
• 一致性保证：事务要么成功完成，并且满足所有这些规则（总金额不变，余额非负）；要么失败回滚，数据库回到事务开始前的状态，规则也满足。事务的中间过程（比如 A 扣了钱，B 还没加钱）对其他用户是不可见的，不会破坏整体的规则。
• 一句话理解： Keep data valid. (保持数据有效/符合规则)

3. I - Isolation (隔离性)：
• 是什么？ 当多个事务并发执行时，一个事务的执行不应被其他事务干扰。即事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。从效果上看，就像是各个事务串行执行一样（虽然实际上可能是并发的）。
• 银行转账比喻： 当你给 B 转账的同时，可能有另一个人 C 也在给 B 转账。隔离性保证你的转账操作和 C 的转账操作互不影响，你俩看到和修改的 B 的余额都是基于一个清晰的、非混乱的起点和终点，不会看到对方操作到一半的奇怪余额。
• 一句话理解： Transactions don't step on each other's toes. (事务间互不干扰)

4. D - Durability (持久性)：
• 是什么？ 一旦事务成功提交，它对数据库所做的更改就是永久性的。即使后续系统发生故障（如断电、崩溃），这些更改也不会丢失。
• 银行转账比喻： 一旦银行系统提示你“转账成功”，这 100 块钱就确确实实地从 A 到了 B。就算这时银行机房突然断电，重启后，B 的账户里也一定会有这 100 元（或者说，数据库恢复后能体现这次转账的结果）。
• 一句话理解： Once committed, it stays committed. (一旦提交，永不丢失)

如何保证ACID

1. 保证原子性 (A)：靠 Undo Log (撤销日志)
• 原理： InnoDB 在执行事务修改数据之前，会先把修改前的数据记录到一个叫做 Undo Log 的地方。
• 如何工作：
• 如果事务需要回滚 (Rollback)（比如操作失败或用户主动取消），InnoDB 就会利用 Undo Log 里的信息，把数据恢复到事务开始前的状态，就像时光倒流一样。
• 如果事务提交 (Commit)，这些 Undo Log 最终会被清理掉。
• 效果： 通过记录“如何撤销”，保证了要么全部完成，要么能完全退回起点，实现了原子性。

1. 原子性（Atomicity）：要么全做，要么全不做。 如果一个复杂的订单（多步骤事务）执行到一半，客人突然取消了，或者厨房出了点小状况（比如盐没了），怎么能干净利落地撤销掉已经做了一半的准备工作，让一切恢复到好像什么都没发生过一样？

2. 隔离性（Isolation）与并发： 厨房里人来人往，很多厨师（并发事务）可能同时在处理不同的菜品，甚至可能需要参考同一份基础菜谱（数据）。怎么能保证：
• 一个厨师正在修改菜谱时（进行写操作），不会影响到旁边只想查阅原始菜谱的另一个厨师（进行读操作）？
• 怎么让查阅菜谱的厨师看到的是一个在他开始查阅那一刻一致性的版本，而不是别人改到一半的“草稿”？这就是**多版本并发控制（MVCC）**要解决的问题。

1. 记录“如何撤销”：时光倒流的指南
• 核心思想： 当厨师要修改主菜谱（数据页中的行）时，他不仅会准备进行修改（这个修改行为本身会被 Redo Log 记录以防丢失），同时他还会在 Undo Log 这本特殊的“修改痕迹记录本”里，记下如何将这个修改撤销掉。
• 具体内容：
• 如果是 UPDATE（修改菜谱某项内容），Undo Log 就记下修改之前的旧值。
• 如果是 INSERT（新加一道菜谱），Undo Log 就记下如何DELETE（删除）这条新加的记录（通常是主键信息）。
• 如果是 DELETE（删除一道菜谱），Undo Log 就记下如何INSERT（重新插入）这条被删除的记录（即保存被删除行的内容）。
• 关键： Undo Log 记录的是逻辑上的反向操作所需的信息。

2. 数据行与 Undo Log 的链条：追踪历史版本
• 工作方式： 在主菜谱的每一行记录旁边（数据行的隐藏列），都有一个小标记（隐藏的 DB_TRX_ID 记录了最后修改它的事务ID，DB_ROLL_PTR 则是一个指针），指向 Undo Log 里记录“如何撤销这次修改”的那条笔记。如果一行数据被多次修改，这些 Undo Log 记录会像链条一样串起来，形成该行的历史版本链。
• MySQL 术语： 数据页中的行记录包含隐藏字段 DB_TRX_ID 和 DB_ROLL_PTR (Rollback Pointer)。DB_ROLL_PTR 指向该行记录对应的最新一条 Undo Log 记录。这些 Undo Log 记录内部也可能包含指向更早版本的指针，形成一个版本链。

3. 事务回滚（Rollback）：按图索骥，撤销操作
• 流程： 当一个事务需要回滚时（执行 ROLLBACK 命令，或者事务执行中途失败），InnoDB 就会找到这个事务对应的 Undo Log 记录链。它会沿着这个链条，读取每一条 Undo Log 信息，执行其中记录的“反向操作”，从而精确地将该事务所做的所有修改都撤销掉，恢复到事务开始前的状态。就像厨师拿出“取消订单”的便条，一步步把准备好的食材放回原处。

4. MVCC 实现一致性读：寻找合适的历史版本
• 流程： 当一个事务需要读取数据时（例如执行 SELECT），为了实现隔离性，它不能读到其他尚未提交事务所做的修改。InnoDB 会为这个读事务创建一个“读视图”（Read View），这个视图定义了在它开始时，哪些事务的修改是对它可见的，哪些是不可见的。
• 当读取某一行数据时，InnoDB 会检查该行记录头部的 DB_TRX_ID（最后修改它的事务ID）。
• 如果这个事务ID对当前读事务的 Read View 是可见的（比如是读事务自己做的修改，或者是在读事务开始前就已经提交的事务），那么就直接读取这一行的当前值。
• 如果这个事务ID太新了，对当前 Read View 不可见（比如是一个并发的、尚未提交的事务做的修改），InnoDB 就会顺着行记录的 DB_ROLL_PTR 指针，找到对应的 Undo Log 记录。利用 Undo Log 中的信息，它可以在内存中重建出该行的上一个版本。然后，它会检查这个重建出的“旧版本”的 DB_TRX_ID，再次根据 Read View 判断是否可见。这个过程会沿着 Undo Log 版本链一直回溯，直到找到一个对当前 Read View 可见的版本为止。
• 效果： 这就像你想看原始菜谱，但发现当前页面上有个厨师正在用透明纸（进行中的修改）覆盖着写写画画。你就可以根据旁边的“历史版本说明”（Undo Log 指针），找到并查看下面那张原始的、或者更早的、对你来说有效的菜谱版本。这保证了读操作不会被写操作阻塞，并且能读到一致性的数据快照。

5. Undo Log 与 Redo Log 的协作：确保“后悔药”本身的安全
• 关键点： 对 Undo Log 本身的所有操作（比如写入一条 Undo 记录，修改数据行的 DB_ROLL_PTR 指针）也都是物理层面的修改，它们同样受到 Redo Log 的保护！
• 意义： 这意味着即使系统崩溃，Undo Log 的信息也不会丢失。在恢复时，Redo Log 会确保 Undo Log 的状态是正确的。这样，那些在崩溃时还未完成的事务，就可以在系统重启后，利用恢复好的 Undo Log 信息被正确地回滚。

6. 清理（Purge）：回收过期的“修改痕迹”
• 机制： 当一个事务提交后，它产生的 Undo Log 记录并不会立即被删除。因为可能还有其他更早启动的事务，在其 Read View 中仍然需要这些旧版本的数据来实现一致性读。
• InnoDB 有一个后台的 Purge 线程，它会定期检查 Undo Log。当确定某个 Undo Log 记录所代表的数据版本，已经不再被任何活跃的事务（的 Read View）需要时，Purge 线程就会安全地将其删除，回收空间。
• 类比： 就像后厨有专门的清洁工，在确认没人再需要参考那些旧的、作废的草稿纸或修改痕迹记录后，会把它们清理掉。

• 两大核心功能： 事务原子性（通过回滚实现）和事务隔离性（通过 MVCC 实现）。

• MVCC 与 Read View： 理解 Read View 的概念对于掌握不同隔离级别（如 READ COMMITTED, REPEATABLE READ）下的读行为至关重要。

• 逻辑日志： Undo Log 本质上存储的是逻辑上的“如何撤销”信息，这与 Redo Log 的物理页面修改记录不同。

• 存储位置（Undo Tablespaces）： Undo Log 存储在 Undo 段（Segments）中，这些段位于 Undo 表空间内。可以通过 innodb_undo_tablespaces 等参数配置使用共享表空间（ibdata1）中的 Undo 空间，还是使用独立的 Undo 表空间文件（.ibu 文件，推荐方式）。

• Purge 延迟与 History List Length： 如果有长时间运行的事务，或者 Purge 操作跟不上 Undo Log 的产生速度，会导致 Undo 空间持续增长，并且系统中需要维护的版本链变长（History List Length 增大，可在 SHOW ENGINE INNODB STATUS 中查看）。这会影响性能，特别是对于需要查找旧版本数据的读操作。监控 History List Length 是判断 Undo 系统健康状况的重要指标。

• 长事务的影响： 长时间运行的事务（尤其是那些执行了 DML 操作但长时间不提交/回滚的事务）是 Undo Log 空间膨胀和 Purge 滞后的主要原因之一，应尽量避免。

• 当你需要取消订单（事务回滚）时，它告诉你如何一步步撤销所有操作，保证了工作的原子性。

• 当很多人同时在厨房工作，有人在修改菜谱，有人在查阅时，它通过提供历史版本（MVCC），让查阅者能看到一个一致的、不受干扰的版本，保证了隔离性，并提高了并发性能（读写不阻塞）。

• 它记录的是“如何退回上一步”的逻辑信息，并且它自身的安全也由 Redo Log 来保障。

• 后台的清洁工（Purge 线程）负责清理不再需要的旧版本记录。

1. 保证一致性 (C)：靠多方面协同
• 原理： 一致性是一个更宏观的目标，它依赖于其他三个 ACID 特性以及数据库本身的约束。
• 如何工作：
• 原子性保证了不会出现只改一半数据导致不一致的情况。
• 隔离性保证了并发事务不会把数据改乱，破坏一致性规则。
• 持久性保证了成功事务的结果不会丢失，维持了最终的一致状态。
• 数据库自身约束： 如主键约束、外键约束、唯一性约束、CHECK 约束 (MySQL 8.0.16+ 支持)、数据类型检查等，这些在事务执行过程中也会进行检查，防止非法数据写入，从而保证一致性。
• 效果： 通过事务机制和数据库约束共同作用，确保数据总是符合预设规则。

2. 保证隔离性 (I)：靠 锁 (Locking) 和 MVCC (Multi-Version Concurrency Control) (多版本并发控制)
• 原理： 为了让并发事务互不干扰，需要机制来控制它们对数据的访问。
• 如何工作：
• 锁 (Locking)： 当一个事务要修改数据时，InnoDB 会给相关数据（可能是行、可能是间隙）上锁。其他事务如果想修改同一个被锁住的数据，就必须等待锁释放。这是一种比较悲观的方式。
• MVCC (多版本并发控制)： 这是 InnoDB 处理读操作的核心。它通过保存数据在某个时间点的快照 (Snapshot) 来实现的。当一个事务需要读取数据时，它不会去读被其他事务锁住的、正在修改的数据，而是去读这个数据的一个历史版本（快照）。这样，“读”操作就不会被“写”操作阻塞，“写”也不会被“读”阻塞，大大提高了并发性能。MVCC 的实现依赖于 Undo Log (用来构建历史版本) 和一些额外的版本信息。
• 隔离级别： MySQL 还提供了不同的事务隔离级别（读未提交、读已提交、可重复读（默认）、串行化），允许用户根据业务需求在性能和隔离严格性之间做权衡。不同的级别下，锁的使用策略和 MVCC 的行为会有所不同。
• 效果： 通过锁机制防止写冲突，通过 MVCC 机制实现读写并发，共同保证了不同事务间的隔离。

1. 速度 vs. 安全：
• 直接修改“主菜谱”（磁盘上的数据文件）：太慢了！ 每次接到一个微小的修改要求（比如记录加了一小撮盐），你都要先找到菜谱的准确页面，小心翼翼地写上备注，再把厚重的菜谱完美地放回原位。这就像随机磁盘I/O，严重拖慢效率。
• 只在“脑子里记”（内存/Buffer Pool）：非常快，但太危险！ 如果厨房突然断电（服务器崩溃），你脑子里记住的所有信息、那些还没来得及永久记录下来的订单细节，就全都丢失了！

1. 预写式日志 (Write-Ahead Logging - WAL): 黄金法则
• 核心思想： 在厨师动手去修改主菜谱（磁盘上的数据页）之前，他必须先在这本特殊的工作日志（redo log）里，准确记录下“我将要做什么修改”。
• 重要性： 如果厨房突然断电（服务器崩溃），等电力恢复后，副厨师们只需要拿起这本工作日志。他们不需要猜测当时发生了什么。他们从上一个已知的安全时间点开始，读取之后记录的笔记，然后在主菜谱上“重做”这些操作，就能将菜谱恢复到断电前所有已成功下单（已提交事务）的状态。
• MySQL 术语： InnoDB 在允许 Buffer Pool（内存缓冲区）中被修改的数据页写回磁盘上的数据文件之前，会先将描述这些物理变更的记录写入 redo log 文件。

2. 顺序写入：风驰电掣！
• 工作方式： 向这本日志本写入是按顺序的，就像写日记一样，一行接一行，或者像磁带录音一样。厨师不会跳来跳去地写，总是在末尾添加新的记录。
• 优势： 磁盘的顺序 I/O 速度远超随机 I/O。这就像写日记比在百科全书里到处翻页做笔记快得多。这使得事务的“提交”动作可以非常迅速地完成（至少日志记录本身很快）。
• MySQL 术语： 对 redo log 文件（如 ib_logfile*）的写入是追加模式的顺序操作，磁盘处理这种操作效率极高。

3. Redo Log Buffer：临时的“草稿区”
• 运作机制： 即便是顺序写入磁盘也需要一点时间。为了进一步提速，厨师可能会先把笔记快速写在旁边的小白板（内存中的 redo log buffer）上，然后在稍后某个时刻（比如订单确认完成时，或者小白板快写满时）再一次性、成批地抄写到那本主要的工作日志（磁盘上的 redo log 文件）里。
• 好处： 写入内存几乎是瞬时的。这在很大程度上让事务提交的速度与直接的磁盘写入速度“解耦”。
• MySQL 术语： Redo log 条目首先被写入由 innodb_log_buffer_size 参数定义的内存缓冲区。然后，根据特定的触发条件（如事务提交、缓冲区满、后台线程定时任务等），这些日志条目会被“刷”（flush）到持久化的 redo log 磁盘文件中。

4. 记录物理变更：“只记录事实，不讲故事”
• 记录内容： 日志本上记的不是完整的操作说明（“给第52页的红酒炖牛肉加5克盐”），而是非常精确、底层的指令（“在数据页编号 Z 的偏移量 Y 处，将字节值从 X 改为 W”）。
• 原因： 这使得在系统崩溃恢复时“重放”日志变得非常快，并且是“幂等”的（即同一条日志记录即使被重复应用多次，效果也和只应用一次完全相同）。恢复过程不需要解析复杂的 SQL 或执行业务逻辑。
• MySQL 术语： Redo log 存储的是对数据页面的物理更改，而不是逻辑上的 SQL 语句（这与通常记录 SQL 语句的 binary log 不同）。

5. 循环使用文件：旧的不去，新的不来
• 文件管理： 厨师的工作日志不是无限大的。他可能只有固定数量的几本（比如两个大活页夹）。当写满第一本后，他会开始写第二本。当第二本也写满后，他会回到第一本的开头去写，但前提是：第一本里记录的那些旧修改，所对应的菜谱内容必须已经确认被安全地、永久地更新到了主菜谱上。
• 目的： 防止 redo log 文件无限增长，占用过多磁盘空间。
• MySQL 术语： Redo log 由一组固定大小的文件组成（数量由 innodb_log_files_in_group 定义，每个文件的大小由 innodb_log_file_size 定义，例如 ib_logfile0, ib_logfile1）。InnoDB 按顺序写入这些文件。当写到最后一个文件的末尾时，它会绕回到第一个文件，从头开始覆盖旧的日志记录。覆盖的前提是，这些旧记录所对应的、在内存中被修改过的数据页（dirty pages）已经被“刷”到磁盘上的数据文件里了。这个过程由“检查点”（Checkpoint）机制管理。

6. 检查点 (Checkpoint)：标记安全进度
• 作用： 厨师长会周期性地宣布：“好了，日志本上记录到这个时间点的所有修改，都百分之百已经更新到主菜谱上了！” 这个时间点就是“检查点”。
• 意义： 这告诉崩溃恢复程序：“检查点之前的日志你都不用管了，因为它们对应的更改已经安全落盘了。” 同时，检查点也让系统知道 redo log 文件中的哪些部分可以被安全地覆盖重用。
• MySQL 术语： Checkpointing 过程涉及到将 Buffer Pool 中被修改过的页（dirty pages）刷写到磁盘，然后记录一个重要的标记点——即“尚未被刷到磁盘的最旧的那个修改”对应的日志序列号（LSN）。这个检查点 LSN 标志着崩溃恢复需要从哪里开始向前扫描 redo log。

7. 日志序列号 (Log Sequence Number - LSN)：全局唯一的“进度尺”
• 概念： 写入 redo log 的每一个字节都会推进一个全局的、单调递增的计数器——LSN。你可以把它想象成一个永不后退的、极其精确的“页码+行号”组合。内存中的每个数据页也知道自己最后一次被修改是对应到哪个 LSN。
• 重要性： LSN 把所有东西都串联起来了。检查点的 LSN 告诉我们安全恢复的起点。通过比较数据页头部的 LSN 和检查点 LSN，可以判断磁盘上的这个数据页是否可能已经过时。在崩溃恢复时，InnoDB 正是利用 LSN 来精确判断哪些 redo log 记录需要被重新应用到哪些数据页上。
• MySQL 术语： LSN 是 InnoDB 中一个非常基础且重要的概念。它是一个不断增长的整数，代表了 redo log 已经产生的总量。它被记录在 redo log 条目中，也记录在每个数据页的头部，是实现崩溃恢复和管理 redo log 循环的关键。

• 持久性级别控制 (innodb_flush_log_at_trx_commit)： 这可能是与 redo log 相关的最关键的调优参数。直接影响性能和数据安全性。
• 1 (默认值)：完全符合 ACID 的 D（持久性）要求。 每个事务提交时，redo log buffer 的内容会被写入并强制刷到（fsync） 磁盘。最安全，但可能因为频繁的磁盘同步操作而牺牲一些性能。即使操作系统崩溃或服务器断电，也能保证已提交的事务数据不丢失。
• 2：事务提交时，redo log buffer 的内容会写入到磁盘（实际是写入操作系统的缓存），但不保证立即刷盘，而是依赖操作系统大约每秒一次的频率刷盘。比 1 快，但如果操作系统崩溃或服务器断电，可能会丢失最近一秒内提交的事务数据（MySQL 服务自身崩溃通常是可恢复的）。
• 0：事务提交时不做任何操作，redo log buffer 的内容大约每秒由后台线程写入并刷盘一次。速度最快，但在 MySQL 服务崩溃、操作系统崩溃或服务器断电时，可能会丢失最多一秒内提交的事务数据。

• Redo Log 文件大小 (innodb_log_file_size, innodb_log_files_in_group)： 总大小很重要。
• 太小： 可能导致过于频繁的检查点（因为日志空间很快写满需要循环），引发 I/O 尖峰，影响性能平稳性。但好处是崩溃恢复可能更快（需要扫描的日志量少）。
• 太大： 可以更好地“缓冲”写入压力，平滑 I/O 峰值，可能在高并发写入场景下获得更好的性能。但缺点是崩溃恢复时需要扫描和重放更多的日志，恢复时间可能更长。现代建议通常倾向于设置较大的 redo log（总大小达到几个 GB 甚至几十 GB），尤其是在写入密集型负载和使用快速存储（如 SSD）的情况下。

• Redo Log Buffer 大小 (innodb_log_buffer_size)： 控制内存缓冲区的大小。如果你的事务很大（一次修改很多数据），或者并发连接数很高，产生了大量日志，那么增大这个缓冲区可以减少因等待缓冲区空间或等待刷盘（尤其在 innodb_flush_log_at_trx_commit=1 时）而造成的性能瓶颈。但也不宜设置过大，通常 16MB 到 128MB 就能满足大部分场景，除非有明确证据表明需要更大。

• 崩溃恢复 (Crash Recovery)： Redo log 只用于系统崩溃后的恢复过程。它的作用是将数据文件状态前滚，确保那些在崩溃前已经提交但其对应的数据页修改可能还留在内存（Buffer Pool）里没来得及写回磁盘的事务，其修改能够被重新应用到数据文件上。恢复是从最后一个检查点开始向前扫描 redo log。 （这与 undo log 不同，undo log 用于回滚未提交的事务，以及实现 MVCC 多版本并发控制）。

• 组提交 (Group Commit)： 为了优化 innodb_flush_log_at_trx_commit=1 时的性能，MySQL 会尝试将多个并发提交的事务的 redo log 刷新操作“组合”在一起，用一次 fsync() 调用完成多个事务的日志刷盘，从而提高整体吞吐量。

• Undo Log 解决了“如果做错了或者需要看旧版本怎么办”的问题，保障了原子性和隔离性。 它确实是关于“回退”和“版本”。

• Redo Log 解决了“如果刚做完就断电了怎么办”以及“怎么能做得更快”的问题，保障了持久性和高性能。 它主要是关于“前进恢复”和“效率”

• 场景： 假设主厨（事务 A）正在阅读“招牌红烧肉”的菜谱（SELECT 操作），准备确认食材用量。与此同时，一个新来的帮厨（事务 B）被告知需要更新这道菜谱里的糖量（UPDATE 操作）。

• 没有 MVCC 的旧方法（简单加锁）：
• 方法1 (读锁): 主厨 A 先给菜谱加个“阅读锁”，在他读完之前，帮厨 B 就算想改也不能动手，只能干等着。效率低！
• 方法2 (写锁): 帮厨 B 先给菜谱加个“修改锁”，在他改完（并决定是否最终确认这次修改）之前，主厨 A 就算想看也不能看，也得等着。效率同样低！
• 结果： 这种“你要用，我就不能用；我要用，你就不能用”的方式，严重限制了厨房的工作效率（数据库的并发性能）。

1. 核心思想：多版本共存，各取所需
• 理念： 与其粗暴地锁住整个菜谱，不如允许同一份菜谱（同一行数据）同时存在多个“版本”。修改者创建新版本，而读取者根据自己“开始工作的时间点”，去读取那个时间点有效的旧版本。
• 比喻： 帮厨 B 要改糖量时，他不会直接在原始菜谱上涂改。

2. 行版本控制：创建新版本
• 过程： 帮厨 B 拿到一张透明的覆盖纸，把它铺在原始菜谱页面上。他在这张覆盖纸上写下新的糖量。同时，他在这张覆盖纸上做了两个标记：
• “本次修改由 B 完成 (事务ID B)” (对应行的隐藏列 DB_TRX_ID)
• “这张纸下面的原始版本在这里 (指向原始菜谱页/Undo Log记录)” (对应行的隐藏列 DB_ROLL_PTR)
• 结果： 现在，“红烧肉”菜谱有了两个“版本”：覆盖纸上的新版本（帮厨 B 的修改结果）和覆盖纸下面的原始版本。注意： 实际上，旧版本的数据是存储在 Undo Log 中的，DB_ROLL_PTR 指针指向 Undo Log 记录。

3. 读视图（Read View）：我的“时间快照”
• 概念： 每个厨师（事务）在开始一项需要一致性视图的任务时（比如主厨 A 开始阅读菜谱时），会得到一个“厨房当前状态快照”（Read View）。这个快照告诉他：“在你开始这一刻，哪些厨师的工作成果（已提交事务）是你看得到的，哪些正在进行中或还未开始的（未提交事务）你是看不到的。”

4. 读取过程：按“快照”选择版本
• 主厨 A（他的“时间快照”是在帮厨 B 修改之前生成的）过来读菜谱。他看到了最上面的覆盖纸（帮厨 B 的新版本）。
• 他查了一下自己的“快照”，发现“事务 B”对他来说是不可见的（因为 B 的修改在他快照生成之后才发生，或者 B 还没提交）。
• 于是，主厨 A 忽略这张覆盖纸，顺着上面的标记（DB_ROLL_PTR 指针），找到了并读取了覆盖纸下面的原始菜谱版本（或者通过 Undo Log 重建出那个他应该看到的旧版本）。
• 关键： 主厨 A 读取到了他事务开始时的一致性数据，并且没有被帮厨 B 的修改操作所阻塞！
• 另一个场景： 如果另一位厨师 C 在帮厨 B 提交了他的修改之后才开始读取，那么厨师 C 的“时间快照”会认为“事务 B”是可见的。当厨师 C 看到覆盖纸时，他会直接读取覆盖纸上的新糖量，因为这个版本对他来说是有效的。

5. 写入过程：
• 帮厨 B（写入者）在创建新版本（写覆盖纸）时，仍然需要短暂地锁定一下菜谱页面本身（物理页的锁或行锁），以防止其他帮厨同时在同一页上涂改导致物理性损坏。但这通常非常快。关键在于，这个短暂的写锁定通常不会阻塞那些只需要读取旧版本的读者（像主厨 A）。

• 核心优势：读写并发。 极大地提高了数据库在混合读写负载下的性能，尤其是“读不阻塞写，写不阻塞读”。

• 一致性读： 保证了在一个事务（或语句，取决于隔离级别）中读取的数据，是来自某个特定时间点的一致性快照。

• 依赖 Undo Log： MVCC 的实现高度依赖 Undo Log 来存储行的旧版本数据，供需要旧版本的读事务查询。

• 隐藏列： 数据行中通常包含隐藏的 DB_TRX_ID (创建该版本的事务ID) 和 DB_ROLL_PTR (指向前一个版本的 Undo Log 记录的指针) 等字段，用于版本链管理。

• 隔离级别： MVCC 是实现 SQL 标准中的 READ COMMITTED（读已提交）和 REPEATABLE READ（可重复读）隔离级别的基础技术。

• 潜在成本：
• 需要存储 Undo Log，如果存在长事务，可能导致 Undo 空间膨胀。
• 读取旧版本时，需要额外的 CPU 开销去遍历版本链和从 Undo Log 重建数据。

1. m_ids (活跃事务 ID 列表): 一个列表，记录了在创建 Read View 时，系统中所有正活跃且未提交的事务的 ID。
• 比喻： 眼镜上附带的小纸条写着：“注意，厨师 B、D、F 正在忙，他们的活儿还没干完（事务未提交）。”

2. m_up_limit_id (高水位事务 ID): 创建 Read View 时，系统中将要分配给下一个新事务的 ID。任何事务 ID 大于或等于这个值的，都意味着它是在 Read View 创建之后才开始的，因此其所做的修改对于持有该 Read View 的事务来说是绝对不可见的。
• 比喻： 纸条上写着：“等厨师 G 开始干活时，他的工单号是 105。所有工单号是 105 或更大的，对你来说都还没发生。”

3. m_low_limit_id (低水位事务 ID): 创建 Read View 时，系统中活跃事务列表 m_ids 中最小的事务 ID。任何事务 ID 小于这个值的，都表示它在 Read View 创建时就已经提交或回滚了（是很久以前就完成的事务），因此其所做的修改对于持有该 Read View 的事务来说是绝对可见的。
• 比喻： 纸条上写着：“目前正在忙的厨师里，工单号最小的是厨师 B（假设是 98）。所有工单号小于 98 的活儿，肯定早就干完了。”

4. m_creator_trx_id (创建者事务 ID): 创建这个 Read View 的事务自身的 ID。
• 比喻： 纸条上写着：“这是你（厨师 A）自己的工单号（假设是 101）。”

1. 是我自己改的吗？ row_trx_id 是否等于 m_creator_trx_id？
• 是：可见！（自己做的修改当然能看到）

2. 是不是太旧了（在我开始前就完成了）？ row_trx_id 是否小于 m_low_limit_id？
• 是：可见！（这个修改在我拿到眼镜前早就完成了）

3. 是不是太新了（在我开始后才启动）？ row_trx_id 是否大于或等于 m_up_limit_id？
• 是：不可见！（这个修改是在我拿到眼镜后才发生的）

4. 是不是在我拿到眼镜时还在忙？ （此时 m_low_limit_id <= row_trx_id < m_up_limit_id）检查 row_trx_id 是否在 m_ids (活跃事务列表) 中？
• 是：不可见！（这个修改是我拿到眼镜时，那个厨师还在忙活，没提交呢）
• 否：可见！（这个修改的厨师在我拿到眼镜时已经完工了，虽然他开始得可能比较晚，但在那一刻他已经提交了）

• READ COMMITTED (读已提交): 每执行一条 SELECT 语句时，都会创建一个新的 Read View。
• 效果： 在同一个事务中，两条相邻的 SELECT 语句可能会看到不同的数据，因为它们使用了不同的 Read View，中间可能有其他事务提交了。这就是为什么 RC 级别下会有不可重复读。

• REPEATABLE READ (可重复读): 只有在事务中的第一个读取操作（SELECT）发生时，才会创建一个 Read View。之后该事务中所有的读取操作，都会复用这同一个 Read View。
• 效果： 在整个事务期间，看到的总是一致的数据快照（事务开始时的样子），不会看到其他事务在此期间提交的修改。这就避免了不可重复读。（前面说过，InnoDB 通过额外加锁通常还能避免幻读）。

锁