一条看似简单的SQL查询语句，从客户端发出到返回结果，背后要经过数据库服务端的多个协作组件。不同数据库如MySQL、PostgreSQL大体阶段相似，都包含连接、解析、优化、执行几个核心步骤。理解这条链路，是排查慢查询、死锁以及编写高效SQL的基础。
一、连接与线程分配
数据库客户端通过TCP或本地套接字建立连接，服务端连接管理器接收到请求后，会从线程池或新建线程中分配一个会话处理上下文。此时数据库会校验用户名、密码、主机权限以及该用户是否具备目标库的访问权。若校验失败，直接返回访问拒绝错误，语句不会进入后续阶段。
连接建立后，会话会维持一个命令接收缓冲区。客户端发送的SQL文本先被完整读入该缓冲区，再由命令分发器判断类型。对于查询语句，服务端会检查是否开启查询缓存（如MySQL旧版本），若命中且权限允许则直接返回，否则继续向下传递。现代数据库往往因缓存失效频繁而默认关闭此特性。
二、解析与预处理
解析器首先对SQL字符串做词法分析，将字符流拆解为关键字、标识符、常量和操作符标记。随后语法分析器依据SQL文法生成解析树，任何括号不匹配、保留字误用都会在此阶段抛出语法错误。以下伪代码展示了词法拆解的基本思路：
def lexer(sql_text):
tokens = []
i = 0
while i < len(sql_text):
if sql_text[i].isspace():
i += 1
continue
if sql_text[i].isalpha():
j = i
while j < len(sql_text) and (sql_text[j].isalnum() or sql_text[j] == '_'):
j += 1
tokens.append(('IDENT', sql_text[i:j]))
i = j
else:
tokens.append(('OP', sql_text[i]))
i += 1
return tokens
sql = "SELECT id FROM user WHERE age > 18"
print(lexer(sql))
预处理器在解析树基础上做语义检查，包括将别名展开、验证表与列是否存在、处理视图替换为底层定义。比如查询引用了不存在的列名，就会在这一步被拦截。预处理结束后生成的逻辑查询树才真正交给优化器。
三、查询优化器与执行计划
优化器是数据库的大脑。它基于表和索引的统计信息，枚举可能的访问路径，例如全表扫描、索引扫描、多表连接的顺序与算法（嵌套循环、哈希连接、归并连接）。优化器通过成本模型估算每种路径的IO与CPU消耗，选择估算值最小的方案，并生成执行计划。
以多表关联为例，三张表连接理论上存在多种左右子树组合，优化器会结合WHERE条件过滤率与索引选择性剪枝。下面是一段模拟优化器选择索引扫描的简化逻辑：
public Plan choosePlan(Table t, Condition c) {
Index idx = t.getIndexMatching(c);
if (idx != null && idx.getSelectivity() < 0.2) {
return new IndexScanPlan(t, idx, c);
}
return new FullScanPlan(t, c);
}
执行计划通常可用EXPLAIN命令查看。它展示了访问类型、可能索引、实际所用索引、扫描行数等。读懂执行计划，就能判断为何明明建了索引却走了全表扫描，或连接顺序是否合理。
四、执行引擎与存储引擎交互
执行引擎按执行计划调用存储引擎接口获取数据。对于索引扫描，存储引擎通过B+树定位叶子节点，返回记录给执行层。执行层完成剩余的过滤、排序、分组或聚合。若需要排序且内存不足，还会借助临时文件做外部排序。
以下表格对比了两种常见扫描方式的特点：
| 扫描方式 | 适用场景 | 缺点 |
|---|---|---|
| 全表扫描 | 无可用索引或返回大部分数据 | IO量大，延迟高 |
| 索引扫描 | 高选择性过滤条件 | 回表开销，不适合宽范围 |
最终执行引擎将结果集封装为协议格式，经连接写回客户端。整个过程中，锁与事务状态由存储引擎维护，若查询触发表级或行级锁等待，会话便会阻塞直至资源释放。
五、常见误区与排查建议
不少开发者认为SQL写得短就执行快，实际上执行计划才是决定因素。比如使用函数包裹索引列会导致无法走索引：WHERE YEAR(createtime) = 2023 这类写法会让优化器放弃索引。应改为范围条件。
另一个误区是忽视统计信息过期。优化器依赖统计信息做判断，若表经历大量增删而未更新统计，可能误选全表扫描。定期执行ANALYZE TABLE类命令，可保持优化器决策准确。掌握SQL执行全流程，才能从原理层面做性能调优。