MySQL InnoDB存储引擎架构底层实现详细介绍

一、InnoDB存储引擎概述

InnoDB存储引擎最早由Innobase Oy公司开发（创始人HeikkiTuuri，芬兰赫尔辛基），被包括在MySQL数据库所有的二进制发行版本中，从MySQL5.5版本开始是默认的表存储引擎（之前的版本InnoDB 存储引擎仅在WindoWs下为默认的存储引擎）。

InnoDB存储引擎是第一个完整支持ACID事务的MySQL存储引擎（BDB是第一个支持事务的MySQL存储引擎，现在已经停止开发），其特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读，同时被设计用来最有效地利用以及使用内存和CPU。

二、InnoDB存储引擎架构

InnoDB的架构分为后台线程、内存结构和磁盘结构三大部分，协同完成数据的高效存储、事务处理和并发控制。

三、后台线程

后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存的是最近的数据。此外将已修改的数据文件刷新到磁盘文件，同时保证在数据库发生异常的情况下InnoDB能恢复到正常运行状态。

InnoDB存储引擎是多线程的模型，其后台有多个不同的后台线程，负责处理不同的任务。

1. Master Thread

Master Thread是一个非常核心的后台线程，具有最高的线程优先级别。主要负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性，包括脏页的刷新、变更缓冲（Change Buffer）、undo页的回收等。

MasterThread内部由多个循环组成：主循环（loop）、后台循环（backgroup loop）、刷新循环（flush loop）、暂停循环（suspend loop）。在主循环内有两大部分的操作，分别是每隔1秒和10秒的操作：

• 每1秒执行一次的操作：

  • 刷新重做日志缓冲区（Redo Log Buffer）中的内容写入磁盘，即使事务没有提交。（总会执行）
  • 将变更缓冲区中的数据合并到辅助索引页中（减少随机I/O）。（可能执行，在前1秒IO操作次数小于5次触发执行）
  • 刷新100个（默认）脏页数据到磁盘。（可能执行，在脏页数据数量大于参数innodb_max_dirty_pages_pct值触发执行）
  • 切换为后台循环（Background Loop）。（可能执行，当检测到无用户活动或数据库关闭）

• 每10秒执行一次的操作：

  • 刷新100个（默认）脏页数据到磁盘。（可能执行，在前10秒IO操作次数小于200次触发）
  • 合并变更缓冲区数据。（总会执行）
  • 刷新日志缓冲区数据到磁盘。（总会执行）
  • 删除无用的undo页。（总会执行）
  • 刷新100个或10个（默认）脏页数据到磁盘。（总会执行，根据缓冲池中脏页比例buf_get_modified_ratio_pct判断，大于该比例则刷新100个，小于则10个脏页数据）
  • 检查并优化自适应哈希索引的性能。
  • 收集并更新表的统计信息（如行数、索引分布）。

2. IO Thread

• 使用AIO（Async IO）来处理异步I/O操作，支持多线程并行操作，AIO通过合并多个IO操作为单个操作，极大的提升吞吐量。
• 主要有四种线程类型：
  • change buffer thread：负责将变更缓冲内容刷新到磁盘。
  • log thread：负责将日志缓冲区内容刷新到磁盘。
  • read thread：负责读取操作，将数据从磁盘加载到缓存page页。
  • write thread：负责写操作，将缓存脏页刷新到磁盘。在 MySQL 5.6 版本后，脏页刷新操作由独立 Page Cleaner Thread 完成。
• InnoDB1.0版本之前固定4个IO Thread，在InnoDB1.0版本开始可通过参数innodb_read_io_threads和innodb_write_io_threads来设置读写线程数。

3. Purge Thread

• 事务提交后，回收无用的Undo日志（不再需要的版本）。
• InnoDB1.1版本引入，在InnoDB1.2版本可通过参数innodb_purge_threads来配置启动线程数。目的是为了减轻Master Thread的工作，从而提高CPU的使用率以及提升存储引擎的性能。

4. Page Cleaner Thread

• 将脏页数据放入到单独的线程中刷新到磁盘，脏页数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能达到redo log循环使用的目的。
• InnoDB1.2版本引入，可通过参数innodb_page_cleaners来配置启动线程数。目的是为了减轻Master Thread的工作及对于用户查询线程的阻塞，进一步提高InnoDB的性能。

