mysql sql执行流程是带条件分支的动态路径，多数select不进入执行器：先校验连接与权限，再查查询缓存（5.7及以前），接着解析预处理，最后优化器生成执行计划；执行计划依赖实时环境而非sql本身。
MySQL 的 SQL 执行流程不是线性“解析→优化→执行”三步走，而是一套带条件分支、缓存干预和权限校验的动态路径；多数 SELECT 语句甚至根本不会走到真正的执行器阶段。
连接与权限校验：第一道关卡
客户端发起连接后，MySQL 先查 mysql.user 表验证用户名、密码、host，并检查该账号对目标数据库/表是否有对应操作权限（如 SELECT、INSERT）。权限不满足会直接报错 access denied for user，后续步骤全部跳过。
常见疏漏点：
- 用户从 localhost 连接时，
user@'127.0.0.1'和user@'localhost'是两个不同账号，权限可能不一致 - GRANT 后未执行
FLUSH PRIVILEGES（8.0+ 账号系统已改为原子化，但老版本仍需） - 使用代理或中间件时，实际连接用户可能是中间层账号，而非应用配置的账号
查询缓存（8.0 已移除，但 5.7 及以前必须注意）
如果开启 query_cache_type=ON，MySQL 会用 SQL 文本的 MD5 值查缓存。命中则直接返回结果，跳过解析、优化、执行全过程。
但这带来严重副作用：
- 任何对相关表的
UPDATE/delete/INSERT都会使该表所有缓存失效 - 缓存键对空格、大小写、注释敏感：
SELECT * FROM t和select * from t是两条不同缓存 - 5.7 默认关闭，8.0 彻底删除
query_cache_*系统变量
解析与预处理：语法树怎么来的
词法分析（Lexer）把 SQL 拆成 Token（如 SELECT、id、FROM），语法分析（Parser）按语法规则生成解析树（Parse Tree）。接着进入预处理阶段，做两件事：
- 表名、列名合法性检查：是否存在该库、该表、该字段？别名是否冲突？
- 语义等价改写：比如把
WHERE id = 1 AND id = 2直接判为恒假，生成空结果集
典型错误在此暴露：Unknown column 'xxx' in 'field list' 或 table 'db.t' doesn't exist，说明没通过预处理。
优化器与执行计划：真正决定快慢的地方
优化器把解析树转为逻辑执行计划，再结合统计信息（如 INformatION_SCHEMA.STATISTICS、采样页数据）估算成本，选择索引、决定 JOIN 顺序、是否使用临时表等。最终生成的是执行计划（EXPLAIN 输出），不是可执行代码。
关键事实：
- 优化器不保证选到“最优”方案，只选它估算“成本最低”的那个——而成本模型本身有误差
-
FORCE INDEX或USE INDEX是绕过优化器的强制手段，但可能在数据分布变化后反而更慢 -
EXPLAIN FORMAT=TREE（8.0+）能看清是否用了物化（MATERIALIZATION）、是否下推了条件（attached_condition）
最后一步“执行器”才调用存储引擎接口（如 ha_innobase::index_read），逐行读取、过滤、聚合。但如果你的 SQL 被缓存命中、被权限拦截、或被语义改写成常量，它压根不会走到这里。
真正容易被忽略的是：**执行计划不是 SQL 的固有属性，而是依赖当前表结构、索引、统计信息、甚至 session 变量（如 optimizer_switch）的瞬时快照。同一句 SQL，在不同时间、不同实例上，可能走完全不同的路径。**