一条复杂sql在mysql中必然经过连接→解析→预处理→优化→执行→返回这六个不可跳过的环节，且每个环节都可能失败或被干预：连接器校验账号密码与host权限但不查sql内容，解析阶段通过词法和语法分析生成语法树并暴露语法错误，预处理检查表列存在性及权限，优化器基于统计信息生成执行计划（可能忽略索引或误选join顺序），执行器调用引擎接口并二次校验权限，最终返回结果。
一条复杂 SQL 在 MySQL 中不是“写完就跑”，它必须先被拆解、验证、权衡、再调度执行。核心结论很直接：**它必然经过连接 → 解析 → 预处理 → 优化 → 执行 → 返回这六个不可跳过的环节，且每个环节都可能失败或被干预。**
连接器会校验权限，但不校验SQL内容
客户端发起连接时，mysql 命令或 JDBC 连接串触发的是 TCP 握手 + 认证流程，连接器只查 mysql.user 表确认账号密码和 host 权限，不看你要执行什么 SQL。这意味着：
- 即使你后续要查一张根本不存在的表，连接也能成功建立
-
ERROR 1045 (28000)或ERROR 1142 (42000)都发生在这里，而不是执行阶段 - 长连接下线程复用，
wait_timeout控制空闲断开，默认 8 小时，超时后重连会重新走认证 - 连接成功后，
SHOW PROCESSLIST能看到对应thread_id和当前状态（如Sleep或Query）
解析阶段就可能报错，且错误信息非常具体
词法分析把 SELECT * FROM users WHERE id = 1; 拆成 SELECT、*、FROM、users 等 token；语法分析则检查这些 token 是否构成合法结构。常见失败点：
-
ERROR 1064 (42000)：典型语法错误，比如写成SELEC * FROM users（少了个 T），或SELECT name FROM users WHERE age > '25'但 age 是整型字段 - 大小写和空格敏感：在旧版本开启查询缓存时，
select * from t和SELECT * FROM t是两个不同缓存项（不过 MySQL 8.0 已彻底移除查询缓存） - 注释干扰：
--后未换行会导致截断，/* */嵌套不支持，都可能引发解析失败
优化器决定怎么查，但它不保证按你写的索引走
预处理确认表和列存在、权限够用之后，优化器登场。它基于统计信息（SHOW TABLE STATUS LIKE 'orders' 中的 Rows 值、ANALYZE TABLE 更新的分布）估算成本，最终生成执行计划。关键事实：
- 你写了
FORCE INDEX(idx_created_at)，它会照做；但没加提示时，哪怕有索引，也可能选全表扫描——比如WHERE status IN ('paid', 'shipped')，而 status 只有 3 个值，选择性太差 -
EXPLAIN FORMAT=TRADITIONAL SELECT ...显示的key列才是它实际选的索引，不是你期望的那个 - 多表 JOIN 时，
JOIN ORDER由优化器定，STRAIGHT_JOIN可强制顺序，但需谨慎，数据量变化后可能更慢 - 覆盖索引能避免回表，但前提是
SELECT的所有列都在索引中；否则仍要通过主键二次查找
执行器调用引擎 API，但权限会再校一次
执行器拿到优化器输出的执行计划后，并不直接读磁盘，而是调用存储引擎接口（如 InnoDB 的 ha_innobase::index_read()）。这个阶段容易被忽略的细节：
- 它会再次检查用户对目标表的权限——和连接器那次是独立的两次校验，中间任何一步权限变更都可能导致失败
- 即使走了索引，
WHERE条件仍可能在执行器层过滤：比如索引只加速定位，但WHERE JSON_CONTAINS(data, '"admin"')这类函数无法下推到引擎层，得回表后再计算 - InnoDB 的 Buffer Pool 决定是否从内存读页；没命中才触发磁盘 I/O，
SHOW ENGINE INNODB STATUS的Buffer pool hit rate可反映该情况 - 事务隔离级别影响可见性：RR 下靠 MVCC + undo log 判断哪些版本可见，这不是执行器逻辑，但结果由它组装返回
真正复杂的点不在某个单环节，而在于环节之间的依赖与反馈——比如优化器依赖统计信息准确度，而统计信息又受 ANALYZE TABLE 或自动采样影响；执行器发现某页不在 Buffer Pool，触发 I/O 后还要等 IO 完成才能继续。这些隐含路径，才是线上慢查排查时最常卡住的地方。
