连接器：权限校验和会话生命周期管理
你执行
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下会记录每一行变更，影响主从同步延迟 MySQL 执行流程里最隐蔽的复杂点，其实是**各层之间状态不共享**：连接器缓存权限，但执行器还要再查；解析器生成的表名是逻辑名，优化器要映射到物理文件路径，执行器又要通过存储引擎 API 去读取——这些衔接处一旦统计不准、权限错位或引擎返回异常，错误表现往往模糊（比如报错位置和真实问题脱节）。调试时别只盯 SQL 写得对不对，得多看
SHOW WARNINGS、
EXPLAIN FORMAT=JSON和慢日志里的
Rows_examined。
