StarRocks 查询探秘（二）：SELECT语句的语义分析之旅

用户提交的 SQL 查询文本在 FE 需要经过一系列处理，最终生成一个分布式执行计划分发给各个 BE 进行计算。如下图所示，经过这么几个核心的处理流程:

1. Parser 解析，把一条文本 SQL 解析成一棵 AST 树；

2. Analyze 分析，对 AST 树进行分析，比如表是否存在等；

3. AST 树是怎么转成 Loagical Plan；

4. 规则重写，基于一些规则重写 Logical Plan；

5. 经过优化 Optimizer 选出最佳 Physical Plan。

图片

本文主要分析 Anylyze 阶段做的工作, 基于StarRocks-3.4.0版本

在上一篇文章

StarRocks 查询探秘（一）：SELECT语句的解析之旅 平头哥，公众号：BigData共享StarRocks 查询探秘（一）：SELECT语句的解析之旅

中，剖析了 StarRocks 是如何把一条文本 SQL 解析成一颗 AST 树；本文将接着上一篇文章，分析 Analyze 阶段，该阶段主要是针对 SQL 语义进行处理，比如：判断SQL 中表/列 是否存在，函数是否存在，order by 前是否有 group by 等一系列语义检查，如下图一些语义检验例子：

图片

Analyzer阶段的核心任务

Analyzer 阶段的核心是对 AST 进行语义分析，验证 SQL 语句是否符合数据库的语义规则。通过 Visitor 模式结合递归遍历的方式，逐层分析 AST 的每个节点。不同的 SQL 语句类型对应不同的 Analyzer 处理逻辑，确保语义分析的针对性。

如下图所示，一条查询 SQL 对应的 QueryAnalyzer 是如何遍历 AST

图片

对应堆栈信息

图片

单层 SELECT 查询的语义分析

以一条简单的 SQL 查询为例，来看看 Analyzer 阶段的具体工作

SELECT uid, AVG(read_duration)FROM xx_v1WHERE time = '20250604'GROUP BY uidLIMIT 6;

Analyzer 接收上一阶段（Parser）生成的 AST，其中 stmt 就是上一个阶段构建出的 AST 抽象语法树

图片

逐步分析 SQL 查询的各个组成部分（SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT 等），并生成语义分析结果.

image.png

比如，在分析 WHERE 子句中，使用 AnalyzerUtils 工具类检查 WHERE 子句中的表达式是否包含以下非法内容：

• 聚合函数（如SUM、COUNT）：WHERE 子句中不允许使用聚合函数，因为它们需要在分组后计算。
• 窗口函数（如ROW_NUMBER）：WHERE 子句不支持窗口函数，因为它们依赖于查询的输出。

否则就会抛出对应的语义异常：

图片

例如，如果在 where 后面跟个 sum(pv) 函数，就会校验抛如下错误：

图片

多层嵌套查询的语义分析

Scope 类表示一个命名空间，命名空间包含了该作用域内对外层可见的字段信息，这样在逐级解析字段的时候才能判断该字段名是否是正确合法的。

以下面两层查询sql为例，

SELECT sum_pvFROM (      SELECT app_id,  SUM(pv) AS sum_pv      FROM xxx_table      WHERE dt = 'xxx'      GROUP BY app_id) tLIMIT 10;

分别对应的内外层 Scope 如下，

图片

Analyzer 阶段是 SQL 查询处理中承上启下的关键环节。它通过语义分析确保 SQL 语句的正确性，并为后续的 Logical Plan 生成奠定基础。本文通过单层和嵌套查询的示例，展示了 Analyzer 的核心工作原理和 Scope 的作用。

在下一篇文章《StarRocks 查询探秘（三）：AST如何转换成Logical Plan》中，我们将深入探讨AST如何转化为逻辑执行计划，敬请期待！

更多大数据干货，欢迎关注我的微信公众号—BigData共享

​