This is an automated email from the ASF dual-hosted git repository.
kassiez pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new 8591743ea9c [Improvement](docs) refine query acceleration doc (#1584)
8591743ea9c is described below
commit 8591743ea9ca021aa86dfe3a5d99bab0a1a7f52f
Author: xzj7019 <xiongzhongj...@selectdb.com>
AuthorDate: Tue Dec 24 20:52:33 2024 +0800
[Improvement](docs) refine query acceleration doc (#1584)
## Versions
- [x] dev
- [ ] 3.0
- [ ] 2.1
- [ ] 2.0
## Languages
- [x] Chinese
- [x] English
## Docs Checklist
- [ ] Checked by AI
- [ ] Test Cases Built
---
.../current/query-acceleration/hints/distribute-hint.md | 4 ++--
.../current/query-acceleration/hints/leading-hint.md | 10 +++++-----
.../tuning/tuning-plan/accelerating-queries-with-sql-cache.md | 7 ++++++-
.../tuning/tuning-plan/adjusting-join-shuffle.md | 10 +++++-----
.../tuning/tuning-plan/controlling-hints-with-cbo-rule.md | 4 ++--
.../query-acceleration/tuning/tuning-plan/dml-tuning-plan.md | 2 +-
.../tuning/tuning-plan/optimizing-join-with-colocate-group.md | 4 ++--
.../tuning/tuning-plan/optimizing-table-index.md | 2 +-
.../tuning/tuning-plan/transparent-rewriting-with-async-mv.md | 4 ++--
.../tuning/tuning-plan/transparent-rewriting-with-sync-mv.md | 6 +++---
10 files changed, 29 insertions(+), 24 deletions(-)
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/distribute-hint.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/distribute-hint.md
index 3964fa18b17..4b8d5ae99f4 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/distribute-hint.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/distribute-hint.md
@@ -36,7 +36,7 @@ Distribute hint 用来控制 join 的 shuffle 方式。
## 案例
-1. **与 Ordered Hint 混用**
+**与 Ordered Hint 混用**
把 Join 顺序固定为文本序，然后再指定相应的 Join 预期使用的 Distribute 方式。例如：
@@ -93,7 +93,7 @@ Explain Shape Plan 里面会显示 Distribute 算子相关的信息。其中：
- `DistributionSpecGather` 表示将数据 Gather 到 FE 节点；
- `DistributionSpecHash` 表示将数据按照特定的 hashKey 以及算法打散到不同的 BE 节点。
-1. **与 Leading Hint 混用**
+**与 Leading Hint 混用**
在编写 SQL 查询时，可以在使用 `LEADING` 提示的同时，为每个 `JOIN` 操作指定相应的 `DISTRIBUTE`
方式。以下是一个具体的例子，展示了如何在 SQL 查询中混合使用 `Distribute Hint` 和 `Leading Hint`。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/leading-hint.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/leading-hint.md
index be1f217d284..a83a1569626 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/leading-hint.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/hints/leading-hint.md
@@ -437,11 +437,11 @@ Ordered hint 可以看做 leading hint 的一种特例，用于控制 join order
### 语法
-OrderedHint 的语法为 `/*+ ORDERED */`，放置在 `SELECT` 语句中的 `SELECT` 关键字之后，紧接着查询的其余部分。
+Ordered Hint 的语法为 `/*+ ORDERED */`，放置在 `SELECT` 语句中的 `SELECT` 关键字之后，紧接着查询的其余部分。
### 案例
-以下是一个使用 OrderedHint 的示例：
+以下是一个使用 Ordered Hint 的示例：
```sql
mysql> explain shape plan select /*+ ORDERED */ t1.c1 from t2 join t1 on t1.c1
= t2.c2 join t3 on c2 = c3;
@@ -469,9 +469,9 @@ mysql> explain shape plan select /*+ ORDERED */ t1.c1 from
t2 join t1 on t1.c1 =
+--------------------------------------------------------------------------------+
```
-与 LeadingHint 的关系：
+与 Leading Hint 的关系：
-当 OrderedHint 和 LeadingHint 同时使用时，OrderedHint 将优先于 LeadingHint。这意味着，即使指定了
LeadingHint，如果同时存在 OrderedHint，查询计划将按照 OrderedHint 的规则来执行，而 LeadingHint
将被忽略。以下是一个示例，展示了当两者同时使用时的情况：
+当 Ordered Hint 和 Leading Hint 同时使用时，Ordered Hint 将优先于 Leading Hint。这意味着，即使指定了
Leading Hint，如果同时存在 Ordered Hint，查询计划将按照 Ordered Hint 的规则来执行，而 Leading Hint
将被忽略。以下是一个示例，展示了当两者同时使用时的情况：
```sql
mysql> explain shape plan select /*+ ORDERED LEADING(t1 t2 t3) */ t1.c1 from
t2 join t1 on t1.c1 = t2.c2 join t3 on c2 = c3;
@@ -501,4 +501,4 @@ mysql> explain shape plan select /*+ ORDERED LEADING(t1 t2
t3) */ t1.c1 from t2
## 总结
-Leading hint 是一个强大的手工控制 join order 的特性，在生产业务调优中应用广泛。使用好 leading hint 能够满足现场针对
join order 的调优需求，增加系统控制的灵活性。Ordered hint 是一种特殊的 leading hint，用于固定当前业务的 join
order 为文本序，使用时需要注意和其他 Hint 之间的优先级关系。
+Leading Hint 是一个强大的手工控制 join order 的特性，在生产业务调优中应用广泛。使用好 leading hint 能够满足现场针对
join order 的调优需求，增加系统控制的灵活性。Ordered hint 是一种特殊的 leading hint，用于固定当前业务的 join
order 为文本序，使用时需要注意和其他 Hint 之间的优先级关系。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/accelerating-queries-with-sql-cache.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/accelerating-queries-with-sql-cache.md
index 1ff103a109a..0cdbb3676a4 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/accelerating-queries-with-sql-cache.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/accelerating-queries-with-sql-cache.md
@@ -26,7 +26,7 @@ under the License.
## 概述
-关于 SQL Cache 详细实现原理，请参考 [查询缓存（SQL
Cache）](../../../query-acceleration/sql-cache-manual)
+关于 SQL Cache 详细实现原理，请参考 [查询缓存（SQL
Cache）](../../../query-acceleration/sql-cache-manual)章节
## 案例
@@ -35,3 +35,8 @@ under the License.
## 总结
SQL Cache 是 Doris 提供的一种查询优化机制，可以显著提升查询性能。在使用的时候需要注意：
+:::tips 提示
+- SQL Cache 不适用于包含生成随机值的函数 (如 `random()`) 的查询，因为这会导致查询结果失去随机性。
+- 目前不支持使用部分指标的缓存结果来满足查询更多指标的需求。例如，之前查询了 2 个指标的缓存不能用于查询 3 个指标的情况。
+- 通过合理使用 SQL Cache，可以显著提升 Doris
的查询性能，特别是在数据更新频率较低的场景中。在实际应用中，需要根据具体的数据特征和查询模式来调整缓存参数，以获得最佳的性能提升。
+:::
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/adjusting-join-shuffle.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/adjusting-join-shuffle.md
index d664304b6fb..32a653b03e4 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/adjusting-join-shuffle.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/adjusting-join-shuffle.md
@@ -28,7 +28,7 @@ under the License.
Doris 支持使用 Hint 来调整 Join 操作中数据 Shuffle 的类型，从而优化查询性能。本节将详细介绍如何在 Doris 中利用 Hint
来指定 Join Shuffle 的类型。
-目前，Doris 支持两种独立的
[DistributeHint](../../../query-acceleration/hints/distribute-hint.md)，`[shuffle]
` 和 `[broadcast]`，用来指定 Join 右表的 Distribute Type。Distribute Type 需置于 Join
右表之前，采用中括号 `[]` 的方式。同时，Doris 也可以通过 LeadingHint 配合 DistributeHint 的方式，指定 shuffle
方式（详见[使用 Leading Hint 控制 Join 顺序](reordering-join-with-leading-hint.md)章节相关介绍）。
+目前，Doris 支持两种独立的 [Distribute
Hint](../../../query-acceleration/hints/distribute-hint.md)，`[shuffle] ` 和
`[broadcast]`，用来指定 Join 右表的 Distribute Type。Distribute Type 需置于 Join 右表之前，采用中括号
`[]` 的方式。同时，Doris 也可以通过 Leading Hint 配合 Distribute Hint 的方式，指定 shuffle 方式（详见[使用
Leading Hint 控制 Join 顺序](reordering-join-with-leading-hint.md)章节相关介绍）。
示例如下：
@@ -39,13 +39,13 @@ SELECT COUNT(*) FROM t2 JOIN [shuffle] t1 ON t1.c1 = t2.c2;
## 案例
-接下来将通过同一个例子来展示 DistributeHint 的使用方法：
+接下来将通过同一个例子来展示 Distribute Hint 的使用方法：
```sql
EXPLAIN SHAPE PLAN SELECT COUNT(*) FROM t1 JOIN t2 ON t1.c1 = t2.c2;
```
-原始 SQL 的计划如下，可见 t1 连接 t2 使用了 hash distribute（"DistributionSpecHash"）的方式。
+原始 SQL 的计划如下，可见 t1 连接 t2 使用了 hash distribute即`DistributionSpecHash`的方式。
```sql
+----------------------------------------------------------------------------------+
@@ -71,7 +71,7 @@ EXPLAIN SHAPE PLAN SELECT COUNT(*) FROM t1 JOIN t2 ON t1.c1 =
t2.c2;
EXPLAIN SHAPE PLAN SELECT COUNT(*) FROM t1 JOIN [broadcast] t2 ON t1.c1 =
t2.c2;
```
-可见 t1 连接 t2 的分发方式改为了 broadcast（"DistributionSpecReplicated"）的方式。
+可见 t1 连接 t2 的分发方式改为了 broadcast即`DistributionSpecReplicated`的方式。
```sql
+----------------------------------------------------------------------------------+
@@ -93,4 +93,4 @@ EXPLAIN SHAPE PLAN SELECT COUNT(*) FROM t1 JOIN [broadcast]
t2 ON t1.c1 = t2.c2;
## 总结
-通过合理使用 DistributeHint，可以优化 Join 操作的 Shuffle 方式，提升查询性能。在实践中，建议先通过 EXPLAIN
分析查询执行计划，再根据实际情况指定合适的 Shuffle 类型。
+通过合理使用 Distribute Hint，可以优化 Join 操作的 Shuffle 方式，提升查询性能。在实践中，建议先通过 EXPLAIN
分析查询执行计划，再根据实际情况指定合适的 Shuffle 类型。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/controlling-hints-with-cbo-rule.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/controlling-hints-with-cbo-rule.md
index 3d8b364dc67..d3be60d2c70 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/controlling-hints-with-cbo-rule.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/controlling-hints-with-cbo-rule.md
@@ -39,7 +39,7 @@ CBO 规则控制 Hint 的基本语法如下所示：
SELECT /*+ USE_CBO_RULE(rule1, rule2, ...) */ ...
```
-此 Hint 紧跟在 SELECT 关键字之后，并在括号内指定要启用的规则名称（规则名称不区分大小写）。
+此 Hint 紧跟在 `SELECT` 关键字之后，并在括号内指定要启用的规则名称（规则名称不区分大小写）。
当前 Doris 优化器支持若干中代价改写，可以通过 `USE_CBO_RULE` hint 来显式启用，例如：
@@ -81,4 +81,4 @@ PhysicalResultSink
## 总结
-合理使用 `USE_CBO_RULE hint`，可以帮助手动启用部分高级 CBO 优化规则，在特定场景下优化性能。但是使用 CBO
优化规则需要对查询优化过程和数据特性有深入的理解，在大多数情况下，依赖 Doris 优化器的自动决策仍然是最佳的选择。
+合理使用 `USE_CBO_RULE` hint，可以帮助手动启用部分高级 CBO 优化规则，在特定场景下优化性能。但是使用 CBO
优化规则需要对查询优化过程和数据特性有深入的理解，在大多数情况下，依赖 Doris 优化器的自动决策仍然是最佳的选择。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/dml-tuning-plan.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/dml-tuning-plan.md
index c5b6307ac94..be482e98eaf 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/dml-tuning-plan.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/dml-tuning-plan.md
@@ -24,6 +24,6 @@ specific language governing permissions and limitations
under the License.
-->
-DML 计划调优首先需要定位是导入引起的性能瓶颈，还是查询部分引起的性能瓶颈 。查询部分的性能瓶颈的排查和调优详见计划调优章节其他小节。
+DML 计划调优首先需要定位是导入引起的性能瓶颈，还是查询部分引起的性能瓶颈
。查询部分的性能瓶颈的排查和调优详见[计划调优](optimizing-table-schema.md)其他小节。
Doris 支持从多种数据源导入数据，灵活运用 Doris 提供的多种导入功能，可以高效地将各种来源的数据导入到 Doris
中进行分析。最佳实践详情请参考[导入概览](../../../data-operate/import/load-manual.md)。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-join-with-colocate-group.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-join-with-colocate-group.md
index e58b49e0787..596098063e9 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-join-with-colocate-group.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-join-with-colocate-group.md
@@ -24,11 +24,11 @@ specific language governing permissions and limitations
under the License.
-->
-Colocate Group 是一种高效的 Join 方式，使得执行引擎能有效地规避 Join 操作中数据的shuffle开销。相关原理介绍和案例参考详见
[Colocate-join](../../colocation-join.md)）
+Colocate Group 是一种高效的 Join 方式，使得执行引擎能有效地规避 Join 操作中数据的shuffle开销。相关原理介绍和案例参考详见
[Colocate-join](../../colocation-join.md)
:::tip 注意
- 在某些场景下，即使已经成功建立了 Colocate Group，执行计划（plan）仍然可能会显示为 `Shuffle Join` 或 `Bucket
Shuffle Join`。这种情况通常发生在 Doris 正在进行数据整理的过程中，比如，它可能在 BE 间迁移 tablet，以确保数据在多个 BE
之间的分布达到更加均衡的状态。
-- 通过命令`show proc "/colocation_group"`;可以查看 Colocate Group 状态，如下图所示：`IsStable`
出现false，表示有 colocation_group 不可用的情况。
+- 通过命令`show proc "/colocation_group"`;可以查看 Colocate Group 状态，如下图所示：`IsStable`
出现false，表示有 Colocate Group 不可用的情况。
:::
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-table-index.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-table-index.md
index 1037ef95341..98cb1a8d60c 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-table-index.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/optimizing-table-index.md
@@ -84,7 +84,7 @@ PROPERTIES (
Doris 支持倒排索引作为二级索引，以加速等值、范围及文本类型的全文检索等业务场景。倒排索引的创建和管理是独立的，它能够在不影响原始表 Schema
和无需重新导入表数据的情况下，便捷地进行业务性能优化。
-关于典型的使用场景、语法及案例，可参考[表索引 -
倒排索引](../../../table-design/index/inverted-index.md)，查看详细介绍，本章节不再重复阐述。
+关于典型的使用场景、语法及案例，可参考[倒排索引](../../../table-design/index/inverted-index.md)，查看详细介绍，本章节不再重复阐述。
:::tip 优化建议
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-async-mv.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-async-mv.md
index 4fee2a3262f..343beb8f428 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-async-mv.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-async-mv.md
@@ -154,7 +154,7 @@ mysql> explain shape plan SELECT l_shipdate,
SUM(o_totalprice) AS total_price
## 总结
-通过使用物化视图， 可以显著提高查询性能， 特别是对于复杂的聚合查询。在使用的时候需要注意：
+通过使用多表物化视图， 可以显著提高查询性能， 特别是对于复杂的连接和聚合查询。在使用的时候需要注意：
:::tip 使用建议
- 预计算结果： 物化视图将查询结果预先计算并存储，避免了每次查询时重复计算的开销。这对于需要频繁执行的复杂查询尤其有效。
@@ -165,4 +165,4 @@ mysql> explain shape plan SELECT l_shipdate,
SUM(o_totalprice) AS total_price
- 适用场景： 物化视图适用于数据变化频率较低、查询频率较高的场景。对于经常变化的数据，实时计算可能更为合适。
:::
-合理利用物化视图，可以显著改善数据库的查询性能，特别是在复杂查询和大数据量的情况下。同时，也需要综合考虑存储、维护等因素，以实现性能和成本的平衡。
+合理利用多表物化视图，可以显著改善数据库的查询性能，特别是在复杂查询和大数据量的情况下。同时，也需要综合考虑存储、维护等因素，以实现性能和成本的平衡。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-sync-mv.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-sync-mv.md
index 4d1f7246bf3..bb771b1955d 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-sync-mv.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/tuning/tuning-plan/transparent-rewriting-with-sync-mv.md
@@ -26,7 +26,7 @@ under the License.
## 概述
-[单表物化视图](../../materialized-view/sync-materialized-view.md) （Materialized
View） 是一种特殊的表，它预先根据定义好的 SELECT
语句计算并存储数据。其主要目的是满足用户对原始明细数据的任意维度分析需求，同时也能快速地进行固定维度的分析查询。
+[物化视图](../../materialized-view/sync-materialized-view.md) （Materialized View）
是一种特殊的表，它预先根据定义好的 SELECT
语句计算并存储数据。其主要目的是满足用户对原始明细数据的任意维度分析需求，同时也能快速地进行固定维度的分析查询。
物化视图的适用场景为：
@@ -37,8 +37,8 @@ under the License.
对于频繁重复使用相同子查询结果的查询，单表同步物化视图能显著提升性能。Doris 会自动维护物化视图的数据，确保基础表 （Base Table）
和物化视图表的数据一致性，无需额外的人工维护成本。在查询时，系统会自动匹配到最优的物化视图，并直接从物化视图中读取数据。
-：::tip 注意事项
-- 在 Doris 2.0
版本中，物化视图具备了一些增强功能。建议用户在正式的生产环境中使用物化视图之前，先在测试环境中确认预期中的查询能否命中想要创建的物化视图。
+:::tip 注意事项
+- 在 Doris 2.0
及后续版本中，物化视图具备了一些增强功能。建议用户在正式的生产环境中使用物化视图之前，先在测试环境中确认预期中的查询能否命中想要创建的物化视图。
- 不建议在同一张表上创建多个形态类似的物化视图，因为这可能会导致多个物化视图之间的冲突，从而使查询命中失败。
:::
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
