📚 课程目录第3章 SQL解析与优化器高频问题

第三章 SQL解析与优化器高频问题

SQL 优化器是数据库内核最复杂的模块之一。本章聚焦 解析流程、代价模型、统计信息、查询重写 四大核心方向，帮助你在面试中清晰展现对优化器工作原理和调优思路的理解。

  核心结论：面试官关注你是否能从编译原理→成本计算→数据分布→逻辑变换的链条讲透一个优化问题。

面试问题	请描述一条 SQL 在数据库内核中的解析流程。
面试官考察点	①是否了解编译器前端（词法→语法→语义）与数据库特有的名称解析、权限验证；②能否联系到后续优化器阶段。
回答框架	词法分析 → 语法分析（生成AST）→ 语义分析（绑定元数据、权限检查）→ 转换为逻辑计划（Relation/Operator）。
简短示例回答	以 SELECT * FROM t WHERE id=1 为例：先通过词法分析拆解为；语法分析生成 SelectStmt AST；语义分析解析 t 表和 id 列，检查用户权限；最后转换为逻辑扫描+过滤节点，交给优化器。
可能追问	①如果表名不存在，在哪一步报错？②视图或子查询如何处理解析？③解析错误与执行错误如何区分？
避坑提醒	勿将优化器阶段混入解析阶段。强调语义分析时涉及 catalog 查询，并点出错误处理（如 deferred name resolution）。

面试问题	代价模型如何利用统计信息选择执行计划？
面试官考察点	①是否理解基数（cardinality）→ 代价 = 基数 × 算子代价因子；②是否了解直方图、NDV、Null比例等统计信息；③能否指出统计信息过时导致的 bad plan。
回答框架	统计信息收集（直方图、MCV）→ 估算选择率 → 计算每个算子代价（CPU+IO+网络）→ 选出总代价最小的计划树。
简短示例回答	例如 t 表 1000 行，id 列有直方图。过滤条件 id<100，若统计显示该范围占比 30%，则基数 300。索引扫描代价 = 300随机读取成本，全表扫描 = 1000顺序读取成本，优化器选择小者。
可能追问	①没有统计信息时优化器如何工作？（默认假设均匀分布）②如何手动更新统计信息？③多重连接如何估算基数？
避坑提醒	不要把代价模型说成简单公式，要体现多因子考虑（启动成本、行处理成本、并行因子）。避免遗漏“统计信息陈旧导致选错”这一常见场景。

面试问题	举例说明查询重写优化中用到哪些规则？
面试官考察点	①是否了解常见重写规则：谓词下推、子查询展开、视图合并、常量折叠；②能否说明规则应用的启发式或基于代价的区别。
回答框架	列举4-5个规则 → 选1-2个详细说明变换效果 → 指出重写是等价变换，不改变结果语义 → 有些规则基于规则（RBO），有些基于代价（CBO）。
简短示例回答	谓词下推：WHERE t1.a=1 AND t1.id=t2.id → 先对 t1 过滤再 JOIN，减少中间行数。子查询展开：将 IN (SELECT ...) 转为 semi-join，避免逐行判断。常量折叠：WHERE 1+2=3 直接优化为 true。
可能追问	①视图合并为什么有时会失效？②子查询展开一定会更快吗？③什么情况下需要用 hint 禁止重写？
避坑提醒	不要只背规则名称，要展示对“等价性”的理解；同时提及重写阶段的顺序（如逻辑重写在物理优化前）。

项目名称	星环分布式查询引擎代价模型升级
业务背景	原有优化器采用固定权重模型，无法准确评估网络传输和 shuffle 成本，导致多表 JOIN 时频繁选择广播而非分区，引发 OOM。
规模指标	集群 200+ 节点，单表最大 5TB，日查询量 50 万+。
技术栈	C++、LLVM、Apache Calcite（CBO）、HDFS、Kubernetes。
核心难点	①分布式环境下 shuffle 成本建模（数据倾斜、网络带宽波动）；②统计信息动态采样开销控制；③重写规则（broadcast vs partitioned join）与代价联动。
面试高频追问	①如何测试新模型的准确性？②统计信息过期后如何处理兜底？③同一种 JOIN 在数据倾斜下如何自适应选择？
可迁移回答话术	“在分布式场景，代价模型不仅看行数和 IO，更要考虑网络传输量和 shuffle 倾斜因子。我当时的做法是引入数据分布直方图，将分区内数据方差作为代价惩罚项，从而自适应选择 broadcast 或 hash join。” 可套用在任何分布式或并行数据库面试中。

💡 面试提示：说到代价模型时，主动提及“分布式环境下 network cost 往往是瓶颈”，体现系统视角。

⚠️ 常见失分点：只背了规则名称，没有解释“为什么这个规则能优化”。用具体数字或比例演示更佳。