diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index c7f7b5ffa096..3c5807a3ab73 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/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 配置 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 26d2c333dc0c..5665625353de 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/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 ``` diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index f6e542996173..44cc930d294e 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/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 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 01609dd9c36b..01df8b446537 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -5,36 +5,21 @@ 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： @@ -42,7 +27,7 @@ set @@tidb_mem_quota_query = 8 << 30; {{< copyable "sql" >}} ```sql -set @@tidb_mem_quota_query = 8 << 20; +SET tidb_mem_quota_query = 8 << 20; ``` 配置整条 SQL 的内存使用阈值为 8KB： @@ -50,7 +35,7 @@ set @@tidb_mem_quota_query = 8 << 20; {{< 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 的硬盘空间。 diff --git a/dynamic-config.md b/dynamic-config.md index 94f73f729035..c8265084c5c9 100644 --- a/dynamic-config.md +++ b/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 查询阈值 | diff --git a/enable-disk-spill-encrypt.md b/enable-disk-spill-encrypt.md index 2d15f2f5641b..5fde11354890 100644 --- a/enable-disk-spill-encrypt.md +++ b/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) 的限制，某些算子可以将执行时的中间结果作为临时文件落盘保存，直到查询执行完成之后将它们删除。 用户可以开启落盘文件加密功能，防止攻击者通过读取临时文件来访问数据。 diff --git a/enable-tls-between-clients-and-servers.md b/enable-tls-between-clients-and-servers.md index b56cae1dd2cc..b9ca635dcc4a 100644 --- a/enable-tls-between-clients-and-servers.md +++ b/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 diff --git a/error-codes.md b/error-codes.md index 7340c688c052..9f444abdceba 100644 --- a/error-codes.md +++ b/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 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index a924eef9c2eb..d7b9948d8ede 100644 --- a/faq/sql-faq.md +++ b/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;` diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index dc8f08184348..413c4c8ae8ce 100644 --- a/grafana-tidb-dashboard.md +++ b/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) 机制的事务数量，提供成功和失败两种数量 diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index 90f01df54543..c83bc9797862 100644 --- a/identify-expensive-queries.md +++ b/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 会即时将这条语句的相关信息写入日志。 diff --git a/non-transactional-dml.md b/non-transactional-dml.md index cc410d1675d4..5e7f46a7ae18 100644 --- a/non-transactional-dml.md +++ b/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-版本开始引入) 控制。 ## 使用限制 diff --git a/optimizer-hints.md b/optimizer-hints.md index 0dd571ccb933..86b10b578680 100644 --- a/optimizer-hints.md +++ b/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() diff --git a/releases/release-4.0.10.md b/releases/release-4.0.10.md index 5d902bff62e0..f8d2a60bac04 100644 --- a/releases/release-4.0.10.md +++ b/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) diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index ecde3f61c6ac..a1e7fef13571 100644 --- a/releases/release-5.0.0.md +++ b/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` 定义的相应操作。 ### 提升系统在发生网络分区时的可用性 diff --git a/releases/release-5.0.1.md b/releases/release-5.0.1.md index fa481ddeb946..1ad6374e9fc9 100644 --- a/releases/release-5.0.1.md +++ b/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 diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 0d2ca169de4e..844db7d5d91c 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -22,7 +22,7 @@ TiDB 版本：5.1 > **注意：** > -> 当从一个早期的 TiDB 版本升级到 TiDB 5.1 时，如需了解所有中间版本对应的兼容性更改说明，请查看对应版本的 [Release Note](/releases/release-notes.md)。 +> 当从一个早期的 TiDB 版本升级到 TiDB 5.1 时，如需了解所有中间版本对应的兼容性更改说明，请查看对应版本的 [Release Note](/releases/release-notes.md)。 ### 系统变量 @@ -40,7 +40,7 @@ TiDB 版本：5.1 | 配置文件 | 配置项 | 修改类型 | 描述 | |:----------|:-----------|:-----------|:-----------| | TiDB 配置文件 | [`security.enable-sem`](/tidb-configuration-file.md#enable-sem) | 新增 | 控制是否启用安全增强模式 (SEM)。默认值为 `false`，代表未启用。 | -| TiDB 配置文件 | [`performance.committer-concurrency`](/tidb-configuration-file.md#committer-concurrency) | 修改 | 在单个事务的提交阶段，控制用于执行提交操作相关请求的并发数。默认值从 `16` 修改为 `128`。| +| TiDB 配置文件 | `performance.committer-concurrency` | 修改 | 在单个事务的提交阶段，控制用于执行提交操作相关请求的并发数。默认值从 `16` 修改为 `128`。| | TiDB 配置文件 | [`performance.tcp-no-delay`](/tidb-configuration-file.md#tcp-no-delay) | 新增 | 控制 TiDB 是否在 TCP 层开启 TCP_NODELAY。 默认值为 `true`，代表开启。 | | TiDB 配置文件 | [`performance.enforce-mpp`](/tidb-configuration-file.md#enforce-mpp) | 新增 | 用于在实例级别控制 TiDB 是否忽略优化器代价估算，强制使用 MPP 模式，默认值为 `false`。该配置项可以控制系统变量 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-从-v51-版本开始引入) 的初始值。 | | TiDB 配置文件 | [`pessimistic-txn.deadlock-history-capacity`](/tidb-configuration-file.md#deadlock-history-capacity) | 新增 | 控制单个 TiDB 节点的 [`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md) 表最多可记录的死锁事件个数，默认值为 “10”。 | @@ -119,19 +119,19 @@ TiDB 版本：5.1 `tidb_analyze_version = 2` 默认启用，避免了 Version 1 中因为哈希冲突导致的在较大的数据量中可能产生的较大误差，并保持了大多数场景中的估算精度。 [用户文档](/statistics.md) - + ### 事务 + 新增锁视图 (Lock View)（实验特性） Lock View 用于提供关于悲观锁的锁冲突和锁等待的更多信息，方便 DBA 通过锁视图功能来观察事务加锁情况以及排查死锁问题等 [#24199](https://github.com/pingcap/tidb/issues/24199) - + 用户文档： - 查看集群中所有 TiKV 节点上当前正在发生的悲观锁等锁：[`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) - 查看 TiDB 节点上最近发生的若干次死锁错误：[`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) - 查看 TiDB 节点上正在执行的事务的信息：[`TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) - + ### 性能 + 数据副本非一致性读 (Stale Read)（实验特性） diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ef304d337d30..8c7de6082cfb 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -53,7 +53,7 @@ key 中任何一项变动（如切换数据库，重命名 `Prepare` 语句， - 考虑到不同 `Execute` 的参数会不同，执行计划缓存为了保证适配性会禁止一些和具体参数值密切相关的激进查询优化手段，导致对特定的一些参数值，查询计划可能不是最优。比如查询的过滤条件为 `where a > ? and a < ?`，第一次 `Execute` 时参数分别为 2 和 1，考虑到这两个参数下次执行时可能会是 1 和 2，优化器不会生成对当前参数最优的 `TableDual` 执行计划。 - 如果不考虑缓存失效和淘汰，一份执行计划缓存会对应各种不同的参数取值，理论上也会导致某些取值下执行计划非最优。比如查询过滤条件为 `where a < ?`，假如第一次执行 `Execute` 时用的参数值为 1，此时优化器生成最优的 `IndexScan` 执行计划放入缓存，在后续执行 `Exeucte` 时参数变为 10000，此时 `TableScan` 可能才是更优执行计划，但由于执行计划缓存，执行时还是会使用先前生成的 `IndexScan`。因此执行计划缓存更适用于查询较为简单（查询编译耗时占比较高）且执行计划较为固定的业务场景。 -目前执行计划缓存功能默认打开，可以通过变量 [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-从-v610-版本开始引入) 启用或关闭这项功能。 +自 v6.1.0 起，执行计划缓存功能默认打开，可以通过变量 [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-从-v610-版本开始引入) 启用或关闭这项功能。 > **注意：** > diff --git a/system-variables.md b/system-variables.md index 9808e59289ee..0e6323ca3886 100644 --- a/system-variables.md +++ b/system-variables.md @@ -24,10 +24,10 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; > **注意：** > > 部分 `GLOBAL` 作用域的变量会持久化到 TiDB 集群中。文档中的变量有一个“是否持久化到集群”的说明，可以为“是”或者“否”。 -> +> > - 对于持久化到集群的变量，当该全局变量被修改后，会通知所有 TiDB 服务器刷新其系统变量缓存。在集群中增加一个新的 TiDB 服务器时，或者重启现存的 TiDB 服务器时，都将自动使用该持久化变量。 > - 对于不持久化到集群的变量，对变量的修改只对当前连接的 TiDB 实例生效。如果需要保留设置过的值，需要在 `tidb.toml` 配置文件中声明。 -> +> > 此外，由于应用和连接器通常需要读取 MySQL 变量，为了兼容这一需求，在 TiDB 中，部分 MySQL 的变量既可读取也可设置。例如，尽管 JDBC 连接器不依赖于查询缓存 (query cache) 的行为，但仍然可以读取和设置查询缓存。 > **注意：** @@ -152,7 +152,8 @@ mysql> SELECT * FROM t1; ### `ddl_slow_threshold` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`300` - 单位：毫秒 - 耗时超过该阈值的 DDL 操作会被输出到日志。 @@ -236,13 +237,15 @@ mysql> SELECT * FROM t1; ### `plugin_dir` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值："" - 指定加载插件的目录。 ### `plugin_load` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值："" - 指定 TiDB 启动时加载的插件，多个插件之间用逗号（,）分隔。 @@ -269,6 +272,15 @@ mysql> SELECT * FROM t1; - 该变量用于为 SQL 函数 `RAND()` 中使用的随机值生成器添加种子。 - 该变量的行为与 MySQL 兼容。 +### require_secure_transport 从 v6.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 默认值：`OFF` +- 该变量控制是否所有 TiDB 的连接都在本地 socket 上进行通信，或使用 TLS。详情见[为 TiDB 客户端服务端间通信开启加密传输](/enable-tls-between-clients-and-servers.md)。 +- 该变量设置为 `ON` 时，必须使用开启 TLS 的会话连接到 TiDB，防止在 TLS 配置不正确时出现锁定的情况。 +- 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`security.require-secure-transport`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 + ### skip_name_resolve 从 v5.2.0 版本开始引入 - 作用域：GLOBAL @@ -384,7 +396,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 > **注意：** > -> 只有在 TiDB 的启动配置文件中开启了 `run-auto-analyze` 选项，该 TiDB 才会触发 `auto_analyze`。 +> 当系统变量 `tidb_enable_auto_analyze` 设置为 `ON` 时，TiDB 才会触发 `auto_analyze`。 ### `tidb_auto_analyze_start_time` @@ -470,11 +482,22 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 ### `tidb_check_mb4_value_in_utf8` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`ON` - 设置该变量为 `ON` 可强制只存储[基本多文种平面 (BMP)](https://zh.wikipedia.org/zh-hans/Unicode字符平面映射) 编码区段内的 `utf8` 字符值。若要存储 BMP 区段外的 `utf8` 值，推荐使用 `utf8mb4` 字符集。 - 早期版本的 TiDB 中 (v2.1.x)，`utf8` 检查更为宽松。如果你的 TiDB 集群是从早期版本升级的，推荐关闭该变量，详情参阅[升级与升级后常见问题](/faq/upgrade-faq.md)。 +### tidb_committer_concurrency 从 v6.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 默认值：`128` +- 范围：`[1, 10000]` +- 在单个事务的提交阶段，用于执行提交操作相关请求的 goroutine 数量。 +- 若提交的事务过大，事务提交时的流控队列等待耗时可能会过长。此时，可以通过调大该配置项来加速提交。 +- 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`performance.committer-concurrency`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 + ### `tidb_checksum_table_concurrency` - 作用域：SESSION @@ -650,6 +673,14 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 > - 启用 TiDB Binlog 后，开启该选项无法获得性能提升。要获得性能提升，建议使用 [TiCDC](/ticdc/ticdc-overview.md) 替代 TiDB Binlog。 > - 启用该参数仅意味着 Async Commit 成为可选的事务提交模式，实际由 TiDB 自行判断选择最合适的提交模式进行事务提交。 +### `tidb_enable_auto_analyze` 从 v6.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 默认值：`ON` +- 该变量控制 TiDB 是否以后台操作自动更新表的统计信息。 +- 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`performance.run-auto-analyze`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 + ### `tidb_enable_auto_increment_in_generated` - 作用域：SESSION | GLOBAL @@ -657,6 +688,14 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 默认值：`OFF` - 这个变量用于控制是否允许在创建生成列或者表达式索引时引用自增列。 +### tidb_enable_batch_dml 从 v6.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 默认值：`OFF` +- 该变量控制 TiDB 是否允许非事务的“批处理”语句。由于 batch DML 不提供 ACID 保证，只有该变量设置为 `OFF` 时才是安全的。 +- 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`enable-batch-dml`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 + ### `tidb_enable_cascades_planner` > **警告：** @@ -687,7 +726,8 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 ### `tidb_enable_collect_execution_info` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`ON` - 这个变量用于控制是否同时将各个执行算子的执行信息记录入 slow query log 中。 @@ -751,14 +791,14 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 -- 默认值：`ON` +- 默认值：`ON` - 这个变量用于控制是否开启 index merge 功能。 ### tidb_enable_legacy_instance_scope 从 v6.0.0 版本开始引入 - 作用域：SESSION | GLOBAL - 是否持久化到集群：是 -- 默认值：`ON` +- 默认值：`ON` - 这个变量用于允许使用 `SET SESSION` 对 `INSTANCE` 作用域的变量进行设置，用法同 `SET GLOBAL`。 - 为了兼容之前的 TiDB 版本，该变量值默认为 `ON`。 @@ -848,7 +888,8 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 ### `tidb_enable_slow_log` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`ON` - 这个变量用于控制是否开启 slow log 功能。 @@ -1016,7 +1057,8 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_expensive_query_time_threshold` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`60` - 范围：`[10, 2147483647]` - 单位：秒 @@ -1024,7 +1066,8 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_force_priority` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`NO_PRIORITY` - 这个变量用于改变 TiDB server 上执行的语句的默认优先级。例如，你可以通过设置该变量来确保正在执行 OLAP 查询的用户优先级低于正在执行 OLTP 查询的用户。 - 可设置为 `NO_PRIORITY`、`LOW_PRIORITY`、`DELAYED` 或 `HIGH_PRIORITY`。 @@ -1254,6 +1297,16 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 范围：`[100, 16384]` - 这个变量用来设置缓存 schema 版本信息（对应版本修改的相关 table IDs）的个数限制，可设置的范围 100 - 16384。此变量在 2.1.18 及之后版本支持。 +### tidb_mem_oom_action 从 v6.1.0 版本开始引入 + +- 作用域：GLOBAL +- 是否持久化到集群：是 +- 默认值：`CANCEL` +- 可选值：`CANCEL`，`LOG` +- 该变量控制当单个查询使用的内存超过限制 (`tidb_mem_quota_query`) 且不能再利用临时磁盘时，TiDB 所采取的操作。详情见 [TiDB 内存控制](/configure-memory-usage.md)。 +- 该变量默认值为 `CANCEL`，但在 TiDB v4.0.2 及之前的版本中，默认值为 `LOG`。 +- 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`oom-action`) 进行配置，升级到 v6.1.0 时会自动继承原有设置。 + ### `tidb_mem_quota_apply_cache` 从 v5.0 版本开始引入 - 作用域：SESSION | GLOBAL @@ -1276,16 +1329,19 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） ### `tidb_mem_quota_query` -- 作用域：SESSION +- 作用域：SESSION ｜ GLOBAL +- 是否持久化到集群：是 - 默认值：`1073741824` (1 GiB) - 范围：`[-1, 9223372036854775807]` - 单位：字节 - 这个变量用来设置一条查询语句的内存使用阈值。 -- 如果一条查询语句执行过程中使用的内存空间超过该阈值，会触发 TiDB 启动配置文件中 OOMAction 项所指定的行为。该变量的初始值由配置项 [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) 配置。 +- 如果一条查询语句执行过程中使用的内存空间超过该阈值，会触发系统变量 [`tidb_mem_oom_action`](#tidb_mem_oom_action-从-v610-版本开始引入) 中指定的行为。 +- 在 v6.1.0 之前这个开关通过 TiDB 配置文件 (`mem-quota-query`) 进行配置，且作用域为 `SESSION`。升级到 v6.1.0 时会自动继承原有设置，作用域变更为 `SESSION | GLOBAL`。 ### `tidb_memory_usage_alarm_ratio` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`0.8` - TiDB 内存使用占总内存的比例超过一定阈值时会报警。该功能的详细介绍和使用方法可以参考 [`memory-usage-alarm-ratio`](/tidb-configuration-file.md#memory-usage-alarm-ratio-从-v409-版本开始引入)。 - 该变量的初始值可通过 [`memory-usage-alarm-ratio`](/tidb-configuration-file.md#memory-usage-alarm-ratio-从-v409-版本开始引入) 进行配置。 @@ -1508,7 +1564,8 @@ explain select * from t where age=5; ### `tidb_pprof_sql_cpu` 从 v4.0 版本开始引入 -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`0` - 范围：`[0, 1]` - 这个变量用来控制是否在 profile 输出中标记出对应的 SQL 语句，用于定位和排查性能问题。 @@ -1546,11 +1603,13 @@ explain select * from t where age=5; ### `tidb_query_log_max_len` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：是 - 默认值：`4096` (4 KiB) -- 范围：`[-1, 9223372036854775807]` +- 范围：`[0, 1073741824]` - 单位：字节 -- 最长的 SQL 输出长度。当语句的长度大于 query-log-max-len，将会被截断输出。 +- 该变量控制 SQL 语句输出的最大长度。当一条 SQL 语句的输出长度大于 `tidb_query_log_max_len` 时，输出将会被截断。 +- 在 v6.1.0 之前这个开关也可以通过 TiDB 配置文件 (`log.query-log-max-len`) 进行配置，升级到 v6.1.0 后仅可通过系统变量配置。 示例： @@ -1582,7 +1641,8 @@ SET tidb_query_log_max_len = 20; ### `tidb_record_plan_in_slow_log` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`ON` - 这个变量用于控制是否在 slow log 里包含慢查询的执行计划。 @@ -1679,7 +1739,8 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) ### `tidb_slow_log_threshold` -- 作用域：INSTANCE +- 作用域：GLOBAL +- 是否持久化到集群：否 - 默认值：`300` - 范围：`[-1, 9223372036854775807]` - 单位：毫秒 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index d9b95235eb4e..1458e9cbc144 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -24,22 +24,14 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 最大值（64 位平台）：`18446744073709551615` + 最大值（32 位平台）：`4294967295` -### `mem-quota-query` - -+ 单条 SQL 语句可以占用的最大内存阈值，单位为字节。 -+ 默认值：1073741824 -+ 注意：当集群从 v2.0.x 或 v3.0.x 版本直接升级至 v4.0.9 及以上版本时，该配置默认值为 34359738368。 -+ 超过该值的请求会被 `oom-action` 定义的行为所处理。 -+ 该值作为系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 的初始值。 - ### `oom-use-tmp-storage` -+ 设置是否在单条 SQL 语句的内存使用超出 `mem-quota-query` 限制时为某些算子启用临时磁盘。 ++ 设置是否在单条 SQL 语句的内存使用超出系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 限制时为某些算子启用临时磁盘。 + 默认值：true ### `tmp-storage-path` -+ 单条 SQL 语句的内存使用超出 `mem-quota-query` 限制时，某些算子的临时磁盘存储位置。 ++ 单条 SQL 语句的内存使用超出系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 限制时，某些算子的临时磁盘存储位置。 + 默认值：`<操作系统临时文件夹>/<操作系统用户ID>_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage`。其中 `MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=` 是对 `:/:` 进行 `Base64` 编码的输出结果。 + 此配置仅在 `oom-use-tmp-storage` 为 true 时有效。 @@ -52,22 +44,6 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 默认值：-1 + 当 `tmp-storage-path` 的剩余可用容量低于 `tmp-storage-quota` 所定义的值时，TiDB server 启动时将会报出错误并退出。 -### `oom-action` - -+ 当 TiDB 中单条 SQL 的内存使用超出 `mem-quota-query` 限制且不能再利用临时磁盘时的行为。 -+ 默认值："cancel" -+ 目前合法的选项为 ["log", "cancel"]。设置为 "log" 时，仅输出日志。设置为 "cancel" 时，取消执行该 SQL 操作，并输出日志。 - -### `lower-case-table-names` - -+ 这个选项可以设置 TiDB 的系统变量 `lower_case_table_names` 的值。 -+ 默认值：2 -+ 具体可以查看 MySQL 关于这个变量的[描述](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lower_case_table_names) - -> **注意：** -> -> 目前 TiDB 只支持将该选项的值设为 2，即按照大小写来保存表名，按照小写来比较（不区分大小写）。 - ### `lease` + DDL 租约超时时间。 @@ -236,12 +212,6 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 默认值：10000 + 当查询的行数（包括中间结果，基于统计信息）大于这个值，该操作会被认为是 `expensive` 查询，并输出一个前缀带有 `[EXPENSIVE_QUERY]` 的日志。 -### `query-log-max-len` - -+ 最长的 SQL 输出长度。 -+ 默认值：4096 -+ 当语句的长度大于 `query-log-max-len`，将会被截断输出。 - ## log.file 日志文件相关的配置项。 @@ -275,11 +245,6 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ 安全相关配置。 -### `require-secure-transport` - -- 配置是否要求客户端使用安全传输模式。 -- 默认值：`false` - ### `enable-sem` - 启用安全增强模式 (SEM)。 @@ -388,12 +353,6 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 单位：毫秒 + 超过此时间的事务只能执行提交或者回滚，提交不一定能够成功。 -### `committer-concurrency` - -+ 在单个事务的提交阶段，用于执行提交操作相关请求的 goroutine 数量 -+ 默认值：128 -+ 若提交的事务过大，事务提交时的流控队列等待耗时可能会过长，可以通过调大该配置项来加速提交。 - ### `stmt-count-limit` + TiDB 单个事务允许的最大语句条数限制。 @@ -430,11 +389,6 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ - `mysql.stats_histograms`/`mysql.stats_buckets` 和 `mysql.stats_top_n`：TiDB 不再自动 analyze 和主动更新统计信息 - `mysql.stats_feedback`：TiDB 不再根据被查询的数据反馈的部分统计信息更新表和索引的统计信息 -### `run-auto-analyze` - -+ TiDB 是否做自动的 Analyze。 -+ 默认值：true - ### `feedback-probability` + TiDB 对查询收集统计信息反馈的概率。 @@ -471,6 +425,26 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 默认值：false + 该配置项可以控制系统变量 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-从-v51-版本开始引入) 的初始值。例如，当设置该配置项为 true 时，`tidb_enforce_mpp` 的默认值为 ON。 +### `stats-load-concurrency` 从 v5.4.0 版本开始引入 + +> **警告：** +> +> 统计信息同步加载功能目前为实验性特性，不建议在生产环境中使用。 + ++ TiDB 统计信息同步加载功能可以并发处理的最大列数 ++ 默认值：5 ++ 目前的合法值范围：`[1, 128]` + +### `stats-load-queue-size` 从 v5.4.0 版本开始引入 + +> **警告：** +> +> 统计信息同步加载功能目前为实验性特性，不建议在生产环境中使用。 + ++ 用于设置 TiDB 统计信息同步加载功能最多可以缓存多少列的请求 ++ 默认值：1000 ++ 目前的合法值范围：`[1, 100000]` + ### `enable-stats-cache-mem-quota` 从 v6.1.0 版本开始引入 + 用于控制 TiDB 是否开启统计信息缓存的内存上限。 @@ -708,23 +682,3 @@ experimental 部分为 TiDB 实验功能相关的配置。该部分从 v3.1.0 + 用于控制是否能创建表达式索引。自 v5.2.0 版本起，如果表达式中的函数是安全的，你可以直接基于该函数创建表达式索引，不需要打开该配置项。如果要创建基于其他函数的表达式索引，可以打开该配置项，但可能存在正确性问题。通过查询 `tidb_allow_function_for_expression_index` 变量可得到能直接用于创建表达式的安全函数。 + 默认值：false - -### `stats-load-concurrency` 从 v5.4.0 版本开始引入 - -> **警告：** -> -> 统计信息同步加载功能目前为实验性特性，不建议在生产环境中使用。 - -+ TiDB 统计信息同步加载功能可以并发处理的最大列数 -+ 默认值：5 -+ 目前的合法值范围：`[1, 128]` - -### `stats-load-queue-size` 从 v5.4.0 版本开始引入 - -> **警告：** -> -> 统计信息同步加载功能目前为实验性特性，不建议在生产环境中使用。 - -+ 用于设置 TiDB 统计信息同步加载功能最多可以缓存多少列的请求 -+ 默认值：1000 -+ 目前的合法值范围：`[1, 100000]` diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index d61e9f0971ac..24257eed07c7 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -119,7 +119,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles > **注意：** > - > 单条 SQL 内存阈值的默认值为 `1GB`，可通过 `tidb_mem_quota_query` 系统变量进行设置，作用域为 `SESSION`，单位为 `Byte`。也可以通过配置项热加载的方式，对配置文件中的 `mem-quota-query` 项进行修改，单位为 `Byte`。 + > 单条 SQL 内存阈值的默认值为 `1GB`，可通过系统变量 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 进行设置。 - 3.2.3 缓解 OOM 问题