SQL执行生命周期

我们拿一句最经典的 SQL 为例SELECT name,age FROM users WHERE age18;当这条 SQL 发送给数据库比如 MySQL后数据库内部会经历一个极其严密的“五步走生命周期”。这就像是一个超级工厂的流水线我们把这五步彻底拆解第一步连接器Connector—— 验明正身数据库首先会检查你的账号密码看看你有没有权限连上来以及连上来之后有没有权限查 users 表。如果没问题它会维持这个连接准备接收你的 SQL。第二步解析器Parser—— 构建 SQL 语法树AST这就是我们上一轮聊到的核心数据库拿到这串文本后会进行“词法分析”和“语法分析”。它会把 SELECT name, age FROM users WHERE age 18 拆解成一棵内存中的语法树AST。如果少写了 FROM或者拼错了表名数据库在这一步就会直接报错Syntax error后面的流程直接终止。如果语法正确数据库就完全明白了你的意图你要查 users 表要 name 和 age 字段条件是 age 18。第三步优化器Optimizer—— 制定最佳战术这是数据库最聪明的地方它拿到语法树后不会傻乎乎地直接去干活而是会思考“怎么查最快”它会去查数据字典元数据看看 users 表上有没有索引。情况 A如果 age 字段上没有索引优化器就会制定计划“没办法只能把 users 表从头到尾扫一遍全表扫描把 age 18 的数据捞出来。”情况 B如果 age 字段上有 B 树索引优化器就会大喜“太好了我直接去 B 树上找 age 18 的区间速度会快一万倍”优化器最终会生成一个“执行计划Execution Plan”决定用什么顺序、走哪个索引来查数据。第四步执行器Executor—— 冲锋陷阵执行器拿到计划后开始真正去干活。这时候B 树就隆重登场了调用存储引擎执行器本身不存数据它会根据计划调用底层的存储引擎比如 MySQL 的 InnoDB。B 树检索如果计划决定走索引存储引擎就会去磁盘或内存缓冲池里的 B 树 上查找。B 树极其扁平几千万条数据也只需要跳跃 3~4 次就能定位到具体的数据行页。逐行过滤与返回执行器拿着 B 树找出来的数据再校验一遍条件比如 age 18如果符合就把这一行放进结果集里。第五步返回结果Return执行器把所有符合条件的数据行打包通过网络协议返回给你的应用程序。 核心总结两棵树的完美配合你看在这个五步流程中SQL 语法树和 B 树 完美地配合了一次SQL 语法树AST 存在于第二步它是逻辑层面的负责让数据库“听懂”你要什么。B 树 存在于第四步它是物理层面的负责以最快的速度把数据从硬盘里“搬”出来。掌握了这个完整的生命周期以后你在排查慢查询Slow Query时脑子里就能清晰地浮现出到底是解析器卡住了还是优化器选错了执行计划没走索引还是 B 树查询太慢