[opt](sql cache) Reorganize the chapter on SQL Cache (apache#1392)

# Versions 

- [x] dev
- [x] 3.0
- [x] 2.1
- [ ] 2.0

# Languages

- [x] Chinese
- [x] English

docs/query-acceleration/sql-cache-manual.md

@@ -24,6 +24,8 @@ specific language governing permissions and limitations
 under the License.
 -->
 
+## Description
+
 SQL Cache is a query optimization mechanism provided by Doris that can significantly enhance query performance. It reduces redundant computations by caching query results, making it suitable for scenarios where data update frequency is low.
 
 SQL Cache stores and retrieves caches based on the following key factors:
@@ -50,6 +52,18 @@ SQL Cache is highly suitable for T+1 update scenarios. Data is updated early in
 
 Currently, SQL Cache supports both internal OlapTables and external Hive tables.
 
+## Usage Limitations
+
+### Non-Deterministic Functions
+
+Non-deterministic functions refer to those whose computation results do not form a fixed relationship with their input parameters.
+
+Take the common function `select now()` as an example. It returns the current date and time. Since this function returns different results when executed at different times, its return value is dynamically changing. The `now` function returns time at the second level, so SQL Cache from the previous second can be reused within the same second; however, a new SQL Cache needs to be created for the next second.
+
+To optimize cache utilization, it is recommended to convert such fine-grained time into coarse-grained time, such as using `select * from tbl where dt=date(now())`. In this case, queries within the same day can leverage the SQL Cache.
+
+In contrast, the `random()` function is difficult to utilize Cache because its results vary each time it is executed. Therefore, the use of such non-deterministic functions in queries should be avoided as much as possible.
+
 ## Principles
 
 ### BE Principle
@@ -70,7 +84,7 @@ When the BE returns the computation results to the FE, the FE is responsible for
 
 Additionally, if the SQL optimization phase determines that the query results contain only 0 or 1 row of data, the FE will choose to store these results in its memory to respond more quickly to potential future identical queries.
 
-## Best Practices
+## Get Started
 
 ### Enabling and Disabling SQL Cache
 
@@ -147,7 +161,7 @@ Execution  Summary:
 
 Both methods provide effective means for users to verify whether queries utilize the SQL Cache, helping users better assess query performance and optimize query strategies.
 
-### Statistics on Cache Metrics
+## Metrics and Monitor
 
 **1. The HTTP interface on the FE `http://${FE_IP}:${FE_HTTP_PORT}/metrics` returns two relevant metrics:**
 
@@ -181,6 +195,8 @@ Different caches may be stored in different BEs, so metrics from all BEs need to
 
 :::
 
+## Memory Control
+
 ### FE Memory Control
 
 In FE, the metadata information of Cache is set to weak references. When FE memory is insufficient, the system will automatically release the least recently used Cache metadata. Additionally, users can further limit FE memory usage by executing the following SQL statements. This configuration takes effect in real-time and needs to be set for each FE. For persistent configuration, it should be saved in the fe.conf file.
@@ -214,7 +230,7 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');
 ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 ```
 
-### Troubleshooting Cache Invalidation
+## Troubleshooting Cache Invalidation
 
 The reasons for cache invalidation typically include the following:
 
@@ -233,15 +249,3 @@ The reasons for cache invalidation typically include the following:
 7. The result row count exceeds the FE-configured `cache_result_max_row_count`, with a default value of 3000 rows.
 
 8. The result size exceeds the FE-configured `cache_result_max_data_size`, with a default value of 30MB.
-
-## Usage Limitations
-
-### Non-Deterministic Functions
-
-Non-deterministic functions refer to those whose computation results do not form a fixed relationship with their input parameters.
-
-Take the common function `select now()` as an example. It returns the current date and time. Since this function returns different results when executed at different times, its return value is dynamically changing. The `now` function returns time at the second level, so SQL Cache from the previous second can be reused within the same second; however, a new SQL Cache needs to be created for the next second.
-
-To optimize cache utilization, it is recommended to convert such fine-grained time into coarse-grained time, such as using `select * from tbl where dt=date(now())`. In this case, queries within the same day can leverage the SQL Cache.
-
-In contrast, the `random()` function is difficult to utilize Cache because its results vary each time it is executed. Therefore, the use of such non-deterministic functions in queries should be avoided as much as possible.

i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/sql-cache-manual.md

@@ -24,7 +24,6 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-
 ## 概念介绍
 
 SQL Cache 是 Doris 提供的一种查询优化机制，可以显著提升查询性能。它通过缓存查询结果来减少重复计算，适用于数据更新频率较低的场景。
@@ -53,6 +52,18 @@ SQL Cache 非常适合 T+1 更新场景。数据在凌晨更新，第一次查
 
 目前，SQL Cache 支持 OlapTable 内部表和 Hive 外部表。
 
+## 使用限制
+
+### 非确定函数
+
+非确定函数是指其运算结果与输入参数之间无法形成固定关系的函数。
+
+以常见函数 `select now()` 为例，它返回当前的日期与时间。由于该函数在不同时间执行时会返回不同的结果，因此其返回值是动态变化。`now` 函数返回的是秒级别的时间，所以在同一秒内可以复用之前的 SQL Cache；但下一秒之后，就需要重新创建 SQL Cache。
+
+为了优化缓存利用率，建议将这种细粒度的时间转为粗粒度的时间，例如使用 `select * from tbl where dt=date(now())`。在这种情况下，同一天的查询都可以利用到 SQL Cache。
+
+相比之下，`random()` 函数则很难利用到 Cache，因为它每次运算的结果都是不同的。因此，应尽量避免在查询中使用这类非确定函数。
+
 ## 实现原理
 
 ### BE 实现原理
@@ -73,7 +84,7 @@ SQL Cache 非常适合 T+1 更新场景。数据在凌晨更新，第一次查
 
 此外，如果 SQL 优化阶段判断出查询结果仅包含 0 行或 1 行数据，FE 会选择将这些结果保存在其内存中，以便更快速地响应未来可能的相同查询。
 
-## 最佳实践
+## 快速上手
 
 ### 开启和关闭 SQL Cache
 
@@ -150,7 +161,7 @@ Execution  Summary:
 
 这两种方法均为用户提供了有效的手段来验证查询是否利用了 SQL Cache，从而帮助用户更好地评估查询性能并优化查询策略。
 
-### 统计缓存的指标
+## 指标监控
 
 **1. 在 FE 的 HTTP 接口** **`http://${FE_IP}:${FE_HTTP_PORT}/metrics`** **会返回两个相关指标：**
 
@@ -184,6 +195,8 @@ doris_be_query_cache_memory_total_byte 44101
 
 :::
 
+## 内存控制
+
 ### FE 内存控制
 
 在 FE 中，Cache 的元数据信息被设置为弱引用。当 FE 内存不足时，系统会自动释放最近最久未使用的 Cache 元数据。此外，用户还可以通过执行以下 SQL 语句，进一步限制 FE 内存的使用量。此配置实时生效，且每个 FE 都需要进行配置。若需持久化配置，则需将其保存在 fe.conf 文件中。
@@ -217,7 +230,7 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');
 ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 ```
 
-### 排查缓存失效原因
+## 排查缓存失效原因
 
 缓存失效原因一般包括以下几点：
 
@@ -236,15 +249,3 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 7. 结果行数超过了 FE 配置的 `cache_result_max_row_count`，默认值为 3000 行。
 
 8. 结果大小超过了 FE 配置的 `cache_result_max_data_size`，默认值为 30MB。
-
-## 使用限制
-
-### 非确定函数
-
-非确定函数是指其运算结果与输入参数之间无法形成固定关系的函数。
-
-以常见函数 `select now()` 为例，它返回当前的日期与时间。由于该函数在不同时间执行时会返回不同的结果，因此其返回值是动态变化。`now` 函数返回的是秒级别的时间，所以在同一秒内可以复用之前的 SQL Cache；但下一秒之后，就需要重新创建 SQL Cache。
-
-为了优化缓存利用率，建议将这种细粒度的时间转为粗粒度的时间，例如使用 `select * from tbl where dt=date(now())`。在这种情况下，同一天的查询都可以利用到 SQL Cache。
-
-相比之下，`random()` 函数则很难利用到 Cache，因为它每次运算的结果都是不同的。因此，应尽量避免在查询中使用这类非确定函数。

i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query-acceleration/sql-cache-manual.md

@@ -24,7 +24,6 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-
 ## 概念介绍
 
 SQL Cache 是 Doris 提供的一种查询优化机制，可以显著提升查询性能。它通过缓存查询结果来减少重复计算，适用于数据更新频率较低的场景。
@@ -53,6 +52,18 @@ SQL Cache 非常适合 T+1 更新场景。数据在凌晨更新，第一次查
 
 目前，SQL Cache 支持 OlapTable 内部表和 Hive 外部表。
 
+## 使用限制
+
+### 非确定函数
+
+非确定函数是指其运算结果与输入参数之间无法形成固定关系的函数。
+
+以常见函数 `select now()` 为例，它返回当前的日期与时间。由于该函数在不同时间执行时会返回不同的结果，因此其返回值是动态变化。`now` 函数返回的是秒级别的时间，所以在同一秒内可以复用之前的 SQL Cache；但下一秒之后，就需要重新创建 SQL Cache。
+
+为了优化缓存利用率，建议将这种细粒度的时间转为粗粒度的时间，例如使用 `select * from tbl where dt=date(now())`。在这种情况下，同一天的查询都可以利用到 SQL Cache。
+
+相比之下，`random()` 函数则很难利用到 Cache，因为它每次运算的结果都是不同的。因此，应尽量避免在查询中使用这类非确定函数。
+
 ## 实现原理
 
 ### BE 实现原理
@@ -73,7 +84,7 @@ SQL Cache 非常适合 T+1 更新场景。数据在凌晨更新，第一次查
 
 此外，如果 SQL 优化阶段判断出查询结果仅包含 0 行或 1 行数据，FE 会选择将这些结果保存在其内存中，以便更快速地响应未来可能的相同查询。
 
-## 最佳实践
+## 快速上手
 
 ### 开启和关闭 SQL Cache
 
@@ -150,7 +161,7 @@ Execution  Summary:
 
 这两种方法均为用户提供了有效的手段来验证查询是否利用了 SQL Cache，从而帮助用户更好地评估查询性能并优化查询策略。
 
-### 统计缓存的指标
+## 指标监控
 
 **1. 在 FE 的 HTTP 接口** **`http://${FE_IP}:${FE_HTTP_PORT}/metrics`** **会返回两个相关指标：**
 
@@ -184,6 +195,8 @@ doris_be_query_cache_memory_total_byte 44101
 
 :::
 
+## 内存控制
+
 ### FE 内存控制
 
 在 FE 中，Cache 的元数据信息被设置为弱引用。当 FE 内存不足时，系统会自动释放最近最久未使用的 Cache 元数据。此外，用户还可以通过执行以下 SQL 语句，进一步限制 FE 内存的使用量。此配置实时生效，且每个 FE 都需要进行配置。若需持久化配置，则需将其保存在 fe.conf 文件中。
@@ -217,7 +230,7 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');
 ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 ```
 
-### 排查缓存失效原因
+## 排查缓存失效原因
 
 缓存失效原因一般包括以下几点：
 
@@ -236,15 +249,3 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 7. 结果行数超过了 FE 配置的 `cache_result_max_row_count`，默认值为 3000 行。
 
 8. 结果大小超过了 FE 配置的 `cache_result_max_data_size`，默认值为 30MB。
-
-## 使用限制
-
-### 非确定函数
-
-非确定函数是指其运算结果与输入参数之间无法形成固定关系的函数。
-
-以常见函数 `select now()` 为例，它返回当前的日期与时间。由于该函数在不同时间执行时会返回不同的结果，因此其返回值是动态变化。`now` 函数返回的是秒级别的时间，所以在同一秒内可以复用之前的 SQL Cache；但下一秒之后，就需要重新创建 SQL Cache。
-
-为了优化缓存利用率，建议将这种细粒度的时间转为粗粒度的时间，例如使用 `select * from tbl where dt=date(now())`。在这种情况下，同一天的查询都可以利用到 SQL Cache。
-
-相比之下，`random()` 函数则很难利用到 Cache，因为它每次运算的结果都是不同的。因此，应尽量避免在查询中使用这类非确定函数。

i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/query-acceleration/sql-cache-manual.md

@@ -24,7 +24,6 @@ specific language governing permissions and limitations
 under the License.
 -->
 
-
 ## 概念介绍
 
 SQL Cache 是 Doris 提供的一种查询优化机制，可以显著提升查询性能。它通过缓存查询结果来减少重复计算，适用于数据更新频率较低的场景。
@@ -53,6 +52,18 @@ SQL Cache 非常适合 T+1 更新场景。数据在凌晨更新，第一次查
 
 目前，SQL Cache 支持 OlapTable 内部表和 Hive 外部表。
 
+## 使用限制
+
+### 非确定函数
+
+非确定函数是指其运算结果与输入参数之间无法形成固定关系的函数。
+
+以常见函数 `select now()` 为例，它返回当前的日期与时间。由于该函数在不同时间执行时会返回不同的结果，因此其返回值是动态变化。`now` 函数返回的是秒级别的时间，所以在同一秒内可以复用之前的 SQL Cache；但下一秒之后，就需要重新创建 SQL Cache。
+
+为了优化缓存利用率，建议将这种细粒度的时间转为粗粒度的时间，例如使用 `select * from tbl where dt=date(now())`。在这种情况下，同一天的查询都可以利用到 SQL Cache。
+
+相比之下，`random()` 函数则很难利用到 Cache，因为它每次运算的结果都是不同的。因此，应尽量避免在查询中使用这类非确定函数。
+
 ## 实现原理
 
 ### BE 实现原理
@@ -73,7 +84,7 @@ SQL Cache 非常适合 T+1 更新场景。数据在凌晨更新，第一次查
 
 此外，如果 SQL 优化阶段判断出查询结果仅包含 0 行或 1 行数据，FE 会选择将这些结果保存在其内存中，以便更快速地响应未来可能的相同查询。
 
-## 最佳实践
+## 快速上手
 
 ### 开启和关闭 SQL Cache
 
@@ -150,7 +161,7 @@ Execution  Summary:
 
 这两种方法均为用户提供了有效的手段来验证查询是否利用了 SQL Cache，从而帮助用户更好地评估查询性能并优化查询策略。
 
-### 统计缓存的指标
+## 指标监控
 
 **1. 在 FE 的 HTTP 接口** **`http://${FE_IP}:${FE_HTTP_PORT}/metrics`** **会返回两个相关指标：**
 
@@ -184,6 +195,8 @@ doris_be_query_cache_memory_total_byte 44101
 
 :::
 
+## 内存控制
+
 ### FE 内存控制
 
 在 FE 中，Cache 的元数据信息被设置为弱引用。当 FE 内存不足时，系统会自动释放最近最久未使用的 Cache 元数据。此外，用户还可以通过执行以下 SQL 语句，进一步限制 FE 内存的使用量。此配置实时生效，且每个 FE 都需要进行配置。若需持久化配置，则需将其保存在 fe.conf 文件中。
@@ -217,7 +230,7 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');
 ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 ```
 
-### 排查缓存失效原因
+## 排查缓存失效原因
 
 缓存失效原因一般包括以下几点：
 
@@ -236,15 +249,3 @@ ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
 7. 结果行数超过了 FE 配置的 `cache_result_max_row_count`，默认值为 3000 行。
 
 8. 结果大小超过了 FE 配置的 `cache_result_max_data_size`，默认值为 30MB。
-
-## 使用限制
-
-### 非确定函数
-
-非确定函数是指其运算结果与输入参数之间无法形成固定关系的函数。
-
-以常见函数 `select now()` 为例，它返回当前的日期与时间。由于该函数在不同时间执行时会返回不同的结果，因此其返回值是动态变化。`now` 函数返回的是秒级别的时间，所以在同一秒内可以复用之前的 SQL Cache；但下一秒之后，就需要重新创建 SQL Cache。
-
-为了优化缓存利用率，建议将这种细粒度的时间转为粗粒度的时间，例如使用 `select * from tbl where dt=date(now())`。在这种情况下，同一天的查询都可以利用到 SQL Cache。
-
-相比之下，`random()` 函数则很难利用到 Cache，因为它每次运算的结果都是不同的。因此，应尽量避免在查询中使用这类非确定函数。