查询缓存早就不该用了
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对应连接再重连，否则永远查不到真实权限状态。
