SQL Query Optimizers Explained
内容提要
本文介绍SQL查询优化器：SQL经解析、分析、优化、执行四步流程，优化器负责寻找代价最小的物理计划。优化器分为RBO和CBO：RBO基于经验规则重写查询，速度快但不保证最优；CBO利用代价模型和统计信息估算，通过贪心或动态规划选择最优计划。文章还介绍了Apache Calcite的RBO与CBO实现，以及云原生、湖仓一体、AI结合等趋势。
延伸解读
RBO与CBO：优化策略的本质差异
RBO基于经验规则重写查询，如谓词下推、列裁剪，实现简单且速度快，但不保证最优。CBO则通过代价模型和统计信息估算执行代价，使用贪心或动态规划选择计划，更可能找到高效方案。两者并非互斥，主流优化器常结合使用：RBO先做等价变换，CBO再从中选优。理解这一差异有助于判断查询性能瓶颈。
统计信息：CBO的基石与挑战
CBO依赖统计信息估算代价，包括表行数、列直方图等。统计信息收集有实时、手动和动态采样等方式，各有优劣。然而，CBO常假设列独立且数据均匀，现实却往往相反。例如车型与制造商关联时，独立假设会导致选择率估算错误。因此，识别列相关性并利用直方图处理非均匀数据，对优化效果至关重要。
Apache Calcite：开源优化器的典范
Calcite作为通用查询优化框架，内置RBO和CBO。其RBO（HepPlanner）通过模式匹配应用规则，简单快速；CBO（VolcanoPlanner）基于Volcano/Cascade框架，使用Memo结构存储候选计划，通过动态规划和剪枝高效搜索。Calcite的模块化设计支持多种数据模型，为大数据系统提供了可扩展的优化基础。
前沿趋势：云原生与AI驱动优化
大数据领域创业活跃，云原生和湖仓一体对优化器提出新要求：存储计算分离使弹性扩缩成为可能，湖仓一体需统一SQL查询。同时，AI与数据库结合日益紧密，如学习型优化器利用机器学习改进基数估计和代价模型，实现自配置、自诊断。这些趋势推动优化器向更智能、自适应方向发展。
Q&A
SQL查询优化器在SQL处理流程中处于什么位置？
SQL处理流程依次经过Parser、Analyzer、Optimizer和Executor。优化器位于Analyzer之后、Executor之前，负责将逻辑计划转换为物理执行计划，是数据库的大脑。
RBO和CBO有什么区别？
RBO基于启发式规则重写查询，实现简单、优化速度快，但不保证最优；CBO使用代价模型和统计信息估算执行计划代价，通过贪心或动态规划选择最优计划，在大数据场景下对性能至关重要。
CBO如何估算执行计划的代价？
CBO通过代价模型估算执行计划代价，代价等于所有算子代价之和，涉及CPU、内存、磁盘I/O、网络I/O等。算子代价依赖于输入数据的统计信息，如行数、每行大小等。
Apache Calcite的RBO和CBO是如何实现的？
Calcite RBO使用HepPlanner，通过Pattern匹配表达式子树并执行等价变换，内置100+优化规则；CBO使用VolcanoPlanner，基于Volcano/Cascade框架，采用Memo、动态规划和剪枝来搜索最优计划。
SQL查询优化器有哪些前沿趋势？
前沿趋势包括存储计算分离、云原生与Serverless、湖仓一体、DATA+AI（如AI4DB的自配置、自诊断、学习型优化器，以及DB4AI的数据库内嵌AI算法和机器学习框架）。
RBO常用的优化规则有哪些？
RBO常用优化规则包括列裁剪、谓词下推、传递闭包、Runtime Filter等，这些规则基于关系代数等价变换，旨在减少I/O、网络传输和计算开销。
