update tidb config and sys vars for v6.1 (pingcap#9631)

benchmark/benchmark-tidb-using-sysbench.md

@@ -11,13 +11,12 @@ aliases: ['/docs-cn/dev/benchmark/benchmark-tidb-using-sysbench/','/docs-cn/dev/
 
 ### TiDB 配置
 
-升高日志级别，可以减少打印日志数量，对 TiDB 的性能有积极影响。开启 TiDB 配置中的 `prepared plan cache`，以减少优化执行计划的开销。具体在 TiUP 配置文件中加入：
+升高日志级别，可以减少打印日志数量，对 TiDB 的性能有积极影响。具体在 TiUP 配置文件中加入：
 
 ```yaml
 server_configs:
   tidb:
     log.level: "error"
-    prepared-plan-cache.enabled: true
 ```
 
 ### TiKV 配置

best-practices/three-nodes-hybrid-deployment.md

@@ -45,7 +45,6 @@ tikv:
     rocksdb.rate-bytes-per-sec: “200M”
 
   tidb:
-    performance.committer-concurrency: 4
     performance.max-procs: 8
 ```
 

command-line-flags-for-tidb-configuration.md

@@ -193,8 +193,3 @@ aliases: ['/docs-cn/dev/command-line-flags-for-tidb-configuration/','/docs-cn/de
 
 + 修复模式下需要修复的表名
 + 默认：""
-
-## `--require-secure-transport`
-
-+ 是否要求客户端使用安全传输模式
-+ 默认：false

configure-memory-usage.md

@@ -5,52 +5,37 @@ aliases: ['/docs-cn/dev/configure-memory-usage/','/docs-cn/dev/how-to/configure/
 
 # TiDB 内存控制文档
 
-目前 TiDB 已经能够做到追踪单条 SQL 查询过程中的内存使用情况，当内存使用超过一定阈值后也能采取一些操作来预防 OOM 或者排查 OOM 原因。在 TiDB 的配置文件中，我们可以使用如下配置来控制内存使用超阈值时 TiDB 的行为：
+目前 TiDB 已经能够做到追踪单条 SQL 查询过程中的内存使用情况，当内存使用超过一定阈值后也能采取一些操作来预防 OOM 或者排查 OOM 原因。你可以使用系统变量 [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-从-v610-版本开始引入) 来控制查询超过内存限制后所采取的操作：
 
-{{< copyable "" >}}
-
-```
-# Valid options: ["log", "cancel"]
-oom-action = "cancel"
-```
-
-- 如果上面的配置项使用的是 "log"，那么当一条 SQL 的内存使用超过一定阈值（由 session 变量 `tidb_mem_quota_query` 来控制）后，TiDB 会在 log 文件中打印一条 LOG，然后这条 SQL 继续执行，之后如果发生了 OOM 可以在 LOG 中找到对应的 SQL。
-- 如果上面的配置项使用的是 "cancel"，那么当一条 SQL 的内存使用超过一定阈值后，TiDB 会立即中断这条 SQL 的执行并给客户端返回一个 error，error 信息中会详细写明这条 SQL 执行过程中各个占用内存比较多的物理执行算子的内存使用情况。
+- 如果变量值为 `LOG`，那么当一条 SQL 的内存使用超过一定阈值（由 session 变量 `tidb_mem_quota_query` 控制）后，这条 SQL 会继续执行，但 TiDB 会在 log 文件中打印一条 LOG。
+- 如果变量值为 `CANCEL`，那么当一条 SQL 的内存使用超过一定阈值后，TiDB 会立即中断这条 SQL 的执行，并给客户端返回一个错误，错误信息中会详细写明在这条 SQL 执行过程中占用内存的各个物理执行算子的内存使用情况。
 
 ## 如何配置一条 SQL 执行过程中的内存使用阈值
 
-可以在配置文件中设置每个 Query 默认的 Memory Quota，例如将其设置为 32GB：
-
-{{< copyable "" >}}
-
-```
-mem-quota-query = 34359738368
-```
-
-此外还可通过 session 变量 `tidb_mem_quota_query` 来控制一条 Query 中的内存使用。几个使用例子：
+使用系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 来配置一条 SQL 执行过程中的内存使用阈值，单位为字节。例如：
 
 配置整条 SQL 的内存使用阈值为 8GB：
 
 {{< copyable "sql" >}}
 
 ```sql
-set @@tidb_mem_quota_query = 8 << 30;
+SET tidb_mem_quota_query = 8 << 30;
 ```
 
 配置整条 SQL 的内存使用阈值为 8MB：
 
 {{< copyable "sql" >}}
 
 ```sql
-set @@tidb_mem_quota_query = 8 << 20;
+SET tidb_mem_quota_query = 8 << 20;
 ```
 
 配置整条 SQL 的内存使用阈值为 8KB：
 
 {{< copyable "sql" >}}
 
 ```sql
-set @@tidb_mem_quota_query = 8 << 10;
+SET tidb_mem_quota_query = 8 << 10;
 ```
 
 ## 如何配置 tidb-server 实例使用内存的阈值
@@ -86,7 +71,7 @@ server-memory-quota = 34359738368
     {{< copyable "" >}}
 
     ```toml
-    mem-quota-query = 34359738368  // 将单条 SQL 内存限制调高，以便于构造占用内存较大的 SQL
+    mem-quota-query = 34359738368
     [performance]
     memory-usage-alarm-ratio = 0.8
     ```
@@ -124,7 +109,7 @@ server-memory-quota = 34359738368
 
 TiDB 支持对执行算子的数据落盘功能。当 SQL 的内存使用超过 Memory Quota 时，tidb-server 可以通过落盘执行算子的中间数据，缓解内存压力。支持落盘的算子有：Sort、MergeJoin、HashJoin、HashAgg。
 
-- 落盘行为由参数 [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query)、[`oom-use-tmp-storage`](/tidb-configuration-file.md#oom-use-tmp-storage)、[`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path)、[`tmp-storage-quota`](/tidb-configuration-file.md#tmp-storage-quota) 共同控制。
+- 落盘行为由参数 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)、[`oom-use-tmp-storage`](/tidb-configuration-file.md#oom-use-tmp-storage)、[`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path)、[`tmp-storage-quota`](/tidb-configuration-file.md#tmp-storage-quota) 共同控制。
 - 当落盘被触发时，TiDB 会在日志中打印一条包含关键字 `memory exceeds quota, spill to disk now` 或 `memory exceeds quota, set aggregate mode to spill-mode` 的日志。
 - Sort、MergeJoin、HashJoin 落盘是从 v4.0.0 版本开始引入的，HashAgg 落盘是从 v5.2.0 版本开始引入的。
 - 当包含 Sort、MergeJoin 或 HashJoin 的 SQL 语句引起内存 OOM 时，TiDB 默认会触发落盘。当包含 HashAgg 算子的 SQL 语句引起内存 OOM 时，TiDB 默认不触发落盘，请设置系统变量 `tidb_executor_concurrency = 1` 来触发 HashAgg 落盘功能。
@@ -140,7 +125,7 @@ TiDB 支持对执行算子的数据落盘功能。当 SQL 的内存使用超过
     {{< copyable "sql" >}}
 
     ```sql
-    set tidb_mem_quota_query = 1 << 30;
+    SET tidb_mem_quota_query = 1 << 30;
     ```
 
 2. 创建单表 `CREATE TABLE t(a int);` 并插入 256 行不同的数据。
@@ -164,7 +149,7 @@ TiDB 支持对执行算子的数据落盘功能。当 SQL 的内存使用超过
     {{< copyable "sql" >}}
 
     ```sql
-    set tidb_executor_concurrency = 1;
+    SET tidb_executor_concurrency = 1;
     ```
 
 5. 执行相同的 SQL 语句，不再返回错误，可以执行成功。从详细的执行计划可以看出，HashAgg 使用了 600MB 的硬盘空间。

dynamic-config.md

@@ -316,7 +316,6 @@ select @@tidb_slow_log_threshold;
 
 | 配置项 | 对应变量 | 简介 |
 | --- | --- | --- |
-| mem-quota-query | tidb_mem_quota_query | 查询语句的内存使用限制 |
 | log.enable-slow-log | tidb_enable_slow_log | 慢日志的开关 |
 | log.slow-threshold | tidb_slow_log_threshold | 慢日志阈值 |
 | log.expensive-threshold | tidb_expensive_query_time_threshold | expensive 查询阈值 |

enable-disk-spill-encrypt.md

@@ -5,7 +5,7 @@ summary: 了解如何为 TiDB 落盘文件开启加密。
 
 # 为 TiDB 落盘文件开启加密
 
-当配置项 `oom-use-tmp-storage` 为 `true` 时，如果单条 SQL 语句的内存使用超出 `mem-quota-query` 的限制，某些算子可以将执行时的中间结果作为临时文件落盘保存，直到查询执行完成之后将它们删除。
+当配置项 `oom-use-tmp-storage` 为 `true` 时，如果单条 SQL 语句的内存使用超出系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 的限制，某些算子可以将执行时的中间结果作为临时文件落盘保存，直到查询执行完成之后将它们删除。
 
 用户可以开启落盘文件加密功能，防止攻击者通过读取临时文件来访问数据。
 

enable-tls-between-clients-and-servers.md

@@ -19,7 +19,7 @@ TiDB 服务端支持启用基于 TLS（传输层安全）协议的加密连接
 
 另外，与 MySQL 相同，TiDB 也支持在同一 TCP 端口上开启 TLS 连接或非 TLS 连接。对于开启了 TLS 连接支持的 TiDB 服务端，客户端既可以选择通过加密连接安全地连接到该 TiDB 服务端，也可以选择使用普通的非加密连接。如需使用加密连接，你可以通过以下方式进行配置：
 
-+ 通过在启动参数中配置 `--require-secure-transport` 要求所有用户必须使用加密连接来连接到 TiDB。
++ 通过配置系统变量 `require_secure_transport` 要求所有用户必须使用加密连接来连接到 TiDB。
 + 通过在创建用户 (`create user`)，或修改已有用户 (`alter user`) 时指定 `REQUIRE SSL` 要求指定用户必须使用加密连接来连接 TiDB。以创建用户为例：
 
     ```sql

error-codes.md

@@ -19,7 +19,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样
 
 * Error Number: 8001
 
-    请求使用的内存超过 TiDB 内存使用的阈值限制。出现这种错误，可以通过调整 `mem-quota-query` 来增大单个 SQL 使用的内存上限。
+    请求使用的内存超过 TiDB 内存使用的阈值限制。出现这种错误，可以通过调整系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 来增大单个 SQL 使用的内存上限。
 
 * Error Number: 8002
 

faq/sql-faq.md

@@ -166,6 +166,8 @@ TiDB 支持改变 [per-session](/system-variables.md#tidb_force_priority)、[全
 
 当表的（修改数/当前总行数）大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 `analyze` 语句。`tidb_auto_analyze_ratio` 的默认值为 0.5，即默认开启此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio`（默认值为 0.8），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。
 
+你可以用系统变量 [`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-从-v610-版本开始引入) 关闭 auto analyze。
+
 ## 可以使用 Hints 控制优化器行为吗？
 
 在 TiDB 中，你可以用多种方法控制查询优化器的默认行为，包括使用 [Optimizer Hints](/optimizer-hints.md) 和 [SQL 执行计划管理 (SPM)](/sql-plan-management.md)。基本用法同 MySQL 中的一致，还包含若干 TiDB 特有的用法，示例如下：`select column_name from table_name use index（index_name）where where_condition;`

grafana-tidb-dashboard.md

@@ -57,12 +57,12 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon
     - Transaction Statement Num：事务中的 SQL 语句数量
     - Transaction Retry Num：事务重试次数
     - Session Retry Error OPS：事务重试时每秒遇到的错误数量，分为重试失败和超过最大重试次数两种类型
-    - Commit Token Wait Duration：事务提交时的流控队列等待时间。当出现较长等待时，代表提交事务过大，正在限流。如果系统还有资源可以使用，可以通过增大 TiDB 配置文件中 `committer-concurrency` 值来加速提交
+    - Commit Token Wait Duration：事务提交时的流控队列等待时间。当出现较长等待时，代表提交事务过大，正在限流。如果系统还有资源可以使用，可以通过增大系统变量 `tidb_committer_concurrency` 的值来加速提交
     - KV Transaction OPS：每个 TiDB 内部每秒执行的事务数量
         - 一个用户的事务，在 TiDB 内部可能会触发多次事务执行，其中包含，内部元数据的读取，用户事务原子性地多次重试执行等
         - TiDB 内部的定时任务也会通过事务来操作数据库，这部分也包含在这个面板里
     - KV Transaction Duration：每个 TiDB 内部执行事务的耗时
-    - Transaction Regions Num：事务操作的 Region 数量  
+    - Transaction Regions Num：事务操作的 Region 数量
     - Transaction Write KV Num Rate and Sum：事务写入 KV 的速率总和
     - Transaction Write KV Num：事务操作的 KV 数量
     - Statement Lock Keys：单个语句的加锁个数
@@ -71,7 +71,7 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon
     - Transaction Write Size Bytes：事务写入的数据大小
     - Acquire Pessimistic Locks Duration：加锁所消耗的时间
     - TTL Lifetime Reach Counter：事务的 TTL 寿命上限。TTL 上限默认值 1 小时，它的含义是从悲观事务第一次加锁，或者乐观事务的第一个 prewrite 开始，超过了 1 小时。可以通过修改 TiDB 配置文件中 `max-txn-ttl` 来改变 TTL 寿命上限
-    - Load Safepoint OPS：加载 Safepoint 的次数。Safepoint 作用是在事务读数据时，保证不读到 Safepoint 之前的数据，保证数据安全。因为，Safepoint 之前的数据有可能被 GC 清理掉    
+    - Load Safepoint OPS：加载 Safepoint 的次数。Safepoint 作用是在事务读数据时，保证不读到 Safepoint 之前的数据，保证数据安全。因为，Safepoint 之前的数据有可能被 GC 清理掉
     - Pessimistic Statement Retry OPS：悲观语句重试次数。当语句尝试加锁时，可能遇到写入冲突，此时，语句会重新获取新的 snapshot 并再次加锁
     - Transaction Types Per Seconds：每秒采用两阶段提交 (2PC)、异步提交 （Async Commit) 和一阶段提交 (1PC) 机制的事务数量，提供成功和失败两种数量
 

identify-expensive-queries.md

@@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/identify-expensive-queries/','/docs-cn/dev/how-to/mainta
 
 # 定位消耗系统资源多的查询
 
-TiDB 会将执行时间超过 [`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) 限制（默认值为 60s），或使用内存超过 [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) 限制（默认值为 1 GB）的语句输出到 [tidb-server 日志文件](/tidb-configuration-file.md#logfile)（默认文件为 "tidb.log"）中，用于在语句执行结束前定位消耗系统资源多的查询语句（以下简称为 expensive query），帮助用户分析和解决语句执行的性能问题。
+TiDB 会将执行时间超过 [`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) 限制（默认值为 60s），或使用内存超过 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 限制（默认值为 1 GB）的语句输出到 [tidb-server 日志文件](/tidb-configuration-file.md#logfile)（默认文件为 "tidb.log"）中，用于在语句执行结束前定位消耗系统资源多的查询语句（以下简称为 expensive query），帮助用户分析和解决语句执行的性能问题。
 
 注意，expensive query 日志和[慢查询日志](/identify-slow-queries.md)的区别是，慢查询日志是在语句执行完后才打印，expensive query 日志可以将正在执行的语句的相关信息打印出来。当一条语句在执行过程中达到资源使用阈值时（执行时间/使用内存量），TiDB 会即时将这条语句的相关信息写入日志。
 

non-transactional-dml.md

@@ -211,7 +211,7 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t where v < 6;
 
 非事务 DML 语句中，batch size 越大，拆分出来的 SQL 语句越少，每个 SQL 语句执行起来越慢。最优的 batch size 依据 workload 而定。根据经验值，推荐从 50000 开始尝试。过小和过大的 batch size 都会导致执行效率下降。
 
-每个 batch 的信息存储在内存里，因此 batch 数量过多会显著增加内存消耗。这也是 batch size 不能过小的原因之一。非事务语句用于存储 batch 信息消耗的内存上限与 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 相同，超出这个限制时触发的操作由 [`oom-action`](/tidb-configuration-file.md#oom-action) 配置项控制。
+每个 batch 的信息存储在内存里，因此 batch 数量过多会显著增加内存消耗。这也是 batch size 不能过小的原因之一。非事务语句用于存储 batch 信息消耗的内存上限与 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 相同，超出这个限制时触发的操作由系统变量 [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-从-v610-版本开始引入) 控制。
 
 ## 使用限制
 

optimizer-hints.md

@@ -353,7 +353,7 @@ SELECT /*+ MAX_EXECUTION_TIME(1000) */ * FROM t1 inner join t2 WHERE t1.id = t2.
 SELECT /*+ MEMORY_QUOTA(1024 MB) */ * FROM t;
 ```
 
-除了 Hint 外，系统变量 `tidb_mem_quota_query` 也能限制语句执行的内存使用。
+除了 Hint 外，系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 也能限制语句执行的内存使用。
 
 ### READ_CONSISTENT_REPLICA()
 

releases/release-4.0.10.md

@@ -92,7 +92,7 @@ TiDB 版本：4.0.10
 
     + Dumpling
 
-        - 修改默认设置的 `tidb_mem_quota_query` 的行为以避免 TiDB 内存溢出 [#233](https://github.com/pingcap/dumpling/pull/233)
+        - 修改默认设置的 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 的行为以避免 TiDB 内存溢出 [#233](https://github.com/pingcap/dumpling/pull/233)
 
     + Backup & Restore (BR)
 

releases/release-5.0.0.md

@@ -362,7 +362,7 @@ TiDB 引入的 Raft Joint Consensus 算法将成员变更操作中的“添加
 
 ### 优化内存管理模块，降低系统 OOM 的风险
 
-跟踪统计聚合函数的内存使用情况，系统默认开启该功能，开启后带有聚合函数的 SQL 语句在执行时，如果当前查询内存总的使用量超过 [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) 阈值时，系统自动采用 [`oom-action`](/tidb-configuration-file.md#oom-action) 定义的相应操作。
+跟踪统计聚合函数的内存使用情况，系统默认开启该功能，开启后带有聚合函数的 SQL 语句在执行时，如果当前查询内存总的使用量超过 `mem-quota-query` 阈值时，系统自动采用 `oom-action` 定义的相应操作。
 
 ### 提升系统在发生网络分区时的可用性
 

releases/release-5.0.1.md

@@ -12,12 +12,12 @@ TiDB 版本：5.0.1
 
 + TiDB 配置文件
 
-    - [`committer-concurrency`](/tidb-configuration-file.md#committer-concurrency) 配置项的默认值由 16 改成 128。
+    - `committer-concurrency` 配置项的默认值由 16 改成 128。
 
 ## 改进提升
 
 + TiDB
-    
+
     - 支持 `VITESS_HASH()` 函数 [#23915](https://github.com/pingcap/tidb/pull/23915)
 
 + TiKV