---

四、内存结构

InnoDB的内存架构以 缓冲池（Buffer Pool） 为核心，辅以日志缓冲区、数据字典缓存、锁系统、事务信息等模块，共同实现高性能的数据访问、事务处理及并发控制。

1. 缓冲池（Buffer Pool）

缓冲池（Buffer Pool）是 InnoDB 最核心的内存区域，主要用于缓存磁盘上的数据页（默认 16KB），包括数据页、索引页、undo 页、插入缓冲页等，以达到减少磁盘 I/O，提升查询和更新操作的性能。

1.1. 存储内容

1.1.1. 数据页（Data Page）

存储表的实际数据行，每个数据页包含多行数据，默认页大小为16KB。

1.1.2. 索引页（Index Page）

存储表的索引结构，包括主键索引（聚集索引）和辅助索引（二级索引）。

1.1.3. 变更缓冲区（Change Buffer）

变更缓冲区（Change Buffer）是由插入缓冲区（Insert Buffer）演变而来，主要缓存了对 二级索引页 的修改操作（如插入、更新、删除），避免直接访问磁盘。

适用场景：

• 适用于写密集型操作（如批量插入）。
• 当目标页不在缓冲池中时，合并多次写入操作，减少随机 I/O。

工作流程：

1. 修改操作发生时，若目标页未命中缓冲池，则将变更操作记录到 Change Buffer。
2. 后台线程定期将 Change Buffer 中的变更合并到目标页（Merge 操作）。
3. 目标页被访问时，自动触发 Merge 操作。

核心参数：

innodb_change_buffer_max_size = 25%  # 默认最大占用缓冲池的 25%

1.1.4. 自适应哈希索引（Adaptive Hash Index）

自适应哈希索引（Adaptive Hash Index）就是当某个键值被频繁访问时，InnoDB会自动为其创建生成哈希索引，加速对 热点数据的等值查询。

局限性：仅支持等值查询（如 WHERE id=1），不支持范围查询。

禁用方式： 通过配置innodb_adaptive_hash_index = OFF禁用自适应哈希索引

1.1.5. 数据字典信息（Data Dictionary）

• 存储表、列、索引、外键等元数据（MySQL 8.0后由独立数据字典管理，支持更灵活的元数据操作）。
• 通过information_schema或mysql.innodb_table_stats等系统表访问。

1.1.6. 锁信息（Lock Info）

• 行锁（Record Lock）：锁定索引记录，支持乐观锁和悲观锁。
• 间隙锁（Gap Lock）：锁定索引间隙，防止幻读（RR隔离级别下生效）。
• 表锁（Table Lock）：用于DDL操作或全局锁（如FLUSH TABLES WITH READ LOCK）。

1.1.7. 事务信息

• 事务ID（TRX_ID）：唯一标识活跃事务，支持MVCC（多版本并发控制）。
• 回滚段（Rollback Segment）：存储Undo日志，用于事务回滚和快照读（通过innodb_rollback_segments配置）。
• Undo表空间：存储历史版本数据，支持长事务和崩溃恢复。

---

1.2. 管理策略

缓冲池通过采用改进的 LRU算法（Least Recently Used，最近最少使用） 进行管理。即最频繁使用的页保存在LRU列表的前端，而最少使用的页保存在LRU列表的尾端。

1.2.1. 缓冲池三大链表

• LRU List：
  • 管理缓存的数据页，确保最常访问的数据在缓存中可用。
  • 当一个数据页被访问时，该数据页会被添加到LRU List。
  • 当一个数据页被LRU List逐出时，该数据页会被添加到Free List。
• Free List：
  • 管理内存中的空闲页面帧，确保有足够的空间加载新的数据页。
  • 当系统启动时，所有的数据页都被添加到Free List。当需要使用某个数据页时会优先从Free List中查找，如果存在则删除，添加到LRU list。
• Flush List：
  • 管理需要刷新到磁盘的脏页（Dirty Page，即被修改但还未写入磁盘的数据页），按修改时间排序，确保数据的一致性和持久性。
  • 当一个数据页被修改后，它会被标记为脏页，并被加入到 Flush List 中。
  • InnoDB 后台线程定期检查 Flush List，通过 Checkpoint 机制 将脏页写入磁盘，防止数据丢失。

