MySQL 架构总览

MySQL 采用分层架构设计，自上而下分为三大核心层，各层职责清晰、解耦性强，确保不同模块可独立优化。

如何传输数据？连接层的核心逻辑

连接层是 MySQL 与客户端交互的 “门户”，核心解决 “如何安全、高效地建立连接” 问题，主要涉及连接协议、认证机制与数据加密。

主流连接协议对比

MySQL 支持多种连接协议，适配不同场景（本地 / 远程、Windows/Linux），协议实现于客户端库与驱动中。

关键端口说明

• 3306：Classic 协议默认端口（–port 配置）

• 33060：X 协议默认端口（–mysqlx-port 配置）

• 33062：Classic 协议管理员连接端口（–admin-port 配置）

2. 本地连接示例

• Linux 下 Socket 连接（最优选择）：

1
2
3
4

# 使用指定 Socket 文件
mysql -s /var/lib/mysql/mysql.sock -uroot -p
# 使用默认 Socket 文件（/tmp/mysql.sock）
mysql -uroot -p

注意：未指定 –host 时，MySQL 默认用 localhost 触发 Socket 连接；若需 TCP 连接本地，需显式指定 –protocol=tcp，如 mysql -h localhost –protocol=tcp -uroot -p。

• Windows 下 Shared Memory/Named Pipes 连接：

1
2
3
4

# Shared Memory 连接（默认禁用）
mysql --protocol=memory -uroot -p
# Named Pipes 连接
mysql --protocol=pipe -uroot -p

3. SSL 加密：默认的安全保障

• 适用场景：仅 TCP/IP 连接支持 SSL 加密，Socket、Named Pipes 等本地连接不支持。

• 自动配置：若服务器安装 OpenSSL，MySQL 安装器会调用 mysql_ssl_rsa_setup 生成 SSL 密钥（存于数据目录），客户端自动使用密钥加密通信。

• 强制加密：可配置服务器与客户端 “必须使用 SSL”，未启用 SSL 时拒绝连接。

如何处理请求？SQL 层的执行流程

SQL 层是 MySQL 的 “大脑”，负责将客户端发送的 SQL 语句转化为可执行的计划，核心流程遵循 “解析→校验→优化→执行→日志” 五步走。

SQL 层核心组件与执行顺序

1. 解析（Parser）：校验 SQL 语法与语义（如 “表是否存在”“字段是否合法”），将 SQL 转化为标准语法树。
2. 权限校验（Authorization）：检查当前用户是否有 “执行该 SQL” 的权限（如 SELECT 表权限、UPDATE 字段权限）。
3. 优化（Optimizer）：生成最优执行计划 —— 例如选择哪个索引、表连接顺序，目标是最小化 IO 与计算开销。
4. 执行（Query Execution）：调用存储层接口，执行优化后的计划，返回结果。
5. 日志记录（Query Logging）：可选功能，记录服务器接收或执行的 SQL（如慢查询日志、审计日志）。

如何存储数据？存储层与存储引擎

存储层是 MySQL 的 “硬盘管家”，负责数据的物理存储与读取，核心是存储引擎——MySQL 支持多引擎，不同引擎适配不同业务场景。

主流存储引擎对比

存储引擎核心能力对比表

SQL 层与存储层的交互规则

• 引擎无关性：大部分 SQL 语句（如 SELECT、INSERT）不依赖存储引擎，由 SQL 层统一解析后调用存储层接口。

• 引擎相关性：

  • 创建 / 修改表时需指定引擎：CREATE TABLE t (id INT) ENGINE=InnoDB;

  • 部分特性仅特定引擎支持（如事务仅 InnoDB/NDB 支持，哈希索引仅 MEMORY/NDB 支持）。

元数据管理：MySQL 8 的事务性数据字典

元数据是 “数据的数据”，包括表结构、索引定义、用户权限等。MySQL 8 之前依赖 MyISAM 存储元数据（如 .frm 文件），8.0 后全面迁移到 InnoDB，实现事务性数据字典。

元数据类型

• 表定义（CREATE TABLE 语句）

• 存储过程 / 函数定义（CREATE PROCEDURE）

• 视图、触发器、外键约束

• 用户与权限信息（ACL）

MySQL 8 事务性数据字典优势

• 统一存储：所有元数据存于 InnoDB 表，无独立文件（如 .frm），依赖非事务引擎 MyISAM。

• 事务安全：元数据操作（如 CREATE TABLE、DROP INDEX）支持原子性，崩溃后可恢复。

