查询反馈
本主题介绍查询反馈功能、其应用场景以及如何使用查询计划顾问根据执行统计信息优化查询计划。
StarRocks 从 v3.4.0 版本开始支持查询反馈功能。
概述
查询反馈是基于成本优化器 (CBO) 的一个框架和关键组件。它记录查询执行期间的执行统计信息，并在后续具有类似查询计划的查询中重复使用它，以帮助 CBO 生成优化的查询计划。 CBO 基于估计的统计信息优化查询计划，因此当统计信息过期或不准确时，它可能会选择低效的查询计划（不良计划），例如广播大表或错误地对左右表进行排序。 这些不良计划可能会导致查询执行超时、资源消耗过多，甚至系统崩溃。
工作流程
基于查询反馈的计划优化工作流程包括三个阶段
- 观察：BE 或 CN 记录每个查询计划中 PlanNode 的主要指标（包括
InputRows和OutputRows）。 - 分析：对于超过配置阈值的慢查询以及手动标记为要分析的查询，系统将在查询完成后和返回结果之前分析关键节点的执行详细信息，以识别当前查询计划中的优化机会。 FE 将查询计划与执行统计信息进行比较，并检查查询是否是由异常查询计划引起的慢查询。 当 FE 分析不准确的统计信息时，它将为每个查询生成 SQL 调整指南，指示 CBO 动态优化查询，并推荐提高性能的策略。
- 优化：CBO 生成物理计划后，它将搜索适用于该计划的任何现有调整指南。 如果有，CBO 将根据指南和策略动态优化计划，纠正有问题的部分，从而消除由于重复使用不良查询计划而对查询性能产生的影响。 优化计划的执行时间与原始计划的执行时间进行比较，以评估调整的有效性。
用法
由系统变量 enable_plan_advisor（默认值：true）控制，查询计划顾问程序默认对慢查询启用，即执行时间超过 FE 配置项 slow_query_analyze_threshold（默认值：5 秒）中定义的阈值的查询。
此外，您可以手动分析特定查询或为所有执行的查询启用自动分析。
手动分析特定查询
即使特定查询语句的执行时间未超过 slow_query_analyze_threshold，您也可以手动分析该语句。
ALTER PLAN ADVISOR ADD <query_statement>
示例
ALTER PLAN ADVISOR ADD SELECT COUNT(*) FROM (
SLECT * FROM c1_skew_left_over t1
JOIN (SELECT * FROM c1_skew_left_over WHERE c1 = 'c') t2
ON t1.c2 = t2.c2 WHERE t1.c1 > 'c' ) t;
为所有查询启用自动分析
要为所有查询启用自动分析，您需要将系统变量 enable_plan_analyzer（默认值：false) 设置为 true`。
SET enable_plan_analyzer = true;
显示当前 FE 上的调整指南
每个 FE 维护自己的调整指南记录。 您可以使用以下语句查看为当前 FE 上有权查询生成的调整指南
SHOW PLAN ADVISOR
检查调整指南是否生效
针对查询语句执行 EXPLAIN。 在 EXPLAIN 字符串中，消息 Plan had been tuned by Plan Advisor 表示调整指南已应用于相应的查询。
示例
EXPLAIN SELECT COUNT(*) FROM (
SLECT * FROM c1_skew_left_over t1
JOIN (SELECT * FROM c1_skew_left_over WHERE c1 = 'c') t2
ON t1.c2 = t2.c2 WHERE t1.c1 > 'c' ) t;
+-----------------------------------------------------------------------------------------------+
| Explain String |
+-----------------------------------------------------------------------------------------------+
| Plan had been tuned by Plan Advisor. |
| Original query id:8e010cf4-b178-11ef-8aa4-8a5075cec65e |
| Original time cost: 148 ms |
| 1: LeftChildEstimationErrorTuningGuide |
| Reason: left child statistics of JoinNode 5 had been overestimated. |
| Advice: Adjust the distribution join execution type and join plan to improve the performance. |
| |
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:9: count |
| PARTITION: UNPARTITIONED
删除特定查询的调整指南
您可以根据从 SHOW PLAN ADVISOR 返回的查询 ID 删除特定查询的调整指南。
ALTER PLAN ADVISOR DROP <query_id>
示例
ALTER PLAN ADVISOR DROP "8e010cf4-b178-11ef-8aa4-8a5075cec65e";
清除当前 FE 上的所有调整指南
要清除当前 FE 上的所有调整指南，请执行以下语句
TRUNCATE PLAN ADVISOR
用例
目前，查询反馈主要用于优化以下场景
- 优化本地 Join 节点中左右两侧的顺序
- 优化本地 Join 节点的执行方法（例如，从 Broadcast 切换到 Shuffle）
- 对于具有显着聚合潜力的案例，强制执行
pre_aggregation模式以最大化第一阶段的数据聚合
调整指南主要基于指标 Runtime Exec Node Input/Output Rows 和 FE statistics estimated rows。 由于当前的调整阈值相对保守，因此我们建议您利用查询反馈来检查查询 Profile 或 EXPLAIN 字符串中观察到的潜在性能改进问题。
以下是三个常见的用户案例。
案例 1：Join 顺序不正确
原始不良计划
small left table inner join large table (broadcast)
优化计划
large left table inner join small right table (broadcast)
原因 该问题可能是由于过时或缺失的统计信息引起的，这导致基于成本的优化器 (CBO) 根据不准确的数据生成不正确的计划。
解决方案 在查询执行期间，系统会比较左子项和右子项的 input/output rows 和 statistics estimated rows，从而生成调整指南。 重新执行后，系统会自动调整 Join 顺序。
案例 2：Join 执行方法不正确
原始不良计划
large left table1 inner join large right table2 (broadcast)
优化计划
large left table1 (shuffle) inner join large right table2 (shuffle)
原因 该问题可能是由数据倾斜导致的。 当右表有多个分区，其中一个分区包含不成比例的大量数据时，系统可能会错误地估计应用谓词后右表的行数。
解决方案 在查询执行期间，系统会比较左子项和右子项的 input/output rows 和 statistics estimated rows，从而生成调整指南。 优化后，Join 方法将从 Broadcast Join 调整为 Shuffle Join。
案例 3：第一阶段预聚合模式效率低下
症状 对于具有良好聚合潜力的数据，第一阶段聚合的 auto 模式可能只会聚合少量本地数据，从而错失了性能提升的机会。
解决方案 在查询执行期间，系统会收集本地聚合和全局聚合的 Input/Output Rows。 根据历史数据，它评估聚合列的潜力。 如果潜力显着，系统会强制在本地聚合中使用 pre_aggregation 模式，从而最大化第一阶段的数据聚合并提高整体查询性能。
局限性
- 调整指南只能用于生成它的完全相同的查询。 它不适用于具有相同模式但参数不同的查询。
- 每个 FE 独立管理其查询计划顾问程序，不支持跨 FE 节点的同步。 如果将相同的查询提交到不同的 FE 节点，则调整结果可能会有所不同。
- 查询计划顾问程序使用内存缓存结构
- 当调整指南的数量超过限制时，过期的调整指南会自动驱逐。
- 调整指南的默认限制为 300，不支持历史调整指南的持久性。