1.2.2. LRU列表两个分区

• new列表区：存放频繁访问的热点数据（占 63%，约5/8）。
• old列表区：存放使用较少的数据（占 37%，约3/8）。

1.2.3. LRU列表如何运行

• 新页插入old列表区：
  • 将新页插入到 LRU 列表的 midpoint（默认 5/8 位置） old列表区，而非头部，避免热点数据被频繁淘汰。
  • midpoint 位置可以由参数 innodb_old_blocks_pct 配置。
• old列表区数据淘汰：
  • 当LRU列表空间不足，会先淘汰LRU列表尾部的数据，再将新页数据插入到midpoint位置。
  • 当数据处于old列表区的时间未达到参数innodb_old_blocks_time配置的时间时，会将该数据直接淘汰。
• old列表区转移至new列表区：当old列表区数据时长超过参数innodb_old_blocks_time配置的时间时，会将该数据转移到new列表区，即插入到LRU列表首位成为热点数据。
• new列表区转移至old列表区：由于old列表区的数据不断的刷新转移到new列表区，原来处于new列表区的数据会被持续的推后降级，直到降级到old列表区，最后移出LRU列表。

---

1.3. 核心参数

参数	描述
innodb_buffer_pool_size	指定缓冲池大小（建议设置为系统内存的50%~80%）
innodb_buffer_pool_instances	指定缓冲池实例个数，多实例可减少锁竞争
innodb_buffer_pool_chunk_size	指定每个缓冲池实例的大小
innodb_old_blocks_pct	指定LRU List列表的midpoint位置
innodb_old_blocks_time	指定old列表区的存活时间
innodb_buffer_pool_dump_pct	指定每个缓冲池最近使用的页面读取和转储的百分比。

---

2. 日志缓冲区（Log Buffer）

日志缓冲区（Log Buffer）主要缓存了事务日志（Redo Log 和 Undo Log），减少频繁的磁盘 I/O。

2.1. 存储内容

• Redo Log：记录物理修改操作（如页的更新），用于崩溃恢复。
• Undo Log：记录逻辑反向操作（如旧值），支持事务回滚和 MVCC。
• Bin Log：二进制日志，记录所有对数据库表结构变更和表数据修改的操作。整个数据库级别，针对所有存储引擎。

2.2. 刷新策略

• 事务提交时：根据 innodb_flush_log_at_trx_commit 参数决定是否强制刷盘。
  • 1（默认）：每次提交刷盘（保证 ACID）。
  • 2：每秒刷盘一次（性能优先，可能丢失 1 秒数据）。
  • 0：依赖操作系统定时刷盘（风险较高）。
• 后台线程：定期将日志缓冲区内容刷新到 Redo Log 文件（如每秒一次）。

2.3. 核心参数

参数	描述
innodb_log_buffer_size	指定日志缓冲区大小
innodb_log_file_size	指定redo log日志文件的大小
innodb_flush_log_at_trx_commit	指定事务提交时是否刷盘

---

3. 额外内存池（Additional Memory Pool）

额外内存池（Additional Memory Pool）主要是为 InnoDB 的元数据（metadata）和内部管理结构（如表结构信息、索引元数据、缓冲池（Buffer Pool）的控制块、锁信息等）提供内存空间，避免这些结构直接从操作系统动态分配内存，从而减少内存分配的开销（如系统调用、内存碎片等）。

3.1. 存储内容

• 主要存储 InnoDB 字典缓存（dictionary cache）中的数据。
• 表和列的定义信息（如 CREATE TABLE 语句定义的结构）。
• 索引的元数据（如索引类型、字段顺序、页分布等）。
• 缓冲池的页描述符（每个缓冲池页对应的控制信息）。
• 锁管理器中的锁结构、事务相关的元数据等。

3.2. 性能问题

​​当缓冲池非常大时（如几十GB甚至更大），这些内部数据结构所需的内存也会相应增加。如果这块内存不足，InnoDB可能会尝试从操作系统的内存分配器申请更多内存，可能导致性能下降。

3.3. 核心参数

额外内存池的大小可以由参数 innodb_additional_mem_pool_size 配置。在5.6+版本中，InnoDB通常会自行在Buffer Pool之外分配需要的内存，这个参数已不再重要。

