SQL语句进入MySQL后先被解析成解析树（Parse Tree）；解析器将原始字符串拆分为token并构建解析树，仅表达语法结构，不验证表或索引是否存在。
SQL语句进入MySQL后先被解析成什么
MySQL收到一条SQL语句后，第一件事不是查表，而是交给Parser（解析器）做语法和语义检查。它会把原始字符串拆成词法单元（token），再构建成一棵Parse Tree（解析树）。如果SQL写错了，比如漏了逗号、用了不存在的字段名，就在这一步报错，错误信息通常是ERROR 1064 (42000)或ERROR 1146 (42S02)。
注意：解析树不包含执行逻辑，只表达“用户写了什么”，还不是可执行结构。后续优化器要基于它生成执行计划，但此时连表是否存在、索引有没有都还没验证。
查询缓存（Query Cache）在哪个环节起作用
MySQL 5.7及以前版本中，查询缓存是在解析之后、优化之前触发的——前提是query_cache_type = ON且SQL满足缓存条件（比如不能含NOW()、USER()等不确定性函数）。它用SQL文本的哈希值作key，直接返回之前缓存的结果集。
但这个机制有明显缺陷：
- 只要表有任何更新（哪怕只是
INSERT一行），整个表相关的所有缓存都会失效 - 多线程下缓存锁争用严重，高并发时反而拖慢性能
- MySQL 8.0已彻底移除
query_cache_type和相关系统变量
所以现在生产环境基本不依赖它，也不建议开启。
优化器如何决定走哪个索引或是否全表扫描
优化器拿到解析树后，会结合information_schema.STATISTICS、SHOW INDEX结果和统计信息（如cardinality），为每个可能的执行路径估算成本（I/O + CPU）。它不保证选到“最优”方案，只选它认为“成本最低”的那个。
常见影响判断的因素包括：
-
WHERE条件中字段是否有单列索引或符合最左前缀的联合索引 - 是否使用了函数（如
WHERE YEAR(create_time) = 2023会导致索引失效） - 数据分布倾斜（例如某字段95%值为
'active'，优化器可能觉得走索引还不如全表扫描） -
JOIN顺序——小表驱动大表更优，但优化器有时会选反
用EXPLAIN FORMAT=TREE能直观看到优化器最终选定的访问方法和连接顺序。
执行器调用存储引擎API时的关键行为
执行器不直接读磁盘，而是按优化器生成的执行计划，调用ha_*接口（如handler::index_read()或handler::rnd_next()）与存储引擎交互。InnoDB在此阶段才真正去查B+树、加行锁、判断MVCC可见性。
几个关键点：
- 即使
SELECT语句没写FOR UPDATE，执行器仍需调用handler::store_lock()申请IS锁 - 对于
UPDATE/DELETE，执行器会逐行调用handler::update_row()，每行都触发一次InnoDB的undo日志写入和聚簇索引更新 - 如果SQL里有
LIMIT，执行器会在拿到指定行数后主动中止调用，避免引擎层无谓扫描
这也是为什么SELECT * FROM t WHERE id > 1000 LIMIT 1可能比SELECT * FROM t LIMIT 1 OFFSET 1000快得多——后者得先跳过1000行。
整个流程里最容易被忽略的是：解析、优化、执行三个阶段各自独立，且优化器决策高度依赖统计信息准确性。如果表长期没做ANALYZE TABLE，或者数据量突增，执行计划就可能突然劣化，而错误往往不报在SQL本身，只体现在慢查询里。
