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。
