MySQL执行流程分四层：连接器校验权限并管理会话，解析器完成词法、语法、语义分析生成解析树，优化器基于成本模型选择执行计划，执行器复检权限后调用引擎取数并组装结果。
连接器：权限校验和会话生命周期管理
你执行 mysql -u root -p 或程序调用 JDBC 连接时，首先进入连接器。它不处理 SQL，只干三件事：
• 验证用户名/密码（比对哈希值，不传明文）
• 查 mysql.user 表确认该用户是否有 SELECT 权限（注意：权限在连接建立时就缓存，改权限后必须重连才生效）
• 分配一个线程并创建会话（SHOW PROCESSLIST 中看到的 Sleep 状态就是空闲会话）
⚠️ 容易踩的坑：
• wait_timeout 默认 8 小时，长连接若长期空闲会被服务端主动断开，应用层若没做重连逻辑，就会报 Lost connection to MySQL server during query
• 连接池（如 Druid）配置不当，比如 maxActive=100 却没设 minIdle，高并发下可能瞬间打满连接数，触发 Too many connections
解析器：词法 + 语法 + 语义三层校验
SQL 到达服务层后，解析器先做词法分析（把 SELECT name, age FROM users WHERE id = 1 拆成 SELECT、name、FROM 等 token），再做语法分析（检查是否符合 MySQL 语法规则），最后是语义分析（确认 users 表是否存在、id 字段是否属于该表、别名是否冲突等）。
常见错误现象：
• ERROR 1064 (42000)：典型语法错误，比如漏了逗号、引号不闭合、用了保留字当字段名却没加反引号
• ERROR 1146 (42S02)：语义错误，表不存在
• ERROR 1054 (42S22)：字段名不存在或作用域错误（比如在 WHERE 里引用了 SELECT 列别名）
? 关键点：解析器输出是一棵“解析树”（parse tree），这是后续所有步骤的输入基础；如果这一步失败，SQL 就根本进不了优化器。
优化器：基于成本模型选执行计划，不是猜
优化器不保证“绝对最优”，而是根据统计信息（如 INFORMATION_SCHEMA.STATISTICS、索引基数、行数估算）计算不同执行路径的 I/O 和 CPU 成本，从中挑一个“相对最省”的计划。例如：
• 全表扫描 vs 索引查找 vs 索引覆盖扫描
• 多表 JOIN 时驱动表选谁、用 NLJ 还是 BKA
你可以用 EXPLAIN 看它最终选了哪条路：
EXPLAIN SELECT name, age FROM users WHERE id = 1;
重点关注：
type（访问类型，const 最好，ALL 最差）、key（实际用到的索引）、rows（预估扫描行数）、Extra（比如 Using index 表示覆盖索引，Using filesort 表示要额外排序）⚠️ 容易被忽略的点：
• 统计信息过期会导致优化器误判（可用
ANALYZE TABLE users; 手动更新）•
WHERE 条件中对字段用函数（如 WHERE YEAR(create_time) = 2025）会让索引失效，优化器只能退化为全表扫描
执行器：权限复检 + 引擎接口调用 + 结果组装
执行器拿到优化器生成的执行计划后，并不会直接冲向存储引擎。它先做一次“兜底权限检查”（哪怕连接器已验过，这里仍会再查一次，防止绕过）；然后按计划逐节点调用存储引擎接口，比如：
• InnoDB 的 index_read() 或 table_scan()
• 对每行数据做 WHERE 过滤、SELECT 字段提取、ORDER BY 排序等
执行过程中：
• 如果是 UPDATE/DELETE，InnoDB 会先写 undo log，再写 redo log（WAL 机制）
• 如果涉及临时表（如 GROUP BY 数据量大），可能用到磁盘临时表（Created_tmp_disk_tables 状态变量可监控）
? 实操建议：
• 用 SHOW PROFILE 或性能模式（performance_schema）定位慢在“解析”“优化”还是“执行”阶段
• SELECT 不会写 binlog，但 INSERT/UPDATE/DELETE 在 binlog_format=ROW 下会记录每一行变更，影响主从同步延迟
SHOW WARNINGS、EXPLAIN FORMAT=JSON 和慢日志里的 Rows_examined。 