---

五、磁盘结构

InnoDB 的磁盘文件系统是 MySQL 数据库中用于存储数据、日志、配置信息和运行时状态的核心组件。主要包括 参数文件、日志文件、Socket 文件、PID 文件、MySQL 表结构文件 和 InnoDB 存储引擎文件 等。

1. 参数文件

参数文件是 MySQL 的配置文件，用于定义数据库的运行时行为，包括内存分配、日志路径、存储引擎配置等。

常见配置文件：

• Linux 系统：/etc/my.cnf 或 /etc/mysql/my.cnf
• Windows 系统：my.ini

配置文件简单示例：

[mysqld]
# InnoDB 缓冲池大小（核心参数）
innodb_buffer_pool_size = 20G# 共享表空间文件路径
innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:2000M:autoextend# 独立表空间配置
innodb_file_per_table = 1# 重做日志文件配置
innodb_log_group_home_dir = /var/lib/mysql
innodb_log_file_size = 1G
innodb_log_files_in_group = 2# 日志刷新策略
innodb_flush_log_at_trx_commit = 1# 线程并发度
innodb_thread_concurrency = 16

关键作用：

• 控制 InnoDB 的内存分配（如 innodb_buffer_pool_size）。
• 定义表空间文件和日志文件的存储路径及大小。
• 调整事务日志刷新策略以平衡性能与数据安全。

---

2. 日志文件

InnoDB 的日志文件主要用来记录MySQL实例对某种条件做出响应时写入的文件，如错误日志文件、二进制日志文件、慢查询日志文件、查询日志文件等。

2.1. 错误日志（Error Log）

• 核心作用：记录MySQL启动、运行、关闭过程中的错误信息、警告及关键状态信息，是故障排查的首要依据。
• 配置参数：
  • log_error：指定日志路径（如/var/log/mysql/error.log）。
  • log_timestamps：控制时间戳格式（如SYSTEM或UTC）。
• 查看方法：
  • 使用SHOW VARIABLES LIKE 'log_error';定位路径。
  • 通过grep "error" /var/log/mysql/error.log快速筛选错误信息。
• 管理建议：
  • 定期检查，尤其是启动失败时优先分析此日志。
  • 结合logrotate实现日志轮转，避免占用过多磁盘空间。

2.2. 慢查询日志（Slow Query Log）

• 核心作用：记录执行时间超过阈值的SQL语句，用于性能优化和SQL调优。
• 配置参数：
  • slow_query_log：开启/关闭慢查询日志，默认关闭。
  • long_query_time：设置慢查询阈值（默认10秒，高并发场景建议设为0.5秒）。
  • log_queries_not_using_indexes：记录未使用索引的查询。
  • log_throttle_queries_not_using_indexes：限制每分钟记录的未使用索引的SQL数量（如100条/分钟）。
  • long_query_io：记录逻辑读取次数超过阈值的查询。
• 查看与分析：
  • 使用SHOW VARIABLES LIKE '%slow%';定位路径。
  • 使用SHOW STATUS LIKE 'Slow_queries';查看慢查询sql数量。
  • 使用 mysqldumpslow 工具分析日志mysqldumpslow -s al -n 10 /var/log/mysql/slow.log获取执行时间最长的10条SQL。
  • 可将日志输出到表（mysql.slow_log），便于SQL查询分析。
• 生产环境建议：
  • 结合业务场景调整阈值，避免记录过多无关查询。
  • 定期分析，识别频繁执行或资源消耗大的SQL。

2.3. 查询日志（General Query Log）

• 核心作用：记录所有客户端连接和执行的SQL语句（包括SELECT），用于审计和调试。
• 配置参数：
  • general_log：开启/关闭查询日志。
  • general_log_file：指定日志路径（如/var/log/mysql/query.log）。
  • log_output：设置输出格式（FILE或TABLE）。
• 注意事项：
  • 生产环境通常关闭，因日志量极大，可能影响性能。
  • 开启时需谨慎，避免泄露敏感信息。
• 查看方法：
  • 通过SHOW VARIABLES LIKE 'general_log%';查看配置。
  • 使用SELECT * FROM mysql.general_log;查询表格式日志。

2.4. 二进制日志（Binary Log）

