MySQL可插拔存储引擎架构：把查询处理与数据存储彻底解耦

大多数数据库系统的查询处理逻辑和数据存储方式是紧密捆绑在一起 的，换存储引擎基本等于换数据库。MySQL最独特的设计恰恰是把这 两层彻底切开：服务器最上层负责连接管理和安全认证，和其他网络 服务没什么两样；中间层是MySQL真正的核心——查询解析、优化、 缓存、内置函数，以及触发器、视图、存储过程这些跨存储引擎的 通用功能，全部在这一层实现，完全不关心底层数据具体怎么存； 最下层才是存储引擎，负责数据真正的存取，通过一套包含”开始 事务”“按主键取一行”这类底层操作的标准API和上层通信，存储引擎 之间互不通信、也不解析SQL，只是响应上层请求。这个架构的直接 后果是：MySQL里”选存储引擎”是一个可以按表、按场景单独做的 决策——同一个数据库里，一张表可以用支持事务和行级锁的InnoDB， 另一张只读的历史数据表可以用不支持事务但更轻量的MyISAM，查询 优化器完全不关心某张表具体用的哪个引擎，只是向存储引擎请求 容量、代价、统计信息来辅助优化决策。但这种”每张表各自为政” 的灵活性也带来一个代价：MySQL服务器层本身不管理事务，事务 的实现完全下放到存储引擎层，如果一个事务里混用了InnoDB和 MyISAM这样跨引擎的表，一旦需要回滚，非事务型引擎（MyISAM）上 已经做的修改根本无法撤销，导致数据库进入无法预料的不一致 状态——这正是”把架构决策下放到每张表”这种灵活性，反过来在 “事务边界跨越多个决策单元”时必然要付出的代价。

结构图：

flowchart TD
    A[连接管理与安全性层<br/>认证/权限,与其他网络服务无异] --> B[核心服务层<br/>查询解析/优化/缓存<br/>触发器/视图/存储过程等跨引擎功能]
    B -->|标准存储引擎API<br/>开始事务/按主键取行| C{存储引擎层}
    C --> D[InnoDB<br/>事务/行级锁/MVCC]
    C --> E[MyISAM<br/>无事务/表级锁]
    C --> F[其他引擎]
    D -.跨引擎事务.-> G[非事务型表变更无法回滚<br/>数据库进入不一致状态]
    E -.跨引擎事务.-> G