mysql执行SQL时如何访问存储引擎_mysql分层架构说明

MySQL 执行 SQL 时先经 SQL 接口、解析器、优化器，再通过 Handler API 调用存储引擎；InnoDB 等引擎通过实现 handler 类提供 index_read()等标准方法，内部处理 B + 树遍历、MVCC 等，Server 层不感知。

MySQL 执行 SQL 时怎么走到存储引擎层

SQL 语句最终由存储引擎完成数据的读写，但中间经过多层解析与优化。关键路径是：SQL 接口 → 解析器 → 优化器 → 存储引擎接口（Handler API）→ 具体引擎（如 InnoDB、MyISAM）。你写的 SELECT * FROM t WHERE id = 1 不会直接传给 InnoDB；MySQL Server 层先生成执行计划，再通过统一的 handler 接口调用引擎的 index_read()、rnd_next() 等方法。

• 所有引擎都必须实现 handler 类（C++），暴露标准函数供 Server 层调用
• InnoDB 的实际 数据访问（如 B+ 树遍历、MVCC 判断可见性）完全在引擎内部，Server 层不感知
• EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE（8.0.18+）能显示是否真正下推到引擎层，比如 Using index condition 表示 ICP（Index Condition Pushdown）已启用
• 如果查询含 ORDER BY 且无可用索引，Server 层会在内存或磁盘做 filesort，不交给引擎

如何确认某条 SQL 正在使用哪个存储引擎

不能只看表定义，因为执行时可能因查询重写、临时表、派生表等切换引擎。最可靠的方式是结合 information_schema 和运行时状态：

• 查表引擎：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 't';
• 查当前连接正在执行的语句所涉及的表及其引擎：SELECT * FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE '%t%';（需开启相关 consumers）
• 强制观察引擎行为：对 InnoDB 表执行 SELECT * FROM t LOCK IN SHARE MODE，然后在另一个会话查 SELECT * FROM information_schema.INNODB_TRX；MyISAM 不会出现记录，说明它没走事务引擎逻辑
• 临时表默认用 TempTable 引擎（8.0.16+），除非显式指定 CREATE TEMPORARY TABLE …… ENGINE=MyISAM

InnoDB 和 MyISAM 在 SQL 执行路径上的核心差异

差异不在语法层面，而在 Server 层调用 handler 接口时的行为响应。例如同样执行 UPDATE t SET a=1 WHERE pk=5：

• InnoDB 返回 HA_ERR_RECORD_IS_THE_SAME 表示行未变，Server 层跳过更新；MyISAM 总是重写整行，即使值相同
• MyISAM 没有 MVCC，SELECT 直接读磁盘文件（.MYD），加的是表级锁；InnoDB 走聚簇索引 + undo log 版本链判断可见性
• COUNT(*) 在 MyISAM 中是常量（维护在 .MYI 文件头），InnoDB 必须扫描索引（除非覆盖索引 + 优化器估算）
• InnoDB 支持 INSERT …… ON DUPLICATE KEY UPDATE，MyISAM 报错 ERROR 1062 (23000): Duplicate entry

SELECT TABLE_NAME, ENGINE, ROW_FORMAT  FROM information_schema.TABLES  WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME IN ('t_innodb', 't_myisam');

为什么 alter table engine=innodb 可能卡住，以及怎么避免

本质是重建表：MySQL Server 层创建新表结构，逐行从旧表读取、经 InnoDB handler 写入新表。卡点通常不在 SQL 解析，而在引擎层的物理操作：

• 大表上 ALTER TABLE …… ENGINE=InnoDB 会触发全量 DML（非原子 DDL 前），期间阻塞 DML，且产生大量 redo / undo 日志
• 若原表是 MyISAM，没有事务保障，中途失败会导致两个表都损坏（旧表被删、新表未完成）
• 8.0 默认使用 ALGORITHM=INPLACE，但 ENGINE 变更强制走 COPY 模式，无法跳过拷贝
• 替代方案：CREATE TABLE t_new LIKE t_old; ALTER TABLE t_new ENGINE=InnoDB; INSERT INTO t_new SELECT * FROM t_old;，并手动处理外键、权限、注释等元数据

InnoDB 的 buffer pool、redo log 写入节奏、purge 线程压力，都会影响这个过程的实际耗时——这些细节 Server 层看不到，但决定了你等多久才能看到 Query OK。