【MySQL体系】第1篇：从MySQL架构原理到存储的解析

第 1 节：MySQL 体系架构

MySQL 采用分层架构，各层职责清晰，从客户端到存储介质依次分为四层：

1. 连接层：处理客户端连接，完成 TCP 握手、身份认证（账号密码校验）、权限判断，支持连接池管理减少连接开销；
2. 服务层：MySQL 核心逻辑层，包含 SQL 接口（接收 SQL 指令）、查询优化器（基于成本生成最优执行计划，如选择索引、调整 Join 顺序）、数据字典（存储表结构、列信息等元数据），且与存储引擎解耦；
3. 引擎层：插件式设计，负责数据存储与读写逻辑，不同引擎特性不同，主流为 InnoDB（默认）、MyISAM；
4. 存储层：将引擎层数据持久化到操作系统文件系统（如 EXT4、NTFS），通过文件（如.ibd、.frm）管理数据，依赖 OS I/O 操作。

第 2 节：MySQL 运行机制

核心围绕 SQL 执行流程与关键组件运作，流程如下：

1. SQL 执行流程：客户端发送 SQL→连接层认证→服务层解析 SQL（生成解析树）→查询优化器生成执行计划→引擎层执行计划（读写数据）→存储层持久化→结果返回客户端；
2. 查询优化器：以 "成本最低" 为目标，分析表数据量、索引情况，选择是否走索引、Join 表顺序，无需人工干预（复杂 SQL 需手动调优）；
3. 缓存机制：MySQL 8.0 已移除查询缓存（因缓存失效频繁，性能增益有限），现常用替代方案为应用层缓存（如 Redis）、InnoDB 缓冲池（缓存数据页与索引页）。

第 3 节：MySQL 存储引擎

存储引擎是 MySQL 数据存储的核心，不同引擎适配不同业务场景，以下聚焦主流引擎及 InnoDB 关键特性。

3.1 InnoDB 和 MyISAM 对比

对比维度	InnoDB	MyISAM
事务支持	支持 ACID 特性	不支持
锁机制	行锁（细粒度，高并发）+ 表锁	表锁（粗粒度，低并发）
外键支持	支持	不支持
崩溃恢复	支持（依赖 Redo/Undo Log）	不支持（易丢数据）
适用场景	事务型业务（电商订单、金融）	只读 / 查询密集（日志、报表）
索引类型	聚集索引（数据与索引同文件）	非聚集索引（数据与索引分离）

3.2 InnoDB 存储结构

按 "表空间→段→区→页→行" 五级结构管理数据，从大到小依次为：

1. 表空间：存储表相关数据，分系统表空间（ibdata1，存储数据字典、早期 Undo Log）、独立表空间（xxx.ibd，每张表对应一个，存储表数据、索引、高版本 Undo Log）；
2. 段：表空间的逻辑分区，分数据段（对应聚集索引叶子节点）、索引段（对应二级索引叶子节点）；
3. 区：最小分配单位，大小 1MB（含 64 个连续页），减少 I/O 碎片，提升读写效率；
4. 页：最小 I/O 单位，默认 16KB，类型包括数据页（存储行数据）、索引页（存储索引信息）、Undo 页（存储 Undo Log）；
5. 行：数据存储基本单位，支持 COMPACT、DYNAMIC 等行格式，含 3 个隐藏列（DB_ROW_ID：行 ID，DB_TRX_ID：事务 ID，DB_ROLL_PTR：指向 Undo Log 的指针）。

3.3 InnoDB 线程模型

通过多线程协作处理任务，核心线程包括：

1. 主线程：核心调度线程，负责缓冲池脏页刷盘、Redo Log 写入、合并插入缓冲等后台任务；
2. IO 线程：分读线程（默认 4 个）、写线程（默认 4 个），专门处理磁盘 I/O 请求，避免主线程阻塞；
3. 事务线程：每个事务对应独立线程，处理事务逻辑（如 SQL 执行、锁竞争），事务结束后线程回收或复用；
4. Purge 线程：异步清理已提交事务的 Undo Log，释放磁盘空间，避免 Undo Log 膨胀。

3.4 InnoDB 数据文件

InnoDB 数据存储依赖三类核心文件，功能与对应日志明确：

1. xxx.ibd 文件：独立表空间文件，每张表对应一个，存储表数据、索引、MySQL 5.7 + 版本的 Undo Log；
2. ibdata1 文件：系统表空间文件，默认 1 个（可扩展），存储数据字典、MySQL 5.6 及之前版本的 Undo Log；
3. ib_logfile0/ib_logfile1 文件：Redo Log 专属文件，默认 2 个（循环使用），大小固定（可通过 innodb_log_file_size 配置），保障事务持久性。

3.5 Undo Log

即撤销日志，是 InnoDB 保障事务原子性与 MVCC 的核心：

1. 作用：①事务回滚：记录事务修改前的数据，事务失败时通过 Undo Log 恢复原始数据；②支撑 MVCC：多个事务并发读时，通过 Undo Log 生成数据快照，实现 "读不加锁"；
2. 存储位置：MySQL 5.6 及之前存于 ibdata1，5.7 + 存于对应表的 xxx.ibd；
3. 清理机制：事务提交后不立即删除，由 Purge 线程异步清理（避免影响未提交事务的快照读）。

3.6 Redo Log 和 Binlog

两者均为日志文件，但所属层级、功能不同，共同保障数据安全：

对比维度	Redo Log	Binlog
所属层级	InnoDB 引擎层	MySQL 服务层
记录内容	物理日志（记录数据页修改）	逻辑日志（记录 SQL 语句或行数据变更）
写入时机	事务执行中循环写入（实时）	事务提交后一次性写入
日志大小	固定大小（循环覆盖）	可配置（滚动生成，如按大小 / 时间切割）
核心作用	崩溃恢复（恢复未刷盘事务）	主从复制（同步从库数据）、数据备份恢复
刷盘策略	可通过 innodb_flush_log_at_trx_commit 配置（如 1 = 事务提交即刷盘，最安全）	可通过 sync_binlog 配置（如 1 = 每次提交刷盘）

两者关联：事务提交时需执行 "两阶段提交"------ 先写 Redo Log（prepare 阶段），再写 Binlog，最后标记 Redo Log 为 commit，确保两者数据一致（避免单日志写入成功、单失败导致的数据不一致）。

预告下一篇：MySQL索引原理与优化手段