MySQL如何解析一条SQL语句
MySQL不是直接执行你写的SQL字符串，而是先把它拆解成内部可理解的结构。这个过程叫「解析（parsing）」，核心是
sql_parse.cc里的
parse_sql()函数。它用的是自顶向下递归下降语法分析器，基于预定义的
sql_yacc.yy语法文件生成词法和语法树。
常见卡点：如果SQL里有不支持的语法（比如MySQL 5.7里写
JSON_EXTRACT(json_col, '$.a.b')没问题，但
->操作符要8.0+），解析阶段就直接报错
ERROR 1064 (42000)，根本进不了后续流程。 注释、空格、大小写在解析阶段被剥离，
SELECT * FROM t和
select*from\t最终生成的解析树几乎一样 反引号包裹的标识符（如
`order`）会被保留为合法列名，避免和关键字冲突 未加引号的字符串字面量（如
WHERE name = abc）会被当作列名处理，导致
Unknown column 'abc' in 'where clause'
查询优化器怎么改写你的SQL
解析完得到语法树后，优化器（optimizer）开始工作。它不信任你写的SQL顺序，会重排表连接顺序、下推条件、消除冗余字段——这些动作统称「逻辑重写」。关键入口是
optimize_cond()和
make_join_statistics()。
典型现象：你写
SELECT * FROM a JOIN b ON a.id = b.a_id WHERE b.status = 'active'，优化器可能把
WHERE条件提前到
b表扫描时过滤，甚至改用
IN (SELECT ...)等价重写（取决于统计信息是否准确）。 使用
EXPLAIN FORMAT=TREE能看到优化器实际选择的执行计划树，比传统
EXPLAIN更直观
SET optimizer_switch='derived_merge=off'能禁用派生表合并，用于调试复杂子查询行为 统计信息过期（
ANALYZE TABLE没跑）会导致优化器误判索引选择，出现本该走索引却全表扫描
执行器真正干活时依赖哪些数据结构
优化器输出执行计划后，执行器（executor）按节点逐个调用
ha_xxx::index_read()或
ha_xxx::rnd_next()接口读取数据。每张表对应一个
TABLE结构体，其中
file成员指向存储引擎的具体实现（如
ha_innobase）。
注意：执行阶段才真正触发锁、事务可见性判断、权限校验。比如
SELECT在RR隔离级别下，执行器会根据
read_view决定某行是否对当前事务可见——这和解析、优化完全无关。 临时表（
CREATE TEMPORARY TABLE）只在当前连接内存/磁盘存在，执行器通过
tmp_table_param管理其生命周期 批量插入（
INSERT ... VALUES (...), (...)）执行器会合并为单次引擎层批量写入，减少日志刷盘次数 如果
max_heap_table_size太小，执行器在构建内部临时表时会自动落盘到
ibtmp1，性能陡降
为什么有些SQL在prepare阶段就失败
如果你用
PREPARE stmt FROM '...'，MySQL会在prepare阶段完成解析和部分语义检查（比如表是否存在、列名是否拼错），但**不进行权限验证和执行计划生成**。这意味着：
PREPARE成功不代表
EXECUTE一定成功。
典型错误：
ERROR 1146 (42S02): Table 'db.nonexist' doesn't exist在
PREPARE时就报出；而
ERROR 1054 (42S22): Unknown column 'xxx' in 'field list'也可能在此阶段被捕获——只要列名属于已知表结构。 视图定义中的列名错误，会在
PREPARE时暴露，因为视图元数据已加载 存储过程内动态SQL的
PREPARE，若引用了过程参数但拼写错误（如
CONCAT('SELECT * FROM t WHERE id = ', v_id)中v_id未声明），prepare直接失败
EXECUTE时才检查权限，所以
PREPARE成功但
EXECUTE报
ERROR 1142 (42000): SELECT command denied很常见
整个流程里最容易被忽略的是：解析、优化、执行三个阶段共享同一套内存上下文（
THD），但各自持有不同生命周期的对象。比如解析树在优化后可能被释放，而执行器依赖的
JOIN结构体是全新分配的——调试时看错内存地址很容易误判问题阶段。
