mysql 8.0 彻底移除查询缓存，所有 query_cache 相关变量已从源码删除，配置即报错或忽略；查询直接进入解析器，执行完整流程。
MySQL 8.0 查询不走查询缓存，直接进解析器
MySQL 8.0 已彻底移除 query_cache 相关所有逻辑，SHOW VARIABLES LIKE 'query_cache_type' 查不到变量，配置文件里写 query_cache_size 会被忽略，启动时直接报 warning。这意味着你看到的任何查询，都必然经过后续完整流程——没有“跳过”环节。别再查缓存命中率，也别在慢查询日志里找“Cache miss”字样，它不存在。
分析器阶段就可能报错，且错误信息很具体
分析器不是只检查语法，它做的是语义合法性校验：表是否存在、字段是否属于该表、别名是否冲突、权限能否覆盖到列。常见报错如 Unknown column 'xxx' in 'field list' 或 Table 'db.xxx' doesn't exist 都出自这里，不是执行器才拦。注意：SELECT * 在视图上展开时，若视图定义引用了已删字段，也会在此阶段失败；GROUP BY 字段不在 SELECT 列表中（且启用了 ONLY_FULL_GROUP_BY）同样卡在这步。
优化器选路径不等于用索引，EXPLAIN FORMAT=TREE 更可靠
优化器基于统计信息估算成本，但数据倾斜会让它的判断失效。比如 WHERE status IN (0,1)，若 98% 是 1，即使 status 有索引，优化器也可能选全表扫描。验证方式优先用 EXPLAIN FORMAT=TREE（MySQL 8.0+），它能显示实际访问路径、过滤比例、是否使用索引、是否回表。不要只看 type: ref 就认为走了索引——得看 key 字段是否非 NULL，以及 rows 是否接近真实筛选后行数。
执行器才是最终权限闸门和实际干活的人
即使分析器通过了字段检查，执行器仍会逐行校验权限：如果某列被 COLUMNS_PRIV 限制，SELECT * 可能返回 NULL 而不是报错。更关键的是，执行器调用存储引擎接口前，会再次确认你是否有 SELECT 权限——哪怕连接时已认证过。这意味着：同一账号在不同会话中，权限表被修改后，新查询会立刻生效，旧连接不受影响。另外，LIMIT、ORDER BY、DISTINCT 等操作都在执行器层完成，不是引擎层的事。
