当Doris遇上福尔摩斯：一个数据库优化器的推理日记

作为一名数据分析师，你一定遇到过这样的场景：
写了一个看似简单的SQL查询，信心满满地点击执行，然后…不知不觉喝完三杯咖啡，查询还在默默转圈圈。"这也太慢了吧！"小王抓狂地盯着屏幕，心想着这个查询到底经历了什么。
其实，每个SQL查询背后都藏着一位神秘的优化专家 - Doris查询优化器。
一位经验丰富的数据库调优大师，既有老司机般的规则经验(RBO)，又有AI般的智能决策能力(CBO)。
让我们一起揭秘这位幕后英雄是如何让你的SQL查询速度飞起来的！

Doris智能化SQL优化引擎

每个数据分析师都经历过这样的时刻 - 一个看似简单的SQL查询花费了意想不到的长时间。

小王就遇到了这样的情况,他在处理一个包含多表关联的复杂分析需求时,查询执行时间长得惊人…SQL查询优化变得至关重要。

作为现代MPP数据库的佼佼者,Apache Doris在查询优化领域投入了大量精力。Doris的查询优化器像一位经验丰富的数据库调优专家,它既继承了传统RBO的成熟经验,又拥有现代CBO的智能决策能力。

优化器的执行流程大致分为以下几个步骤：

1. 语法分析： 优化器会尝试将 SQL 文本转换为抽象语法树（AST）。如果 SQL 文本合法，则继续进行后续步骤；如果非法，则会报错并终止执行。

2. 语义分析： 优化器会对 AST 中的元素进行语义分析。这一步骤会检查 SQL 查询中的表、列、函数等是否存在，以及它们的使用是否符合语法和语义规则。如果语义合法，则继续执行；如果语义非法，则会报错并终止执行。

3. 改写查询计划（RBO）： 在语法和语义分析之后，优化器会进行基于规则的优化（RBO）。这一步骤会通过一系列预定义的规则对查询计划进行改写，以确定性地优化执行速度。常见的优化手段包括列裁剪、谓词下推、分区裁剪等。

4. 优化查询计划（CBO）： 最后，优化器会进行基于代价的优化（CBO）。在这一步骤中，优化器会在搜索空间中枚举等价的计划集合，并评估它们的执行代价。通过比较不同计划的执行代价，优化器会选择代价最小的计划作为最终的执行计划。这一步骤旨在确保查询能够以最高效的方式执行，从而提供最佳的性能。

查询优化的演进之路

还记得老式数据库优化器是如何工作的吗?它们依靠一套固定的规则,就像遵循交通规则一样 - 遇到十字路口一定要减速。这种基于规则的优化器(RBO)在简单场景下表现不错,却难以应对复杂多变的查询场景。

现代查询优化器更像一个智能导航系统。它会收集道路实时情况(数据统计信息),综合考虑路况、距离等因素(多维度代价),为你推荐最优路线。这就是基于代价的优化器(CBO)的工作方式。

双剑合璧的优化策略

Doris查询优化器采用RBO与CBO相结合的方案,实现优化策略的最佳平衡。

RBO负责确定性的优化转换,包括:

• 常量表达式的预计算
• 复杂子查询的等价改写
• 过滤条件的下推优化
• 列裁剪减少数据读取

CBO则专注于需要代价权衡的场景:

• 多表Join顺序的智能调优
• 根据数据分布选择最优Join策略
• 利用统计信息进行精准的代价估算
• 在备选方案中筛选最优执行计划

好比一辆智能汽车,Doris查询优化器既需要遵守基本的交通规则(RBO),又要根据实时路况做出最优决策(CBO)。Doris优化器正是通过这种双剑合璧的方式,为用户提供最优的查询性能。

智能优化背后的故事

还记得前文被SQL查询难住的小王吗？让我们看看Doris查询优化器是如何帮他破解难题的。

数据侦探的实地调查

小王的查询就像一个复杂的案件,优化器化身数据侦探,开始收集各种"证据"。

"这张订单表有多少行数据？数据是不是存在倾斜？商品分类字段的去重值数量是多少？"优化器像个尽职的侦探,把这些关键信息都记录在了案件档案里。

福尔摩斯式的推理过程

掌握了关键数据后,优化器开始了福尔摩斯式的推理。

"考虑到订单表有10亿行数据,用户表只有100万行,显然应该选择广播Join策略！"优化器在心里暗暗分析。

"商品表的数据分布比较均匀,采用Shuffle Join更合适。"优化器继续推理。

就这样,优化器像破案高手一样,通过层层推理找出最佳的执行方案。

最佳方案的诞生

经过缜密的分析,优化器终于找到了破解小王SQL性能问题的关键：

• 将小表(用户表)广播到各个节点
• 对大表(订单表)采用动态分区策略
• 合理设置并行度,充分利用集群资源
• 选择合适的Join算法和执行顺序

神奇的事情发生了！原本需要30分钟的查询,现在只需要30秒就能完成。小王兴奋地说：“这简直就像魔法一样！”

优化器的优化之路

这个案例只是Doris查询优化器能力的冰山一角，Doris 查询优化器优势：

更聪明

优化器将每个 RBO（基于规则的优化）和 CBO（基于成本的优化）的优化点，以规则的形式清晰地呈现出来。针对每一个规则，优化器都提供了一组描述查询计划形状的模式，这些模式能够精确地匹配可优化的查询计划。因此，优化器能够更好地支持诸如多层子查询嵌套等更为复杂的查询语句。

同时，优化器的 CBO 基于先进的 Cascades 框架，充分利用了丰富的数据统计信息、数据特征信息以及精心调优的代价模型。这使得优化器在处理多表 Join 等复杂查询时，能够游刃有余，轻松应对。

更稳定

优化器的所有优化规则均在逻辑执行计划树上完成。查询语法语义解析完成后，查询会被转换为树状结构。相比旧优化器，新优化器的内部数据结构更为合理、统一。

以子查询处理为例，新优化器基于新的数据结构，避免了旧优化器中众多规则对子查询的单独处理，从而降低了优化规则出现逻辑错误的可能性。

更灵活

优化器的架构设计合理且现代，使得扩展优化规则和处理阶段变得非常方便。因此，我们能够迅速增加新的功能，以满足不断变化的新需求。

小王现在每次写SQL都特别有信心：“有这么强大的优化器在背后支持,我写的查询性能不会差！”

下期，我们将一起探讨其它更有趣有用有价值的内容，敬请期待！