sys_var: merge sys_vars with tidb specific sys_vars (#4001)

* sys_var: merge sys_vars with tidb specific sys_vars

Signed-off-by: Ran <[email protected]>

* fix a dead anchor

Signed-off-by: Ran <[email protected]>

Co-authored-by: ti-srebot <[email protected]>

TOC.md

@@ -438,9 +438,7 @@
     + [tikv-server](/tikv-configuration-file.md)
     + [tiflash-server](/tiflash/tiflash-configuration.md)
     + [pd-server](/pd-configuration-file.md)
-  + 系统变量
-    + [MySQL 系统变量](/system-variables.md)
-    + [TiDB 特定系统变量](/tidb-specific-system-variables.md)
+  + [系统变量](/system-variables.md)
   + 存储引擎
     + TiKV
       + [TiKV 简介](/tikv-overview.md)

agg-distinct-optimization.md

@@ -25,7 +25,7 @@ mysql> explain select DISTINCT a from t;
 ## 聚合函数 DISTINCT
 
 通常来说，带有 `DISTINCT` 的聚合函数会单线程的在 TiDB 侧执行。
-使用系统变量 [`tidb_opt_distinct_agg_push_down`](/tidb-specific-system-variables.md#tidb_opt_distinct_agg_push_down) 或者 TiDB 的配置项 [distinct-agg-push-down](/tidb-configuration-file.md#distinct-agg-push-down) 控制优化器是否执行带有 `DISTINCT` 的聚合函数（比如 `select count(distinct a) from t`）下推到 Coprocessor 的优化操作。
+使用系统变量 [`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distinct_agg_push_down) 或者 TiDB 的配置项 [distinct-agg-push-down](/tidb-configuration-file.md#distinct-agg-push-down) 控制优化器是否执行带有 `DISTINCT` 的聚合函数（比如 `select count(distinct a) from t`）下推到 Coprocessor 的优化操作。
 
 在以下示例中，`tidb_opt_distinct_agg_push_down` 开启前，TiDB 需要从 TiKV 读取所有数据，并在 TiDB 侧执行 `disctinct`。`tidb_opt_distinct_agg_push_down` 开启后，`distinct a` 被下推到了 Coprocessor，在 `HashAgg_5` 里新增了一个 `group by` 列 `test.t.a`。
 

best-practices/tidb-best-practices.md

@@ -95,21 +95,21 @@ TiDB 支持完整的二级索引，并且是全局索引，很多查询可以通
 
     数据分散在很多 Region 上，所以 TiDB 在做查询的时候会并发进行，默认的并发度比较保守，因为过高的并发度会消耗大量的系统资源，且对于 OLTP 类型的查询，往往不会涉及到大量的数据，较低的并发度已经可以满足需求。对于 OLAP 类型的 Query，往往需要较高的并发度。所以 TiDB 支持通过 System Variable 来调整查询并发度。
 
-    - [tidb_distsql_scan_concurrency](/tidb-specific-system-variables.md#tidb_distsql_scan_concurrency)
+    - [tidb_distsql_scan_concurrency](/system-variables.md#tidb_distsql_scan_concurrency)
 
     在进行扫描数据的时候的并发度，这里包括扫描 Table 以及索引数据。
 
-    - [tidb_index_lookup_size](/tidb-specific-system-variables.md#tidb_index_lookup_size)
+    - [tidb_index_lookup_size](/system-variables.md#tidb_index_lookup_size)
 
     如果是需要访问索引获取行 ID 之后再访问 Table 数据，那么每次会把一批行 ID 作为一次请求去访问 Table 数据，这个参数可以设置 Batch 的大小，较大的 Batch 会使得延迟增加，较小的 Batch 可能会造成更多的查询次数。这个参数的合适大小与查询涉及的数据量有关。一般不需要调整。
 
-    - [tidb_index_lookup_concurrency](/tidb-specific-system-variables.md#tidb_index_lookup_concurrency)
+    - [tidb_index_lookup_concurrency](/system-variables.md#tidb_index_lookup_concurrency)
 
     如果是需要访问索引获取行 ID 之后再访问 Table 数据，每次通过行 ID 获取数据时候的并发度通过这个参数调节。
 
 + 通过索引保证结果顺序
 
-    索引除了可以用来过滤数据之外，还能用来对数据排序，首先按照索引的顺序获取行 ID，然后再按照行 ID 的返回顺序返回行的内容，这样可以保证返回结果按照索引列有序。前面提到了扫索引和获取 Row 之间是并行 + Pipeline 模式，如果要求按照索引的顺序返回 Row，那么这两次查询之间的并发度设置的太高并不会降低延迟，所以默认的并发度比较保守。可以通过 [tidb_index_serial_scan_concurrency](/tidb-specific-system-variables.md#tidb_index_serial_scan_concurrency) 变量进行并发度调整。
+    索引除了可以用来过滤数据之外，还能用来对数据排序，首先按照索引的顺序获取行 ID，然后再按照行 ID 的返回顺序返回行的内容，这样可以保证返回结果按照索引列有序。前面提到了扫索引和获取 Row 之间是并行 + Pipeline 模式，如果要求按照索引的顺序返回 Row，那么这两次查询之间的并发度设置的太高并不会降低延迟，所以默认的并发度比较保守。可以通过 [tidb_index_serial_scan_concurrency](/system-variables.md#tidb_index_serial_scan_concurrency) 变量进行并发度调整。
 
 + 逆序索引
 
@@ -154,7 +154,7 @@ for i from 0 to 23:
 
 ### 查询
 
-看业务的查询需求以及具体的语句，可以参考 [TiDB 专用系统变量和语法](/tidb-specific-system-variables.md)这篇文档
+看业务的查询需求以及具体的语句，可以参考 [TiDB 专用系统变量和语法](/system-variables.md)这篇文档
 可以通过 SET 语句控制 SQL 执行的并发度，另外通过 Hint 控制 Join 物理算子选择。
 
 另外 MySQL 标准的索引选择 Hint 语法，也可以用，通过 `Use Index/Ignore Index hint` 控制优化器选择索引。

dashboard/dashboard-overview.md

@@ -57,7 +57,7 @@ title: TiDB Dashboard 概况页面
 
 ![界面](/media/dashboard/dashboard-overview-slow-query.png)
 
-默认情况下运行时间超过 300ms 的SQL 查询即会被计为慢查询并显示在该表格中。可通过调整 [tidb_slow_log_threshold](/tidb-specific-system-variables.md#tidb_slow_log_threshold) 变量或 TiDB [slow-threshold](/tidb-configuration-file.md#slow-threshold) 参数调整阈值。
+默认情况下运行时间超过 300ms 的SQL 查询即会被计为慢查询并显示在该表格中。可通过调整 [tidb_slow_log_threshold](/system-variables.md#tidb_slow_log_threshold) 变量或 TiDB [slow-threshold](/tidb-configuration-file.md#slow-threshold) 参数调整阈值。
 
 该区域显示的内容与[慢查询页面](/dashboard/dashboard-slow-query.md)一致，可点击**最近的慢查询** (Recent Slow Queries) 标题查看完整列表。关于该表格中各列详情，见[慢查询页面](/dashboard/dashboard-slow-query.md)。
 

dashboard/dashboard-slow-query.md

@@ -7,7 +7,7 @@ summary: 了解如何在 TiDB Dashboard 中查看慢查询。
 
 该页面上能检索和查看集群中所有慢查询。
 
-默认情况下，执行时间超过 300ms 的 SQL 查询就会被视为慢查询，被记录到[慢查询日志](/identify-slow-queries.md)中，并可通过本功能对记录到的慢查询进行查询。可调整 [`tidb_slow_log_threshold`](/tidb-specific-system-variables.md#tidb_slow_log_threshold) SESSION 变量或 TiDB [`slow-threshold`](/tidb-configuration-file.md#slow-threshold) 参数调整慢查询阈值。
+默认情况下，执行时间超过 300ms 的 SQL 查询就会被视为慢查询，被记录到[慢查询日志](/identify-slow-queries.md)中，并可通过本功能对记录到的慢查询进行查询。可调整 [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) SESSION 变量或 TiDB [`slow-threshold`](/tidb-configuration-file.md#slow-threshold) 参数调整慢查询阈值。
 
 > **注意：**
 >

faq/sql-faq.md

@@ -80,7 +80,7 @@ TiDB 的 `show processlist` 与 MySQL 的 `show processlist` 显示内容基本
 
 ## 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？
 
-TiDB 支持改变 [per-session](/tidb-specific-system-variables.md#tidb_force_priority)、[全局](/tidb-configuration-file.md#force-priority)或单个语句的优先级。优先级包括：
+TiDB 支持改变 [per-session](/system-variables.md#tidb_force_priority)、[全局](/tidb-configuration-file.md#force-priority)或单个语句的优先级。优先级包括：
 
 - HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句
 - LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级

identify-expensive-queries.md

@@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/how-to/maintain/identify-abnormal-queries/identify-expen
 
 # 定位消耗系统资源多的查询
 
-TiDB 会将执行时间超过 [`tidb_expensive_query_time_threshold`](/tidb-specific-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），或使用内存超过 [`mem-quota-query`](/tidb-configuration-file.md#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 会即时将这条语句的相关信息写入日志。
 

partitioned-table.md

@@ -1053,4 +1053,4 @@ select * from t;
 
 环境变量 `tidb_enable_table_partition` 可以控制是否启用分区表功能。如果该变量设置为 `off`，则建表时会忽略分区信息，以普通表的方式建表。
 
-该变量仅作用于建表，已经建表之后再修改该变量无效。详见 [TiDB 专用系统变量和语法](/tidb-specific-system-variables.md#tidb_enable_table_partition)。
+该变量仅作用于建表，已经建表之后再修改该变量无效。详见[系统变量和语法](/system-variables.md#tidb_enable_table_partition)。

pessimistic-transaction.md

@@ -14,7 +14,7 @@ aliases: ['/docs-cn/dev/reference/transactions/transaction-pessimistic/']
 
 ## 事务模式的修改方法
 
-你可以使用 [`tidb_txn_mode`](/tidb-specific-system-variables.md#tidb_txn_mode) 系统变量设置事务模式。执行以下命令，即可使整个集群中所有新创建 session 执行的所有显示事务（即非 autocommit 的事务）进入悲观事务模式：
+你可以使用 [`tidb_txn_mode`](/system-variables.md#tidb_txn_mode) 系统变量设置事务模式。执行以下命令，即可使整个集群中所有新创建 session 执行的所有显示事务（即非 autocommit 的事务）进入悲观事务模式：
 
 {{< copyable "sql" >}}
 

query-execution-plan.md

@@ -395,7 +395,7 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00
 
 TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用来优化性能。其中一些系统变量和具体的算子相关，比如算子的并发度，算子的内存使用上限，是否允许使用分区表等。这些都可以通过系统变量进行控制，从而影响各个算子执行的效率。
 
-如果读者想要详细了解所有的系统变量及其使用规则，可以参见 [TiDB 专用系统变量和语法](/tidb-specific-system-variables.md)。
+如果读者想要详细了解所有的系统变量及其使用规则，可以参见[系统变量和语法](/system-variables.md)。
 
 ## 另请参阅
 
@@ -404,4 +404,4 @@ TiDB 在 MySQL 的基础上，定义了一些专用的系统变量和语法用
 * [ANALYZE TABLE](/sql-statements/sql-statement-analyze-table.md)
 * [TRACE](/sql-statements/sql-statement-trace.md)
 * [TiDB in Action](https://book.tidb.io/session3/chapter1/sql-execution-plan.html)
-* [System Variables](/tidb-specific-system-variables.md)
+* [System Variables](/system-variables.md)

releases/release-2.1.18.md

@@ -48,7 +48,7 @@ TiDB Ansible 版本：2.1.18
     - 修复 COM_STMT_FETCH 慢日志时间记录和 MySQL 不一致问题 [#12953](https://github.com/pingcap/tidb/pull/12953)
     - 当遇到写冲突时，在报错信息中添加错误码，以方便对冲突原因进行诊断 [#12878](https://github.com/pingcap/tidb/pull/12878)
 + DDL
-    - 为避免误操作，TiDB 默认不再允许删除列的 `AUTO INCREMENT` 属性，当确实需要删除时，请更改系统变量 `tidb_allow_remove_auto_inc`；相关文档请见：[TiDB 专用系统变量和语法](/tidb-specific-system-variables.md) [#12146](https://github.com/pingcap/tidb/pull/12146)
+    - 为避免误操作，TiDB 默认不再允许删除列的 `AUTO INCREMENT` 属性，当确实需要删除时，请更改系统变量 `tidb_allow_remove_auto_inc`；相关文档请见[系统变量和语法](/system-variables.md) [#12146](https://github.com/pingcap/tidb/pull/12146)
     - 支持 Create Table 语句中建唯一索引时带多个 Unique [#12469](https://github.com/pingcap/tidb/pull/12469)
     - 修复 `CreateTable` 语句中指定外键约束时，外键表在没有指定 Database 时未能使用主表的 Database 导致报错的问题 [#12678](https://github.com/pingcap/tidb/pull/12678)
     - 修复 `ADMIN CANCEL DDL JOBS` 时报 `invalid list index` 错的问题 [#12681](https://github.com/pingcap/tidb/pull/12681)

sql-mode.md

@@ -1,5 +1,5 @@
 ---
-title: SQL Mode
+title: SQL 模式
 aliases: ['/docs-cn/dev/reference/sql/sql-mode/']
 ---
 

sql-statements/sql-statement-create-index.md

@@ -205,7 +205,7 @@ CREATE UNIQUE INDEX c1 ON t1 (c1) INVISIBLE;
 
 ## 相关 session 变量
 
-和 `CREATE INDEX` 语句相关的全局变量有 `tidb_ddl_reorg_worker_cnt`，`tidb_ddl_reorg_batch_size` 和 `tidb_ddl_reorg_priority`，具体可以参考 [TiDB 特定系统变量](/tidb-specific-system-variables.md#tidb_ddl_reorg_worker_cnt)。
+和 `CREATE INDEX` 语句相关的全局变量有 `tidb_ddl_reorg_worker_cnt`，`tidb_ddl_reorg_batch_size` 和 `tidb_ddl_reorg_priority`，具体可以参考[系统变量](/system-variables.md#tidb_ddl_reorg_worker_cnt)。
 
 ## MySQL 兼容性
 

sql-statements/sql-statement-show-variables.md

@@ -24,7 +24,7 @@ aliases: ['/docs-cn/dev/reference/sql/statements/show-variables/']
 
 ## 示例
 
-查看 TiDB 定义的专用系统变量，关于这些变量的含义参见 [TiDB 专用系统变量和语法](/tidb-specific-system-variables.md)。
+查看 TiDB 定义的专用系统变量，关于这些变量的含义参见[系统变量和语法](/system-variables.md)。
 
 {{< copyable "sql" >}}
 
@@ -169,4 +169,4 @@ SHOW GLOBAL VARIABLES LIKE 'time_zone%';
 
 ## 另请参阅
 
-* [SET](/sql-statements/sql-statement-set-variable.md)
+* [`SET [GLOBAL|SESSION]`](/sql-statements/sql-statement-set-variable.md)

sql-statements/sql-statement-split-region.md

@@ -395,10 +395,8 @@ region3:   [ 2<<61     ,  3<<61 )
 region4:   [ 3<<61     ,  +inf  )
 ```
 
-## 相关 session 变量
-
-和 `SPLIT REGION` 语句相关的 session 变量有 `tidb_scatter_region`，`tidb_wait_split_region_finish` 和 `tidb_wait_split_region_timeout`，具体可参考 [TiDB 专用系统变量和语法](/tidb-specific-system-variables.md)。
-
 ## 另请参阅
 
 * [SHOW TABLE REGIONS](/sql-statements/sql-statement-show-table-regions.md)
+
+* Session 变量：[`tidb_scatter_region`](/system-variables.md#tidb_scatter_region)，[`tidb_wait_split_region_finish`](/system-variables.md#tidb_wait_split_region_finish) 和[`tidb_wait_split_region_timeout`](/system-variables.md#tidb_wait_split_region_timeout).

subquery-optimization.md

@@ -62,7 +62,7 @@ explain select * from t1 where t1.a in (select t2.a from t2);
 +------------------------------+---------+-----------+------------------------+----------------------------------------------------------------------------+
 ```
 
-这个改写会在 `IN` 子查询相对较小，而外部查询相对较大时产生更好的执行性能。因为不经过改写的情况下，我们无法使用以 t2 为驱动表的 `index join`。同时这里的弊端便是，当改写删成的聚合无法被自动消去且 `t2` 表比较大时，反而会影响查询的性能。目前 TiDB 中使用 [tidb\_opt\_insubq\_to\_join\_and\_agg](/tidb-specific-system-variables.md#tidb_opt_insubq_to_join_and_agg) 变量来控制这个优化的打开与否。当遇到不合适这个优化的情况可以手动关闭。
+这个改写会在 `IN` 子查询相对较小，而外部查询相对较大时产生更好的执行性能。因为不经过改写的情况下，我们无法使用以 t2 为驱动表的 `index join`。同时这里的弊端便是，当改写删成的聚合无法被自动消去且 `t2` 表比较大时，反而会影响查询的性能。目前 TiDB 中使用 [tidb\_opt\_insubq\_to\_join\_and\_agg](/system-variables.md#tidb_opt_insubq_to_join_and_agg) 变量来控制这个优化的打开与否。当遇到不合适这个优化的情况可以手动关闭。
 
 ## `EXISTS` 子查询以及 `... >/>=/</<=/=/!= (SELECT ... FROM ...)`