• 核心作用：
  • 记录所有数据修改操作（如INSERT、UPDATE、DELETE、DDL），用于主从复制、数据恢复和审计。
  • 支持三种日志格式：STATEMENT（记录SQL语句）、ROW（记录行变化，推荐）、MIXED（混合模式）。
• 配置参数：
  • log_bin：指定二进制日志路径（如/var/lib/mysql/binlog）。
  • binlog_format：设置日志格式（ROW为默认推荐）。
  • expire_logs_days：自动清理日志天数（如7天）。
  • max_binlog_size：控制单个日志文件大小（默认1GB）。
  • sync_binlog：每次事务提交时同步写入磁盘（安全性高）。
• 查看与分析：
  • 通过SHOW VARIABLES LIKE 'log_bin%';查看配置。
  • 使用mysqlbinlog --start-datetime="2025-09-01 00:00:00" binlog.000001解析日志。
  • 结合pt-query-digest进行性能分析。
• 生产环境建议：
  • 开启sync_binlog=1确保每次提交同步磁盘，提升数据安全性。
  • 定期备份和清理旧日志，避免磁盘空间不足。

---

3. Socket文件

• 作用：本地客户端（如mysql命令行）与MySQL服务进程通信的Unix域套接字文件。
• 默认路径：Linux通常为/var/run/mysqld/mysqld.sock，Windows为C:\Program Files\MySQL\Data\mysql.sock。
• 配置方法：在my.cnf中通过socket=/path/to/socket自定义路径。
• 常见问题：路径不匹配或权限不足会导致“无法连接”错误，需检查文件存在性及权限（如chmod 660）。

---

4. Pid文件

• 作用：存储MySQL进程ID（PID），用于进程管理、防止多重启动及监控。
• 默认路径：通常位于数据目录（如/var/lib/mysql/mysqld.pid）。
• 配置方法：通过pid-file=/path/to/pid指定路径。
• 管理场景：
  • 启动失败时检查PID文件是否存在，避免重复启动。
  • 自动化脚本通过读取PID监控服务状态。

---

5. MySQL表结构文件

• 作用：

  • 存储表的 元数据（如列定义、索引信息、视图定义等）。
  • 文件格式为 .frm，每个表对应一个文件（如 table_name.frm）。

• 文件路径：

  • 默认存储在数据库目录下（如 /var/lib/mysql/database_name/）。

• 文件类型：

  • .frm文件：早期版本存储表结构（列、索引、约束等），MySQL 8.0后逐渐被系统表空间替代。
  • 系统表空间（ibdata1）：存储数据字典、撤销日志、变更缓冲等元数据，默认包含所有表结构。
  • 独立表空间（.ibd）：启用innodb_file_per_table=ON后，每张表对应一个.ibd文件，存储数据、索引及表结构元数据。

---

6. InnoDB 存储引擎文件

InnoDB 的存储引擎文件包括 表空间文件 和 重做日志文件，是 InnoDB 数据存储的核心。

6.1. 表空间文件（Tablespace）

InnoDB的表空间分类是MySQL数据库存储管理的核心架构，涵盖系统表空间、独立表空间、通用表空间、临时表空间、Undo Log表空间五大核心类型。主要存储表数据、索引和事务信息等。

6.1.1. 系统表空间（System Tablespace）

• 核心作用：存储元数据（表/索引/列定义）、双写缓冲区、回滚日志、变更缓冲、系统事务数据等全局数据，是InnoDB的默认共享存储区。
• 文件结构：默认文件为ibdata1，可扩展为多个文件（如ibdata1:100M;ibdata2:200M:autoextend），支持裸设备分区提升I/O效率。MySQL 8.0后，数据字典不再保存在系统表空间，但双写缓冲、插入缓冲仍存储于此。
• 配置参数：
  • innodb_data_file_path：定义文件路径、大小及自动扩展策略（如末文件可扩展至最大1GB）。
  • innodb_data_home_dir：指定表空间目录（默认datadir）。
• 版本差异：MySQL 8.0前用户表数据可能存储于此，之后默认启用独立表空间；双写缓冲区（16KB页）防止部分写入失效，确保数据页可靠性。
• 管理要点：碎片化空间无法自动收缩，需通过重建表空间回收；高并发下可能成I/O瓶颈。

