MySQL 8.0 已彻底移除查询缓存，5.7+默认关闭且不建议启用；分析器负责语义校验而非语法检查；优化器基于统计信息选执行路径但未必用上索引；执行器最终执行并校验行/列级权限。
查询缓存早就不该用了
MySQL 8.0 已彻底移除 query_cache 相关所有功能，5.7 及更早版本虽保留，但默认关闭且强烈不建议开启。原因很实际：只要表有任意一行被 UPDATE/DELETE/INSERT，整个表对应的缓存全失效——高并发写场景下，缓存命中率极低，反而增加 key 查找开销。
- 检查是否启用：
SHOW VARIABLES LIKE 'query_cache_type';—— 若返回OFF或0，说明没开（这是现代生产环境的合理状态） - 误开后发现性能变差？直接在配置文件中删掉
query_cache_size和query_cache_type两行，重启 MySQL - 想替代缓存？用应用层 Redis 或 Proxy 层（如 ProxySQL）做结果缓存，粒度可控、不随 DML 波动
分析器不是“语法检查器”，而是语义准备阶段
很多人以为分析器只干“SELECT * FROM user WHERE id=1 有没有少个分号”这种事，其实它真正关键的任务是：确认表存在、字段存在、别名是否冲突、权限能否覆盖到目标列——这些都发生在优化器之前。
- 典型报错
Unknown column 'xxx' in 'field list'或Table 'db.xxx' doesn't exist就出自这一阶段，不是执行器才报 -
DISTINCT、GROUP BY字段是否在SELECT列表里，也会在这里校验（尤其 SQL mode 开启ONLY_FULL_GROUP_BY时） - 注意：视图展开、子查询扁平化也发生在此阶段，所以嵌套太深的视图可能在这里就卡住或报错
优化器决定“怎么走”，但不保证你写的索引就真被用上
优化器基于统计信息（INFORMATION_SCHEMA.STATISTICS 或 ANALYZE TABLE 更新的数据）估算成本，选它认为最快的路径。但它的判断依赖数据分布真实性，而现实常有偏差。
- 常见陷阱：
WHERE status = ?如果status只有 2 个值（比如 0/1），且 95% 是 1，优化器大概率放弃索引走全表扫描——哪怕你建了索引 - 验证方式：
EXPLAIN FORMAT=TREE（MySQL 8.0+）比传统EXPLAIN更直观看到访问路径和过滤比例 - 强制走索引？慎用
FORCE INDEX—— 它绕过优化器，一旦数据倾斜变化，可能让查询从 10ms 暴涨到 2s
执行器才是真正“干活”的，也是权限最终把关人
即使分析器通过了表/字段校验，执行器仍会再查一次权限——而且是按行/列粒度。这意味着：你可能 SELECT 成功，但其中某几列因 COLUMNS_PRIV 限制返回 NULL（取决于 SQL mode 和客户端行为）。
- 典型现象：
SELECT *返回部分列为NULL，但SHOW CREATE TABLE显示字段都存在 → 检查SELECT权限是否只给了部分列 - 引擎调用是“按行拉取 + 过滤”：InnoDB 返回一行，执行器判断是否满足
WHERE条件；不满足就丢弃，继续拉下一行——所以WHERE中函数（如DATE(created_at)）会导致无法用索引，且每行都得计算 - 临时表（
Using temporary）和文件排序（Using filesort）也出现在执行阶段，它们不走索引，而是由执行器在内存或磁盘上组织中间结果
整个流程里最容易被忽略的，其实是“连接器建立后权限就固化”这一点：管理员改了你的权限，已存在的连接不会感知，只有新连上的才会生效。线上排查权限问题时，先 KILL 对应连接再重连，否则永远查不到真实权限状态。
