数据库架构指的是数据库系统内部各组件的组织方式与协作逻辑，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 层专注调度。
