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本身，只体现在慢查询里。
