MySQL 数据库架构分为 Server 层和存储引擎层：Server 层负责连接、解析、优化、执行等 SQL 处理，存储引擎层（如 InnoDB、MyISAM）负责实际数据存取，二者通过统一 API 协作，实现灵活扩展与功能解耦。
数据库架构指的是数据库系统内部各组件的组织方式与协作逻辑，MySQL 的基础架构不是单一层级的黑盒，而是分层明确、职责清晰的模块化设计。理解它，关键在于抓住“Server 层”和“存储引擎层”的分工与协作关系。
Server 层：SQL 处理与服务调度中心
这一层是 MySQL 的大脑，不直接碰数据，但负责所有与 SQL 相关的决策和流程控制：
- 连接器：处理 TCP 连接、用户认证、权限加载（权限一旦加载进内存，后续修改需重连才生效）；
- 查询缓存（MySQL 8.0 已默认禁用）：对完全相同的 SELECT 查询返回缓存结果，适合读多写少且语句高度重复的场景；
- 解析器：检查 SQL 语法是否合法，生成解析树；
- 预 处理器：校验表名、列名是否存在，权限是否足够；
- 优化器：决定怎么查最快——比如用哪个索引、多表 join 的顺序、是否走覆盖索引等；
- 执行器：调用存储引擎接口，真正去读 / 写数据，并在返回前做最后的权限校验和日志记录。
存储引擎层：数据存取的实际执行者
这一层是 MySQL 的手脚，只响应 Server 层指令，不理解 SQL，也不参与优化。不同引擎能力差异大：
- InnoDB（默认，5.5 起）：支持事务、行锁、外键、MVCC，索引基于 B+Tree，适合高并发读写混合场景；
- MyISAM：表锁、不支持事务，全文索引较早支持，适合以读为主、低并发统计类应用；
- Memory：数据全在内存，速度快但重启即失，常用于临时表或缓存表。
Server 层通过统一的存储引擎 API 与它们通信，因此上层逻辑无需为引擎切换做适配。
数据如何被一条 SELECT 找到？以 InnoDB 为例
当你执行 SELECT name FROM user WHERE id = 100，实际发生的是：
- 连接器分配线程，验证权限；
- 解析器和优化器确认使用主键索引（id 是主键）；
- 执行器向 InnoDB 发起“按主键查 id=100 的记录”请求；
- InnoDB 在 B+Tree 索引中逐层查找（根→分支→叶子），定位到对应叶子页；
- 从该页中取出整行数据（或仅 name 字段，若命中覆盖索引）；
- 执行器把结果返回客户端。
为什么 这种分层设计重要？
它让 MySQL 兼具灵活性与可扩展性：
- 同一张表可以随时切换引擎（
ALTER TABLE t ENGINE=InnoDB），不影响 SQL 写法； - 新功能（如 JSON 支持、窗口函数）可在 Server 层统一实现，无需每个引擎重复开发；
- 索引、锁、事务等复杂机制由引擎各自实现，InnoDB 做好自己的事，Server 层专注调度。