6.1.2. 独立表空间（File-Per-Table Tablespace）

• 核心作用：每张表独占一个.ibd文件，存储表数据、索引及元数据，实现表级隔离。
• 配置逻辑：
  • 默认启用（innodb_file_per_table=ON），新表自动创建独立文件；支持DATA DIRECTORY子句指定存储路径（如外部磁盘）。
  • 支持数据在线迁移（表空间传输功能），需满足版本一致、表结构相同等条件。
• 优势：
  • 空间回收：TRUNCATE TABLE或ALTER TABLE ... ENGINE=InnoDB释放空间至文件系统。
  • 迁移灵活：可复制.ibd文件至其他实例，通过ALTER TABLE ... IMPORT TABLESPACE导入。
  • 并发优化：多表写入分散至不同文件，减少共享表空间I/O竞争。
• 限制：只存储了表的索引和数据，但是其他类的数据，如回滚（undo）信息，变更缓冲、索引页、事务信息，二次写缓冲（Double write buffer）等全局数据还是存放在系统表空间内。

6.1.3. 通用表空间（General Tablespace）

• 核心作用：跨数据库共享存储，允许多个表存储于同一.ibd文件，减少元数据内存开销。
• 创建方式：
  • 语法：CREATE TABLESPACE ts ADD DATAFILE '/path/ts.ibd' FILE_BLOCK_SIZE=16K ENGINE=InnoDB。
  • 支持自定义路径（需通过innodb_directories配置目录），避免与独立表空间冲突。
• 优势：
  • 性能优化：减少DROP/TRUNCATE的文件系统开销，提升大批量操作效率。
  • 存储管理：支持表压缩（需统一压缩格式），减少存储占用。
• 管理要点：删除表空间前需先删除所有表；通过ALTER TABLE ... TABLESPACE=转移表。

6.1.4. 临时表空间（Temporary Tablespace）

• 核心作用：存储临时表、排序数据、哈希连接中间结果等临时数据，避免占用永久存储。
• 文件结构：默认文件为ibtmp1（12MB自动扩展），位于数据目录，服务器关闭时自动删除并重建。
• 配置参数：innodb_temp_data_file_path控制路径、大小及扩展策略（如ibtmp1:12M:autoextend:max:1G）。
• 应用场景：支持ORDER BY、GROUP BY、索引创建等操作的临时存储，提升查询效率。
• 监控：通过INFORMATION_SCHEMA.INNODB_TEMP_TABLESPACES查看使用情况。

6.1.5. Undo Log表空间（Undo Log Tablespace）

• 核心作用：存储撤销日志，支撑事务回滚、MVCC（多版本并发控制）及崩溃恢复。
• 存储逻辑：
  • MySQL 8.0后默认独立于系统表空间，文件名为undo_001、undo_002等，支持动态添加（CREATE UNDO TABLESPACE ... ADD DATAFILE）。
  • 每个表空间支持128个回滚段（innodb_rollback_segments），通过innodb_undo_tablespaces控制数量。
• 配置参数：
  • innodb_undo_directory：指定存储目录（默认datadir）。
  • innodb_max_undo_log_size：设置截断阈值（默认1GB），超量时自动回收空间。
• 管理要点：监控工具INNODB_METRICS查看截断状态，SET GLOBAL innodb_monitor_enable=module_undo启用日志。

---

6.2 重做日志文件（Redo Log）

作用：

• 记录物理页的修改操作，用于崩溃恢复（确保事务的持久性）。
• 采用 循环写入 和 检查点（Checkpoint） 机制，避免日志文件无限增长。

文件路径：
默认存储在 innodb_log_group_home_dir 指定的目录下（如 /var/lib/mysql），文件名为 ib_logfile0、ib_logfile1 等。

关键参数：

innodb_log_file_size = 1G     # 每个日志文件大小
innodb_log_files_in_group = 2 # 日志文件组数量
innodb_log_buffer_size = 64M  # 日志缓冲区大小
innodb_loggroup_home_dir = ./  #指定了日志文件组所在路径，默认为./

特点：

• 物理日志：记录数据页的物理修改（如页的更新）。
• 崩溃恢复：在系统重启时，通过 Redo Log 恢复未写入磁盘的已提交事务。