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，其实卡在网卡缓冲区或客户端收包慢，不是数据库慢。
