MySQL客户端SQL经连接校验、语法解析生成SELECT_LEX、优化器重写统计选择执行路径、执行器调用引擎逐行读取并过滤、结果缓存后返回；全过程涉及权限、缓存、语法、成本估算、MVCC、网络缓冲等环节。
MySQL 客户端发来的 SQL 到底被怎么“拆解”的
MySQL 不是直接执行你写的 SQL 字符串，而是走一套完整的解析、优化、执行链路。真正决定性能的，往往不是 SELECT 写得多漂亮，而是这条语句在服务端经历了哪些环节、卡在哪一步。
SQL 进入 MySQL 后的第一关：连接与命令分发
客户端通过 TCP 或 Unix socket 连上 mysqld，发送的是一个带长度前缀的二进制包（COM_QUERY 协议包），不是纯文本流。MySQL 线程池拿到这个包后，先做基础校验：
- 用户权限是否允许执行该语句（比如
SELECT需要SELECT权限，哪怕只是查information_schema） - 是否命中查询缓存（MySQL 8.0 已移除，但 5.7 及以前仍存在，且默认关闭）
- 语句长度是否超
max_allowed_packet限制（超了会直接报错Packets larger than max_allowed_packet bytes are not allowed）
语法解析与逻辑计划生成：从字符串到可执行结构
过了连接层，SQL 字符串交给 SQL 解析器（基于 LALR(1) 的 yacc/bison 生成器）。它不关心表是否存在、字段有没有索引，只管是否符合语法规则：
-
SELECT * FROM t WHERE id = ? AND name LIKE '%x'→ 合法 -
SELECT * FROM t WHERE id = ? ORDER BY→ 报错：You have an error in your SQL syntax
解析成功后，生成 SELECT_LEX 结构体（MySQL 内部表示），包含 JOIN_LIST、WHERE_COND、ORDER_LIST 等子结构。这步不访问表，也不查元数据。
查询优化器干了什么：为什么 EXPLAIN 显示的执行顺序和你写的不一样
优化器才是真正的“决策者”。它拿到逻辑结构后，做三件事：
- 重写：把
OR转成UNION，把子查询转成JOIN（如IN (SELECT ...)可能被物化） - 统计：读取
mysql.innodb_table_stats和采样页估算行数（cardinality），决定驱动表顺序 - 选择：对每个 JOIN 组合尝试
ref、range、index_merge等访问方式，选成本最低的物理执行路径
这就是为什么你写 SELECT * FROM a JOIN b ON a.id = b.a_id，EXPLAIN 却显示 b 是第一行——优化器认为先扫 b 再回表 a 更快。参数 optimizer_switch（如 firstmatch=off）会显著改变这个行为。
执行器调用存储引擎：真正读数据的那一步才开始 IO
优化器输出执行计划后，执行器按节点逐个调用接口。关键点在于：
- 每行数据都由执行器从引擎拉取，不是引擎一次性返回结果集（除非是
SELECT ... INTO OUTFILE这类特殊语句） - 如果走了索引，执行器调用
ha_innobase::index_read()；如果是全表扫描，调用ha_innobase::rnd_next() - 遇到
WHERE条件，执行器自己再
过滤一次（Condition pushdown是引擎层做的优化，不是所有条件都能下推） - 事务隔离级别在这里起作用：RR 下的
SELECT会构造 ReadView，MVCC 版本可见性判断由执行器完成
过滤一次（也就是说，WHERE id > 100 AND status = 'active'，如果只有 id 有索引，status 的过滤是在 MySQL Server 层做的，不是 InnoDB。
结果返回与连接清理：别忽略网络和锁的残留影响
执行器拿到最终结果集后，并不立即发给客户端：
- 先写入线程本地的
net_buffer（大小受net_buffer_length控制），攒够或遇到大字段才 flush - 如果用了
SQL_BUFFER_RESULT提示，还会强制把结果暂存在临时表中，释放表锁更早 - 语句结束 ≠ 连接释放：如果没显式
COMMIT或ROLLBACK，事务状态仍保留，可能阻塞其他会话的 DDL
最常被忽略的是：长事务 + 大结果集会让 net_buffer 持续占用内存，且 SHOW PROCESSLIST 里看到的 Status 是 Sending data，其实卡在网卡缓冲区或客户端收包慢，不是数据库慢。