• 易于扩展：提供通用数据字典 API，方便新增元数据类型。

• 优化 INFORMATION_SCHEMA：部分 INFORMATION_SCHEMA 表改为数据字典视图，查询更高效。

InnoDB 表空间：数据存储的 “容器”

InnoDB 用表空间管理数据文件，表空间是存储表、索引、日志的物理文件集合，支持多种类型以适配不同场景。

表空间类型与用途

表空间选择建议

• 独立表空间：适合需单独管理的表（如按表备份、 truncate 回收空间）。

• 通用表空间：适合大量小表（减少文件数量，降低文件系统开销）。

• 自定义路径：可将表空间放在高速设备（如 SSD），提升性能：

1
2
3
4

# 表存于指定目录
CREATE TABLE t (id INT) DATA DIRECTORY '/ssd/datadir';
# 通用表空间存于指定目录
CREATE TABLESPACE ts ADD DATAFILE '/ssd/ts.ibd';

重做与回滚日志：InnoDB 的事务保障

InnoDB 依赖 Redo Log（重做日志） 与 Undo Log（回滚日志） 实现事务的 ACID 特性，是崩溃恢复与多版本并发控制（MVCC）的核心。

Redo Log：崩溃恢复的 “保险”

• 作用：记录数据修改的物理操作（如 “修改表 t 的 id=1 行的 value 为 10”），确保崩溃后未刷盘的修改可恢复。

• 流程：事务执行时，先写 Redo Log 到内存缓冲，再异步刷盘；事务提交时，Redo Log 确保刷盘（可配置刷盘策略）。

• 文件配置：

  • 默认 2 个文件（ib_logfile0、ib_logfile1），由 innodb_log_files_in_group（默认 2）与 innodb_log_file_size 控制大小。

  • 总大小上限 512GB，建议按业务量调整（过大影响恢复速度，过小频繁切换）。

Undo Log：回滚与 MVCC 的 “基石”

• 作用：记录修改前的原始数据，用于：

  • 事务回滚（ROLLBACK 时恢复原始数据）。

  • MVCC 并发控制（其他事务读取 “旧版本” 数据）。

• 存储：默认存于回滚表空间，内部分为 Insert Undo（记录插入操作）与 Update Undo（记录更新 / 删除操作）。

• 临时表特殊处理：临时表的 Undo Log 存于全局临时表空间（ibtmp1），且不写入 Redo Log（崩溃后无需恢复临时表）。

事务修改三大阶段时序

1
2
3
4
5

事务开始
1. 记录 Undo Log：保存原始数据页到 Undo Log（内存）
2. 记录 Redo Log：写入物理修改到 Redo Log（内存缓冲，按策略刷盘）
3. 更新数据页：修改 Buffer Pool 中的数据页（脏页，异步刷盘）
事务提交

内存使用：MySQL 的 “缓存策略”

MySQL 内存分配分为三大类，合理配置内存是提升性能的关键。

内存分配三大类别

核心内存组件：缓冲池（Buffer Pool）

• 作用：InnoDB 最核心的内存组件，缓存数据页与索引页，减少磁盘 IO。

• 刷盘策略：缓冲池中的 “脏页”（修改后未写盘）会在 checkpoint 时异步刷盘，避免影响事务执行。

• 预热机制：服务器关闭时保存部分热点页，重启时恢复，减少冷启动后的 IO 高峰（innodb_buffer_pool_dump_pct 配置）。

插件与组件交互：MySQL 的 “扩展接口”

MySQL 支持插件机制，允许动态扩展功能，无需重启服务器。

插件类型与示例

• 守护进程插件：由服务器直接运行，如线程池插件（thread_pool）、PAM 认证插件。

• 存储引擎插件：第三方存储引擎（如 TokuDB）。

• 功能插件：全文解析插件（如 Japanese MeCab）、SQL 重写插件（rewriter）。

插件核心特性

• 动态加载 / 卸载：通过 INSTALL PLUGIN / UNINSTALL PLUGIN 操作，无需重启。

• 客户端 / 服务器双支持：既支持服务器端插件（如认证），也支持客户端插件（如加密客户端）。

总结

MySQL 架构是 “分层解耦 + 插件扩展” 的经典设计：

• 连接层保障 “安全通信”，SQL 层负责 “智能解析”，存储层实现 “灵活存储”；

• 日志与表空间是 InnoDB 事务与性能的基石；

• 事务性数据字典与插件机制则提升了 MySQL 的可靠性与扩展性。