This is an automated email from the ASF dual-hosted git repository.
luzhijing 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 e05fdf27c0a [doc](cache) deprecate/remove partition cache (#659)
e05fdf27c0a is described below
commit e05fdf27c0a40f61c6bd7d7095af304ce6016437
Author: 924060929 <924060...@qq.com>
AuthorDate: Mon May 20 14:47:53 2024 +0800
[doc](cache) deprecate/remove partition cache (#659)
---
docs/query/query-cache/partition-cache-manual.md | 169 --------------------
docs/query/query-cache/query-cache.md | 24 +--
docs/query/query-cache/sql-cache-manual.md | 9 ++
.../query/query-cache/partition-cache-manual.md | 170 ---------------------
.../current/query/query-cache/query-cache.md | 24 +--
.../current/query/query-cache/sql-cache-manual.md | 9 ++
.../query/query-cache/partition-cache-manual.md | 2 +-
.../query/query-cache/partition-cache-manual.md | 170 ---------------------
.../version-2.1/query/query-cache/query-cache.md | 24 +--
.../query/query-cache/sql-cache-manual.md | 9 ++
sidebars.json | 3 +-
.../query/query-cache/partition-cache-manual.md | 2 +-
.../query/query-cache/partition-cache-manual.md | 169 --------------------
.../version-2.1/query/query-cache/query-cache.md | 24 +--
.../query/query-cache/sql-cache-manual.md | 9 ++
versioned_sidebars/version-2.1-sidebars.json | 3 +-
16 files changed, 52 insertions(+), 768 deletions(-)
diff --git a/docs/query/query-cache/partition-cache-manual.md
b/docs/query/query-cache/partition-cache-manual.md
deleted file mode 100644
index be056be6402..00000000000
--- a/docs/query/query-cache/partition-cache-manual.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-{
- "title": "Partition Cache",
- "language": "en"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-
-Cache hits can occur when multiple SQLs use the same table partition.
-
-:::caution Caution
-**Partition Cache is an experimental feature and is not well maintained. Use
it with caution**
-:::
-
-## Demand scenarios & solutions
-
-See [Query Caches Overview](../query-cache/query-cache.md)
-
-## Design principles
-
-1. SQL can be split in parallel, Q = Q1 ∪ Q2 ... ∪ Qn, R= R1 ∪ R2 ... ∪ Rn, Q
is the query statement, R is the result set
-
-2. SQL only uses DATE, INT, and BIGINT types of partition field aggregation,
and only scans one partition. Therefore, it does not support partitioning by
day, but only supports partitioning by year and month.
-
-3. Cache the results of some dates in the query result set, and then reduce
the date range scanned in SQL. In essence, PartitionCache does not reduce the
number of partitions scanned, but also reduces the date range scanned, thereby
reducing the amount of scanned data.
-
-In addition some restrictions:
-
-- Only supports grouping by partition fields, not by other fields. Grouping by
other fields may cause the group data to be updated, which will cause the cache
to become invalid.
-
-- Only the first half, the second half and all hits of the result set are
supported in the cache. The result set is not supported to be divided into
several parts by cached data, and the dates of the result set must be
continuous. If there is no data in the result set on a certain day, then only
this Dates one day older will be cached.
-
-- If the predicate has columns outside the partition, you must add brackets to
the partition predicate `where k1 = 1 and (key >= "2023-10-18" and key <=
"2021-12-01")`
-
-- The number of days in the query must be greater than 1 and less than
cache_result_max_row_count, otherwise the partition cache cannot be used.
-
-- The predicate of the partition field can only be key >= a and key <= b or
key = a or key = b or key in (a,b,c).
-
-## Usage
-
-Make sure cache_enable_partition_mode=true in fe.conf (default is true)
-
-```text
-vim fe/conf/fe.conf
-cache_enable_partition_mode=true
-```
-
-Set variables in MySQL command line
-
-```sql
-MySQL [(none)]> set [global] enable_partition_cache=true;
-```
-
-If two caching strategies are enabled at the same time, you need to pay
attention to the following parameters:
-
-```text
-cache_last_version_interval_second=30
-```
-
-If the interval between the latest version of the partition and the present is
greater than cache_last_version_interval_second, the entire query result will
be cached first. If it is less than this interval, if it meets the conditions
of PartitionCache, the PartitionCache data will be pressed.
-
-For detailed parameter introduction and unfinished matters, see query-cache.md.
-
-## Unfinished business
-
-Split into read-only partitions and updateable partitions, read-only
partitions are cached, update partitions are not cached
-
-As above, query the number of daily users in the last 7 days. For example, if
partitioned by date, the data will only be written to the partition of the
current day. The data of other partitions other than the current day are fixed.
Under the same query SQL, query a certain area that is not updated. The
partition indicators are all fixed. As follows, the number of users in the
previous 7 days is queried on 2020-03-09. The data from 2020-03-03 to
2020-03-07 comes from the cache. The first [...]
-
-Therefore, to query N days of data, the data is updated for the most recent D
days. Similar queries with different date ranges every day only need to query D
partitions. The other parts come from the cache, which can effectively reduce
the cluster load and query time.
-
-Implementation principle example:
-
-```sql
-MySQL [(none)]> SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-03" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-+----------------+-----------------+
-| eventdate | count(`userid`) |
-+----------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 | //The first time comes from the partition, and the
subsequent ones come from the cache
-| 2020-03-09 | 25 | //From partition
-+----------------+-----------------+
-7 rows in set (0.02 sec)
-```
-
-In PartitionCache, the cached first-level Key is the 128-bit MD5 signature of
the SQL after removing the partition conditions. The following is the rewritten
SQL to be signed:
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent GROUP BY eventdate ORDER
BY eventdate;
-```
-
-The cached second-level key is the content of the partition field of the query
result set, such as the content of the eventdate column of the query result
above. The ancillary information of the second-level key is the version number
and version update time of the partition.
-
-The following demonstrates the process of executing the above SQL for the
first time on 2020-03-09:
-
-1. Get data from cache
-
-```text
-+----------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-+----------------+-----------------+
-```
-
-2. SQL and data to get data from BE
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-08" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-
-+----------------+-----------------+
-| 2020-03-08 | 40 |
-+----------------+-----------------+
-| 2020-03-09 | 25 |
-+----------------+-----------------+
-```
-
-3. The last data sent to the terminal
-
-```text
-+----------------+-----------------+
-| eventdate | count(`userid`) |
-+----------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 |
-| 2020-03-09 | 25 |
-+----------------+-----------------+
-```
-
-4. Data sent to cache
-
-```text
-+----------------+-----------------+
-| 2020-03-08 | 40 |
-+----------------+-----------------+
-```
-
-Partition cache is suitable for partitioning by date, some partitions are
updated in real time, and the query SQL is relatively fixed.
-
-The partition field can also be other fields, but it needs to be ensured that
only a small number of partitions are updated.
diff --git a/docs/query/query-cache/query-cache.md
b/docs/query/query-cache/query-cache.md
index 9325272ee96..908d3366de6 100644
--- a/docs/query/query-cache/query-cache.md
+++ b/docs/query/query-cache/query-cache.md
@@ -46,17 +46,15 @@ This partition cache strategy can solve the above problems,
giving priority to e
- Users do not need to worry about data consistency. Cache invalidation is
controlled through versioning. The cached data is consistent with the data
queried from BE.
- There are no additional components and costs, the cache results are stored
in BE's memory, and users can adjust the cache memory size as needed
-- Implemented two caching strategies, SQLCache and PartitionCache, the latter
has a finer cache granularity
+- Implemented one caching strategy, SQLCache
- Use consistent hashing to solve the problem of BE nodes going online and
offline. The caching algorithm in BE is an improved LRU
## scenes to be used
-Currently, it supports two methods: SQL Cache and Partition Cache, and
supports OlapTable internal table and Hive external table.
+Currently, it supports one method: SQL Cache, and supports OlapTable internal
table and Hive external table.
SQL Cache: Only SQL statements that are completely consistent will hit the
cache. For details, see: sql-cache-manual.md
-Partition Cache: Multiple SQLs can hit the cache using the same table
partition, so it has a higher hit rate than SQL Cache. For details, see:
partition-cache-manual.md
-
## Monitoring
FE monitoring items:
@@ -66,13 +64,8 @@ query_table //The number of tables in Query
query_olap_table //The number of Olap tables in Query
cache_mode_sql //Identify the number of Query whose cache mode is sql
cache_hit_sql //The number of Query hits in Cache with mode sql
-query_mode_partition //The number of queries that identify the cache mode as
Partition
-cache_hit_partition //The number of Query hits through Partition
-partition_all //All partitions scanned in Query
-partition_hit //Number of partitions hit through Cache
-Cache hit rate = (cache_hit_sql + cache_hit_partition) / query_olap_table
-Partition hit rate = partition_hit / partition_all
+Cache hit rate = cache_hit_sql / query_olap_table
```
BE monitoring items:
@@ -80,10 +73,8 @@ BE monitoring items:
```text
query_cache_memory_total_byte //Cache memory size
query_query_cache_sql_total_count //The number of SQL cached
-query_cache_partition_total_count //Number of Cache partitions
SQL average data size = cache_memory_total / cache_sql_total
-Partition average data size = cache_memory_total / cache_partition_total
```
Other monitoring: You can view the CPU and memory indicators of the BE node,
Query Percentile and other indicators in the Query statistics from Grafana, and
adjust the Cache parameters to achieve business goals.
@@ -128,12 +119,3 @@ vim be/conf/be.conf
query_cache_max_size_mb=256
query_cache_elasticity_size_mb=128
```
-
-5. cache_max_partition_count
-
-Parameters unique to Partition Cache. The maximum number of BE partitions
refers to the maximum number of partitions corresponding to each SQL. If it is
partitioned by date, it can cache data for more than 2 years. If you want to
keep the cache for a longer time, please set this parameter larger and modify
the parameters at the same time. cache_result_max_row_count and
cache_result_max_data_size.
-
-```text
-vim be/conf/be.conf
-cache_max_partition_count=1024
-```
diff --git a/docs/query/query-cache/sql-cache-manual.md
b/docs/query/query-cache/sql-cache-manual.md
index 97925c1a556..cba8dede9d6 100644
--- a/docs/query/query-cache/sql-cache-manual.md
+++ b/docs/query/query-cache/sql-cache-manual.md
@@ -59,6 +59,15 @@ MySQL [(none)]> set [global] enable_sql_cache=true;
Note: global is a global variable and does not refer to the current session
variable.
+In versions 2.1.3 and above, the Nereids optimizer saves cached key
information, such as non-deterministic functions and their evaluation values,
in the memory of FE. It can skip SQL parsing when the key information remains
unchanged, optimizing the query speed of SQL cache.
+
+The number of key information and elimination time can be controlled to reduce
memory consumption on FE through the frontend configuration items
sql_cache_manageNum and expires_sql_cache_in_fe_second.
+
+```sql
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num' = '100');
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second' =
'300');
+```
+
## Cache conditions
After the first query, if the following three conditions are met, the query
results will be cached.
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/partition-cache-manual.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/partition-cache-manual.md
deleted file mode 100644
index a131343ce0e..00000000000
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/partition-cache-manual.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-{
- "title": "Partition Cache",
- "language": "zh-CN"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Partition Cache
-
-多个 SQL 使用相同的表分区时可命中缓存。
-
-```
-**Partition Cache是个试验性功能，没有得到很好的维护，谨慎使用**
-```
-
-## 需求场景 & 解决方案
-
-见 query-cache.md。
-
-## 设计原理
-
-1. SQL可以并行拆分，Q = Q1 ∪ Q2 ... ∪ Qn，R= R1 ∪ R2 ... ∪ Rn，Q为查询语句，R为结果集
-
-2. SQL 只使用DATE、INT、BIGINT类型的分区字段聚合，且只扫描一个分区，因此不支持按天分区，只支持按年、月分区。
-
-3. 将查询结果集中部分日期的结果缓存，然后缩减 SQL 中扫描的日期范围，本质 PartitionCache
并没有减少扫描的分区数量，而且缩减扫描的日期范围，从而减少扫描数据量。
-
-此外一些限制：
-
-- 只支持按分区字段分组，不支持按其他字段分组，按其他字段分组，该分组数据都有可能被更新，会导致缓存都失效
-
--
只支持结果集的前半部分、后半部分以及全部命中缓存，不支持结果集被缓存数据分割成几个部分，且结果集的日期必须连续，如果某一天在结果集中没有数据，那只有这一天之前的日期会被缓存。
-
-- 如果 predicate 有分区之外的列，那么必须给分区 predicate 加上括号 `where k1 = 1 and (key >=
"2023-10-18" and key <= "2021-12-01")`
-
-- 查询的天数必须大于1，小于cache_result_max_row_count，否则无法使用partition cache。
-
-- 分区字段的 predicate 只能是 key >= a and key <= b 或者 key = a or key = b 或者 key
in(a,b,c)。
-
-## 使用方式
-
-确保 fe.conf 的 cache_enable_partition_mode=true (默认是true)
-
-```text
-vim fe/conf/fe.conf
-cache_enable_partition_mode=true
-```
-
-在MySQL命令行中设置变量
-
-```sql
-MySQL [(none)]> set [global] enable_partition_cache=true;
-```
-
-如果同时开启了两个缓存策略，下面的参数，需要注意一下:
-
-```text
-cache_last_version_interval_second=30
-```
-
-如果分区的最新版本的时间离现在的间隔，大于cache_last_version_interval_second，则会优先把整个查询结果缓存。如果小于这个间隔，如果符合PartitionCache的条件，则按PartitionCache数据。
-
-具体参数介绍和未尽事项见 query-cache.md。
-
-## 未尽事项
-
-拆分为只读分区和可更新分区，只读分区缓存，更新分区不缓存
-
-如查询最近7天的每天用户数，如按日期分区，数据只写当天分区，当天之外的其他分区的数据，都是固定不变的，在相同的查询SQL下，查询某个不更新分区的指标都是固定的。如下，在2020-03-09当天查询前7天的用户数，2020-03-03至2020-03-07的数据来自缓存，2020-03-08第一次查询来自分区，后续的查询来自缓存，2020-03-09因为当天在不停写入，所以来自分区。
-
-因此，查询N天的数据，数据更新最近的D天，每天只是日期范围不一样相似的查询，只需要查询D个分区即可，其他部分都来自缓存，可以有效降低集群负载，减少查询时间。
-
-实现原理示例:
-
-```sql
-MySQL [(none)]> SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-03" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-+------------+-----------------+
-| eventdate | count(`userid`) |
-+------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 | //第一次来自分区，后续来自缓存
-| 2020-03-09 | 25 | //来自分区
-+------------+-----------------+
-7 rows in set (0.02 sec)
-```
-
-在PartitionCache中，缓存第一级Key是去掉了分区条件后的SQL的128位MD5签名，下面是改写后的待签名的SQL：
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent GROUP BY eventdate ORDER
BY eventdate;
-```
-
-缓存的第二级Key是查询结果集的分区字段的内容，比如上面查询结果的eventdate列的内容，二级Key的附属信息是分区的版本号和版本更新时间。
-
-下面演示上面SQL在2020-03-09当天第一次执行的流程：
-
-1. 从缓存中获取数据
-
-```text
-+------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-+------------+-----------------+
-```
-
-2. 从BE中获取数据的SQL和数据
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-08" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-
-+------------+-----------------+
-| 2020-03-08 | 40 |
-+------------+-----------------+
-| 2020-03-09 | 25 |
-+------------+-----------------+
-```
-
-3. 最后发送给终端的数据
-
-```text
-+------------+-----------------+
-| eventdate | count(`userid`) |
-+------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 |
-| 2020-03-09 | 25 |
-+------------+-----------------+
-```
-
-4. 发送给缓存的数据
-
-```text
-+------------+-----------------+
-| 2020-03-08 | 40 |
-+------------+-----------------+
-```
-
-Partition缓存，适合按日期分区，部分分区实时更新，查询SQL较为固定。
-
-分区字段也可以是其他字段，但是需要保证只有少量分区更新。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/query-cache.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/query-cache.md
index 6698246ea88..2ec66c45431 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/query-cache.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/query-cache.md
@@ -54,18 +54,16 @@ under the License.
- 没有额外的组件和成本，缓存结果存储在 BE 的内存中，用户可以根据需要调整缓存内存大小
-- 实现了两种缓存策略，SQLCache 和 PartitionCache，后者缓存粒度更细
+- 实现了一种缓存策略，SQLCache
- 用一致性哈希解决 BE 节点上下线的问题，BE 中的缓存算法是改进的 LRU
## 使用场景
-当前支持 SQL Cache 和 Partition Cache 两种方式，支持 OlapTable 内表 和 Hive 外表。
+当前支持 SQL Cache，支持 OlapTable 内表 和 Hive 外表。
SQL Cache: 只有 SQL 语句完全一致才会命中缓存，详情见：sql-cache-manual.md
-Partition Cache: 多个 SQL 使用相同的表分区即可命中缓存，所以相比 SQL Cache
有更高的命中率，详情见：partition-cache-manual.md
-
## 监控
FE 的监控项：
@@ -75,13 +73,8 @@ query_table //Query 中有表的数量
query_olap_table //Query 中有 Olap 表的数量
cache_mode_sql //识别缓存模式为 sql 的 Query 数量
cache_hit_sql //模式为 sql 的 Query 命中 Cache 的数量
-query_mode_partition //识别缓存模式为 Partition 的 Query 数量
-cache_hit_partition //通过 Partition 命中的 Query 数量
-partition_all //Query 中扫描的所有分区
-partition_hit //通过 Cache 命中的分区数量
-Cache 命中率 = （cache_hit_sql + cache_hit_partition) / query_olap_table
-Partition 命中率 = partition_hit / partition_all
+Cache 命中率 = cache_hit_sql / query_olap_table
```
BE 的监控项：
@@ -89,10 +82,8 @@ BE 的监控项：
```text
query_cache_memory_total_byte //Cache 内存大小
query_query_cache_sql_total_count //Cache 的 SQL 的数量
-query_cache_partition_total_count //Cache 分区数量
SQL 平均数据大小 = cache_memory_total / cache_sql_total
-Partition 平均数据大小 = cache_memory_total / cache_partition_total
```
其他监控：可以从 Grafana 中查看 BE 节点的 CPU 和内存指标，Query 统计中的 Query Percentile 等指标，配合 Cache
参数的调整来达成业务目标。
@@ -137,12 +128,3 @@ vim be/conf/be.conf
query_cache_max_size_mb=256
query_cache_elasticity_size_mb=128
```
-
-5. cache_max_partition_count
-
-Partition Cache 独有的参数。BE 最大分区数量，指每个 SQL 对应的最大分区数，如果是按日期分区，能缓存 2
年多的数据，假如想保留更长时间的缓存，请把这个参数设置得更大，同时修改参数 cache_result_max_row_count 和
cache_result_max_data_size。
-
-```text
-vim be/conf/be.conf
-cache_max_partition_count=1024
-```
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/sql-cache-manual.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/sql-cache-manual.md
index 026bc76db47..f791e637a11 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/sql-cache-manual.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query/query-cache/sql-cache-manual.md
@@ -59,6 +59,15 @@ MySQL [(none)]> set [global] enable_sql_cache=true;
注：global 是全局变量，不加指当前会话变量
+在2.1.3及以上版本，Nereids优化器在fe的内存中保存缓存的关键信息，比如非确定函数及其评估值，在关键信息未发生变化时可以跳过sql解析，优化了sql
cache的查询速度。
+
+可以通过fe配置项sql_cache_manage_num和expire_sql_cache_in_fe_second来控制这些关键信息的个数以及淘汰时间来减少对fe的内存消耗。
+
+```sql
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num' = '100');
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second' =
'300');
+```
+
## 缓存条件
第一次查询后，如果满足下面三个条件，查询结果就会被缓存。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/query/query-cache/partition-cache-manual.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/query/query-cache/partition-cache-manual.md
index 0aba6f0c151..43384f911c0 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/query/query-cache/partition-cache-manual.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.0/query/query-cache/partition-cache-manual.md
@@ -29,7 +29,7 @@ under the License.
多个 SQL 使用相同的表分区时可命中缓存。
:::caution
-Partition Cache 是试验性功能，没有得到很好的维护，谨慎使用
+Partition Cache 是试验性功能，没有得到很好的维护，将在2.1版本中删除，请谨慎使用。
:::
## 需求场景 & 解决方案
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/partition-cache-manual.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/partition-cache-manual.md
deleted file mode 100644
index a131343ce0e..00000000000
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/partition-cache-manual.md
+++ /dev/null
@@ -1,170 +0,0 @@
----
-{
- "title": "Partition Cache",
- "language": "zh-CN"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-# Partition Cache
-
-多个 SQL 使用相同的表分区时可命中缓存。
-
-```
-**Partition Cache是个试验性功能，没有得到很好的维护，谨慎使用**
-```
-
-## 需求场景 & 解决方案
-
-见 query-cache.md。
-
-## 设计原理
-
-1. SQL可以并行拆分，Q = Q1 ∪ Q2 ... ∪ Qn，R= R1 ∪ R2 ... ∪ Rn，Q为查询语句，R为结果集
-
-2. SQL 只使用DATE、INT、BIGINT类型的分区字段聚合，且只扫描一个分区，因此不支持按天分区，只支持按年、月分区。
-
-3. 将查询结果集中部分日期的结果缓存，然后缩减 SQL 中扫描的日期范围，本质 PartitionCache
并没有减少扫描的分区数量，而且缩减扫描的日期范围，从而减少扫描数据量。
-
-此外一些限制：
-
-- 只支持按分区字段分组，不支持按其他字段分组，按其他字段分组，该分组数据都有可能被更新，会导致缓存都失效
-
--
只支持结果集的前半部分、后半部分以及全部命中缓存，不支持结果集被缓存数据分割成几个部分，且结果集的日期必须连续，如果某一天在结果集中没有数据，那只有这一天之前的日期会被缓存。
-
-- 如果 predicate 有分区之外的列，那么必须给分区 predicate 加上括号 `where k1 = 1 and (key >=
"2023-10-18" and key <= "2021-12-01")`
-
-- 查询的天数必须大于1，小于cache_result_max_row_count，否则无法使用partition cache。
-
-- 分区字段的 predicate 只能是 key >= a and key <= b 或者 key = a or key = b 或者 key
in(a,b,c)。
-
-## 使用方式
-
-确保 fe.conf 的 cache_enable_partition_mode=true (默认是true)
-
-```text
-vim fe/conf/fe.conf
-cache_enable_partition_mode=true
-```
-
-在MySQL命令行中设置变量
-
-```sql
-MySQL [(none)]> set [global] enable_partition_cache=true;
-```
-
-如果同时开启了两个缓存策略，下面的参数，需要注意一下:
-
-```text
-cache_last_version_interval_second=30
-```
-
-如果分区的最新版本的时间离现在的间隔，大于cache_last_version_interval_second，则会优先把整个查询结果缓存。如果小于这个间隔，如果符合PartitionCache的条件，则按PartitionCache数据。
-
-具体参数介绍和未尽事项见 query-cache.md。
-
-## 未尽事项
-
-拆分为只读分区和可更新分区，只读分区缓存，更新分区不缓存
-
-如查询最近7天的每天用户数，如按日期分区，数据只写当天分区，当天之外的其他分区的数据，都是固定不变的，在相同的查询SQL下，查询某个不更新分区的指标都是固定的。如下，在2020-03-09当天查询前7天的用户数，2020-03-03至2020-03-07的数据来自缓存，2020-03-08第一次查询来自分区，后续的查询来自缓存，2020-03-09因为当天在不停写入，所以来自分区。
-
-因此，查询N天的数据，数据更新最近的D天，每天只是日期范围不一样相似的查询，只需要查询D个分区即可，其他部分都来自缓存，可以有效降低集群负载，减少查询时间。
-
-实现原理示例:
-
-```sql
-MySQL [(none)]> SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-03" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-+------------+-----------------+
-| eventdate | count(`userid`) |
-+------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 | //第一次来自分区，后续来自缓存
-| 2020-03-09 | 25 | //来自分区
-+------------+-----------------+
-7 rows in set (0.02 sec)
-```
-
-在PartitionCache中，缓存第一级Key是去掉了分区条件后的SQL的128位MD5签名，下面是改写后的待签名的SQL：
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent GROUP BY eventdate ORDER
BY eventdate;
-```
-
-缓存的第二级Key是查询结果集的分区字段的内容，比如上面查询结果的eventdate列的内容，二级Key的附属信息是分区的版本号和版本更新时间。
-
-下面演示上面SQL在2020-03-09当天第一次执行的流程：
-
-1. 从缓存中获取数据
-
-```text
-+------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-+------------+-----------------+
-```
-
-2. 从BE中获取数据的SQL和数据
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-08" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-
-+------------+-----------------+
-| 2020-03-08 | 40 |
-+------------+-----------------+
-| 2020-03-09 | 25 |
-+------------+-----------------+
-```
-
-3. 最后发送给终端的数据
-
-```text
-+------------+-----------------+
-| eventdate | count(`userid`) |
-+------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 |
-| 2020-03-09 | 25 |
-+------------+-----------------+
-```
-
-4. 发送给缓存的数据
-
-```text
-+------------+-----------------+
-| 2020-03-08 | 40 |
-+------------+-----------------+
-```
-
-Partition缓存，适合按日期分区，部分分区实时更新，查询SQL较为固定。
-
-分区字段也可以是其他字段，但是需要保证只有少量分区更新。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/query-cache.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/query-cache.md
index 6698246ea88..2ec66c45431 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/query-cache.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/query-cache.md
@@ -54,18 +54,16 @@ under the License.
- 没有额外的组件和成本，缓存结果存储在 BE 的内存中，用户可以根据需要调整缓存内存大小
-- 实现了两种缓存策略，SQLCache 和 PartitionCache，后者缓存粒度更细
+- 实现了一种缓存策略，SQLCache
- 用一致性哈希解决 BE 节点上下线的问题，BE 中的缓存算法是改进的 LRU
## 使用场景
-当前支持 SQL Cache 和 Partition Cache 两种方式，支持 OlapTable 内表 和 Hive 外表。
+当前支持 SQL Cache，支持 OlapTable 内表 和 Hive 外表。
SQL Cache: 只有 SQL 语句完全一致才会命中缓存，详情见：sql-cache-manual.md
-Partition Cache: 多个 SQL 使用相同的表分区即可命中缓存，所以相比 SQL Cache
有更高的命中率，详情见：partition-cache-manual.md
-
## 监控
FE 的监控项：
@@ -75,13 +73,8 @@ query_table //Query 中有表的数量
query_olap_table //Query 中有 Olap 表的数量
cache_mode_sql //识别缓存模式为 sql 的 Query 数量
cache_hit_sql //模式为 sql 的 Query 命中 Cache 的数量
-query_mode_partition //识别缓存模式为 Partition 的 Query 数量
-cache_hit_partition //通过 Partition 命中的 Query 数量
-partition_all //Query 中扫描的所有分区
-partition_hit //通过 Cache 命中的分区数量
-Cache 命中率 = （cache_hit_sql + cache_hit_partition) / query_olap_table
-Partition 命中率 = partition_hit / partition_all
+Cache 命中率 = cache_hit_sql / query_olap_table
```
BE 的监控项：
@@ -89,10 +82,8 @@ BE 的监控项：
```text
query_cache_memory_total_byte //Cache 内存大小
query_query_cache_sql_total_count //Cache 的 SQL 的数量
-query_cache_partition_total_count //Cache 分区数量
SQL 平均数据大小 = cache_memory_total / cache_sql_total
-Partition 平均数据大小 = cache_memory_total / cache_partition_total
```
其他监控：可以从 Grafana 中查看 BE 节点的 CPU 和内存指标，Query 统计中的 Query Percentile 等指标，配合 Cache
参数的调整来达成业务目标。
@@ -137,12 +128,3 @@ vim be/conf/be.conf
query_cache_max_size_mb=256
query_cache_elasticity_size_mb=128
```
-
-5. cache_max_partition_count
-
-Partition Cache 独有的参数。BE 最大分区数量，指每个 SQL 对应的最大分区数，如果是按日期分区，能缓存 2
年多的数据，假如想保留更长时间的缓存，请把这个参数设置得更大，同时修改参数 cache_result_max_row_count 和
cache_result_max_data_size。
-
-```text
-vim be/conf/be.conf
-cache_max_partition_count=1024
-```
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/sql-cache-manual.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/sql-cache-manual.md
index 026bc76db47..2c196a10015 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/sql-cache-manual.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/query/query-cache/sql-cache-manual.md
@@ -59,6 +59,15 @@ MySQL [(none)]> set [global] enable_sql_cache=true;
注：global 是全局变量，不加指当前会话变量
+在2.1.3及以上版本，Nereids优化器在fe的内存中保存缓存的关键信息，比如非确定函数及其评估值，在关键信息未发生变化时可以跳过sql解析，优化了sql
cache的查询速度。
+
+可以通过frontend配置项sql_cache_manage_num和expire_sql_cache_in_fe_second来控制这些关键信息的个数以及淘汰时间来减少对fe的内存消耗。
+
+```sql
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num' = '100');
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second' =
'300');
+```
+
## 缓存条件
第一次查询后，如果满足下面三个条件，查询结果就会被缓存。
diff --git a/sidebars.json b/sidebars.json
index dd727def50e..825c1b48f1c 100644
--- a/sidebars.json
+++ b/sidebars.json
@@ -198,8 +198,7 @@
"label": "Caches",
"items": [
"query/query-cache/query-cache",
- "query/query-cache/sql-cache-manual",
- "query/query-cache/partition-cache-manual"
+ "query/query-cache/sql-cache-manual"
]
},
{
diff --git
a/versioned_docs/version-2.0/query/query-cache/partition-cache-manual.md
b/versioned_docs/version-2.0/query/query-cache/partition-cache-manual.md
index d10b6e040d6..6bfd3d37ad2 100644
--- a/versioned_docs/version-2.0/query/query-cache/partition-cache-manual.md
+++ b/versioned_docs/version-2.0/query/query-cache/partition-cache-manual.md
@@ -29,7 +29,7 @@ under the License.
Cache hits can occur when multiple SQLs use the same table partition.
:::caution Caution
-**Partition Cache is an experimental feature and is not well maintained. Use
it with caution**
+**Partition Cache is an experimental feature and is not well maintained, this
feature will be removed in version 2.1. Please use it with caution**
:::
## Demand scenarios & solutions
diff --git
a/versioned_docs/version-2.1/query/query-cache/partition-cache-manual.md
b/versioned_docs/version-2.1/query/query-cache/partition-cache-manual.md
deleted file mode 100644
index be056be6402..00000000000
--- a/versioned_docs/version-2.1/query/query-cache/partition-cache-manual.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-{
- "title": "Partition Cache",
- "language": "en"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-
-Cache hits can occur when multiple SQLs use the same table partition.
-
-:::caution Caution
-**Partition Cache is an experimental feature and is not well maintained. Use
it with caution**
-:::
-
-## Demand scenarios & solutions
-
-See [Query Caches Overview](../query-cache/query-cache.md)
-
-## Design principles
-
-1. SQL can be split in parallel, Q = Q1 ∪ Q2 ... ∪ Qn, R= R1 ∪ R2 ... ∪ Rn, Q
is the query statement, R is the result set
-
-2. SQL only uses DATE, INT, and BIGINT types of partition field aggregation,
and only scans one partition. Therefore, it does not support partitioning by
day, but only supports partitioning by year and month.
-
-3. Cache the results of some dates in the query result set, and then reduce
the date range scanned in SQL. In essence, PartitionCache does not reduce the
number of partitions scanned, but also reduces the date range scanned, thereby
reducing the amount of scanned data.
-
-In addition some restrictions:
-
-- Only supports grouping by partition fields, not by other fields. Grouping by
other fields may cause the group data to be updated, which will cause the cache
to become invalid.
-
-- Only the first half, the second half and all hits of the result set are
supported in the cache. The result set is not supported to be divided into
several parts by cached data, and the dates of the result set must be
continuous. If there is no data in the result set on a certain day, then only
this Dates one day older will be cached.
-
-- If the predicate has columns outside the partition, you must add brackets to
the partition predicate `where k1 = 1 and (key >= "2023-10-18" and key <=
"2021-12-01")`
-
-- The number of days in the query must be greater than 1 and less than
cache_result_max_row_count, otherwise the partition cache cannot be used.
-
-- The predicate of the partition field can only be key >= a and key <= b or
key = a or key = b or key in (a,b,c).
-
-## Usage
-
-Make sure cache_enable_partition_mode=true in fe.conf (default is true)
-
-```text
-vim fe/conf/fe.conf
-cache_enable_partition_mode=true
-```
-
-Set variables in MySQL command line
-
-```sql
-MySQL [(none)]> set [global] enable_partition_cache=true;
-```
-
-If two caching strategies are enabled at the same time, you need to pay
attention to the following parameters:
-
-```text
-cache_last_version_interval_second=30
-```
-
-If the interval between the latest version of the partition and the present is
greater than cache_last_version_interval_second, the entire query result will
be cached first. If it is less than this interval, if it meets the conditions
of PartitionCache, the PartitionCache data will be pressed.
-
-For detailed parameter introduction and unfinished matters, see query-cache.md.
-
-## Unfinished business
-
-Split into read-only partitions and updateable partitions, read-only
partitions are cached, update partitions are not cached
-
-As above, query the number of daily users in the last 7 days. For example, if
partitioned by date, the data will only be written to the partition of the
current day. The data of other partitions other than the current day are fixed.
Under the same query SQL, query a certain area that is not updated. The
partition indicators are all fixed. As follows, the number of users in the
previous 7 days is queried on 2020-03-09. The data from 2020-03-03 to
2020-03-07 comes from the cache. The first [...]
-
-Therefore, to query N days of data, the data is updated for the most recent D
days. Similar queries with different date ranges every day only need to query D
partitions. The other parts come from the cache, which can effectively reduce
the cluster load and query time.
-
-Implementation principle example:
-
-```sql
-MySQL [(none)]> SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-03" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-+----------------+-----------------+
-| eventdate | count(`userid`) |
-+----------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 | //The first time comes from the partition, and the
subsequent ones come from the cache
-| 2020-03-09 | 25 | //From partition
-+----------------+-----------------+
-7 rows in set (0.02 sec)
-```
-
-In PartitionCache, the cached first-level Key is the 128-bit MD5 signature of
the SQL after removing the partition conditions. The following is the rewritten
SQL to be signed:
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent GROUP BY eventdate ORDER
BY eventdate;
-```
-
-The cached second-level key is the content of the partition field of the query
result set, such as the content of the eventdate column of the query result
above. The ancillary information of the second-level key is the version number
and version update time of the partition.
-
-The following demonstrates the process of executing the above SQL for the
first time on 2020-03-09:
-
-1. Get data from cache
-
-```text
-+----------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-+----------------+-----------------+
-```
-
-2. SQL and data to get data from BE
-
-```sql
-SELECT eventdate,count(userid) FROM testdb.appevent WHERE
eventdate>="2020-03-08" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY
eventdate;
-
-+----------------+-----------------+
-| 2020-03-08 | 40 |
-+----------------+-----------------+
-| 2020-03-09 | 25 |
-+----------------+-----------------+
-```
-
-3. The last data sent to the terminal
-
-```text
-+----------------+-----------------+
-| eventdate | count(`userid`) |
-+----------------+-----------------+
-| 2020-03-03 | 15 |
-| 2020-03-04 | 20 |
-| 2020-03-05 | 25 |
-| 2020-03-06 | 30 |
-| 2020-03-07 | 35 |
-| 2020-03-08 | 40 |
-| 2020-03-09 | 25 |
-+----------------+-----------------+
-```
-
-4. Data sent to cache
-
-```text
-+----------------+-----------------+
-| 2020-03-08 | 40 |
-+----------------+-----------------+
-```
-
-Partition cache is suitable for partitioning by date, some partitions are
updated in real time, and the query SQL is relatively fixed.
-
-The partition field can also be other fields, but it needs to be ensured that
only a small number of partitions are updated.
diff --git a/versioned_docs/version-2.1/query/query-cache/query-cache.md
b/versioned_docs/version-2.1/query/query-cache/query-cache.md
index 9325272ee96..908d3366de6 100644
--- a/versioned_docs/version-2.1/query/query-cache/query-cache.md
+++ b/versioned_docs/version-2.1/query/query-cache/query-cache.md
@@ -46,17 +46,15 @@ This partition cache strategy can solve the above problems,
giving priority to e
- Users do not need to worry about data consistency. Cache invalidation is
controlled through versioning. The cached data is consistent with the data
queried from BE.
- There are no additional components and costs, the cache results are stored
in BE's memory, and users can adjust the cache memory size as needed
-- Implemented two caching strategies, SQLCache and PartitionCache, the latter
has a finer cache granularity
+- Implemented one caching strategy, SQLCache
- Use consistent hashing to solve the problem of BE nodes going online and
offline. The caching algorithm in BE is an improved LRU
## scenes to be used
-Currently, it supports two methods: SQL Cache and Partition Cache, and
supports OlapTable internal table and Hive external table.
+Currently, it supports one method: SQL Cache, and supports OlapTable internal
table and Hive external table.
SQL Cache: Only SQL statements that are completely consistent will hit the
cache. For details, see: sql-cache-manual.md
-Partition Cache: Multiple SQLs can hit the cache using the same table
partition, so it has a higher hit rate than SQL Cache. For details, see:
partition-cache-manual.md
-
## Monitoring
FE monitoring items:
@@ -66,13 +64,8 @@ query_table //The number of tables in Query
query_olap_table //The number of Olap tables in Query
cache_mode_sql //Identify the number of Query whose cache mode is sql
cache_hit_sql //The number of Query hits in Cache with mode sql
-query_mode_partition //The number of queries that identify the cache mode as
Partition
-cache_hit_partition //The number of Query hits through Partition
-partition_all //All partitions scanned in Query
-partition_hit //Number of partitions hit through Cache
-Cache hit rate = (cache_hit_sql + cache_hit_partition) / query_olap_table
-Partition hit rate = partition_hit / partition_all
+Cache hit rate = cache_hit_sql / query_olap_table
```
BE monitoring items:
@@ -80,10 +73,8 @@ BE monitoring items:
```text
query_cache_memory_total_byte //Cache memory size
query_query_cache_sql_total_count //The number of SQL cached
-query_cache_partition_total_count //Number of Cache partitions
SQL average data size = cache_memory_total / cache_sql_total
-Partition average data size = cache_memory_total / cache_partition_total
```
Other monitoring: You can view the CPU and memory indicators of the BE node,
Query Percentile and other indicators in the Query statistics from Grafana, and
adjust the Cache parameters to achieve business goals.
@@ -128,12 +119,3 @@ vim be/conf/be.conf
query_cache_max_size_mb=256
query_cache_elasticity_size_mb=128
```
-
-5. cache_max_partition_count
-
-Parameters unique to Partition Cache. The maximum number of BE partitions
refers to the maximum number of partitions corresponding to each SQL. If it is
partitioned by date, it can cache data for more than 2 years. If you want to
keep the cache for a longer time, please set this parameter larger and modify
the parameters at the same time. cache_result_max_row_count and
cache_result_max_data_size.
-
-```text
-vim be/conf/be.conf
-cache_max_partition_count=1024
-```
diff --git a/versioned_docs/version-2.1/query/query-cache/sql-cache-manual.md
b/versioned_docs/version-2.1/query/query-cache/sql-cache-manual.md
index 68fd45f216b..c453c8c42a4 100644
--- a/versioned_docs/version-2.1/query/query-cache/sql-cache-manual.md
+++ b/versioned_docs/version-2.1/query/query-cache/sql-cache-manual.md
@@ -59,6 +59,15 @@ MySQL [(none)]> set [global] enable_sql_cache=true;
Note: global is a global variable and does not refer to the current session
variable.
+In versions 2.1.3 and above, the Nereids optimizer saves cached key
information, such as non-deterministic functions and their evaluation values,
in the memory of FE. It can skip SQL parsing when the key information remains
unchanged, optimizing the query speed of SQL cache.
+
+The number of key information and elimination time can be controlled to reduce
memory consumption on FE through the frontend configuration items
sql_cache_manageNum and expires_sql_cache_in_fe_second.
+
+```sql
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num' = '100');
+MySQL [(none)]> ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second' =
'300');
+```
+
## Cache conditions
After the first query, if the following three conditions are met, the query
results will be cached.
diff --git a/versioned_sidebars/version-2.1-sidebars.json
b/versioned_sidebars/version-2.1-sidebars.json
index ab027c09c39..fe6ba86194f 100644
--- a/versioned_sidebars/version-2.1-sidebars.json
+++ b/versioned_sidebars/version-2.1-sidebars.json
@@ -197,8 +197,7 @@
"label": "Caches",
"items": [
"query/query-cache/query-cache",
- "query/query-cache/sql-cache-manual",
- "query/query-cache/partition-cache-manual"
+ "query/query-cache/sql-cache-manual"
]
},
{
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
