From db39ca23f65717bcfd4f0f823ca62f0589b2c604 Mon Sep 17 00:00:00 2001 From: Nullnotnil Date: Fri, 3 Jul 2020 12:10:11 -0600 Subject: [PATCH 01/11] system-variables: Merge with tidb-specific-sysvars This merges the two documents together. --- sql-statements/sql-statement-alter-table.md | 15 + sql-statements/sql-statement-create-table.md | 15 + system-variables.md | 760 ++++++++++++++++--- tidb-specific-system-variables.md | 595 --------------- 4 files changed, 691 insertions(+), 694 deletions(-) delete mode 100644 tidb-specific-system-variables.md diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index 736ad452ccba9..256163e4b86f4 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -59,6 +59,21 @@ mysql> EXPLAIN SELECT * FROM t1 WHERE c1 = 3; 2 rows in set (0.00 sec) ``` +## SHARD_ROW_ID_BITS + +For tables with a non-integer `PRIMARY KEY` or without a `PRIMARY KEY`, TiDB uses an implicit auto-increment ROW ID. Because regions are automatically sharded using a range-based scheme on the `PRIMARY KEY`, hotspots can occur when there are a large number of `INSERT` operations. + +To mitigate the hot spot issue, you can configure `SHARD_ROW_ID_BITS`. The ROW ID is scattered and the data is written into multiple different Regions. But setting an overlarge value might lead to an excessively large number of RPC requests, which increases the CPU and network overhead. + +- `SHARD_ROW_ID_BITS = 4` indicates 16 shards +- `SHARD_ROW_ID_BITS = 6` indicates 64 shards +- `SHARD_ROW_ID_BITS = 0` indicates the default 1 shard + +Usage: + +- `CREATE TABLE`: `CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;` +- `ALTER TABLE`: `ALTER TABLE t SHARD_ROW_ID_BITS = 4;` + ## MySQL compatibility * All of the data types except spatial types are supported. For other unsupported cases, refer to: [compatibility of DDL statements with MySQL](/mysql-compatibility.md#ddl). diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md index 0f4996704a67c..d9dfc667db2e0 100644 --- a/sql-statements/sql-statement-create-table.md +++ b/sql-statements/sql-statement-create-table.md @@ -270,6 +270,21 @@ mysql> SELECT * FROM t1; 1 row in set (0.00 sec) ``` +## SHARD_ROW_ID_BITS + +For tables with a non-integer `PRIMARY KEY` or without a `PRIMARY KEY`, TiDB uses an implicit auto-increment ROW ID. Because regions are automatically sharded using a range-based scheme on the `PRIMARY KEY`, hotspots can occur when there are a large number of `INSERT` operations. + +To mitigate the hot spot issue, you can configure `SHARD_ROW_ID_BITS`. The ROW ID is scattered and the data is written into multiple different Regions. But setting an overlarge value might lead to an excessively large number of RPC requests, which increases the CPU and network overhead. + +- `SHARD_ROW_ID_BITS = 4` indicates 16 shards +- `SHARD_ROW_ID_BITS = 6` indicates 64 shards +- `SHARD_ROW_ID_BITS = 0` indicates the default 1 shard + +Usage: + +- `CREATE TABLE`: `CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;` +- `ALTER TABLE`: `ALTER TABLE t SHARD_ROW_ID_BITS = 4;` + ## MySQL compatibility * TiDB does not support temporary tables, but it ignores the `CREATE TEMPORARY TABLE` syntax. diff --git a/system-variables.md b/system-variables.md index 8815cf841cc2a..161eaccb59d34 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1,129 +1,691 @@ --- -title: The System Variables -summary: Learn how to use the system variables in TiDB. +title: System Variables +summary: Use system variables to optimize performance or alter running behavior. category: reference -aliases: ['/docs/dev/system-variables/','/docs/dev/reference/configuration/tidb-server/mysql-variables/'] +aliases: ['/docs/dev/tidb-specific-system-variables/','/docs/dev/reference/configuration/tidb-server/tidb-specific-variables/', '/tidb/dev/tidb-specific-system-variables'] --- -# The System Variables +# System Variables -The system variables in MySQL are the system parameters that modify the operation of the database runtime. These variables have two types of scope, Global Scope and Session Scope. TiDB supports all the system variables in MySQL 5.7. Most of the variables are only supported for compatibility and do not affect the runtime behaviors. +TiDB system variables behavior similar to MySQL, in that settings may apply on a `SESSION`, `GLOBAL` or both `SESSION` and `GLOBAL` scope. Changes to `GLOBAL` scoped variables **only apply** to new connections to TiDB. Variables can be set with the [`SET` statement](/sql-statements/sql-statement-set-variable.md) on a per-session or global basis: -## Set the system variables +```sql +# These two identical statements change a session variable +SET tidb_distsql_scan_concurrency = 10; +SET SESSION tidb_distsql_scan_concurrency = 10; -You can use the [`SET`](/sql-statements/sql-statement-set-variable.md) statement to change the value of the system variables. Before you change, consider the scope of the variable. For more information, see [MySQL Dynamic System Variables](https://dev.mysql.com/doc/refman/5.7/en/dynamic-system-variables.html). +# These two identical statements change a global variable +SET @@global.tidb_distsql_scan_concurrency = 10; +SET GLOBAL tidb_distsql_scan_concurrency = 10; +``` -### Set Global variables +> **Note:** +> +> TiDB differs from MySQL in that `GLOBAL` scoped variables **persist** through TiDB server restarts. Changes will also be propagated to other TiDB servers every 2 seconds [TiDB #14531](https://github.com/pingcap/tidb/issues/14531). +> Additionally, TiDB presents several MySQL variables from MySQL 5.7 as both readable and settable. This is required for compatibility, since it is common for both applications and connectors to read MySQL variables. For example: JDBC connectors both read and set query cache settings, despite not relying on the behavior. -Add the `GLOBAL` keyword before the variable or use `@@global.` as the modifier: +## Variable Reference -```sql -SET GLOBAL autocommit = 1; -SET @@global.autocommit = 1; -``` +### autocommit + +- Scope: SESSION | GLOBAL +- Default value: ON +- whether automatically commit a transaction + +### foreign_key_checks + +- Scope: NONE +- Default value: OFF +- For compatibility, TiDB returns foreign key checks as OFF. + +### hostname + +- Scope: NONE +- Default value: (system hostname) +- The hostname of the TiDB server as a read-only variable. + +### innodb_lock_wait_timeout + +- Scope: SESSION | GLOBAL +- Default value: 50 +- The lock wait timeout for pessimistic transactions (default) in seconds. + +### last_plan_from_cache New in v4.0 + +- Scope: SESSION +- Default value: 0 +- This variable is used to show whether the execution plan used in the previous `execute` statement is taken directly from the plan cache. + +### max_execution_time + +- Scope: SESSION | GLOBAL +- Default value: 0 +- The maximum execution time of a statement in milliseconds. The default value is unlimited (zero). > **Note:** > -> In a distributed TiDB database, a variable's `GLOBAL` setting is persisted to the storage layer. A single TiDB instance proactively gets the `GLOBAL` information and forms `gvc` (global variables cache) every 2 seconds. The cache information remains valid within 2 seconds. When you set the `GLOBAL` variable, to ensure the effectiveness of new sessions, make sure that the interval between two operations is larger than 2 seconds. For details, see [Issue #14531](https://github.com/pingcap/tidb/issues/14531). +> Unlike in MySQL, the `max_execution_time` system variable currently works on all kinds of statements in TiDB, not only restricted to the `SELECT` statement. The precision of the timeout value is roughly 100ms. This means the statement might not be terminated in accurate milliseconds as you specify. -### Set Session variables +### sql_mode -Add the `SESSION` keyword before the variable, use `@@session.` as the modifier, or use no modifier: +- Scope: SESSION | GLOBAL +- Default value: `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION` +- This variable controls a number of MySQL compatibility behaviors. See [SQL Mode](/sql-mode.md) for more information. -```sql -SET SESSION autocommit = 1; -SET @@session.autocommit = 1; -SET @@autocommit = 1; -``` +### sql_select_limit + +- Scope: SESSION | GLOBAL +- Default value: `2^64 - 1` (18446744073709551615) +- The maximum number of rows to return from the `SELECT` statements. + +### tidb_allow_batch_cop New in v4.0 version + +- Scope: SESSION | GLOBAL +- Default value: 0 +- This variable is used to control how TiDB sends a coprocessor request to TiFlash. It has the following values: + + * `0`: Never send requests in batches + * `1`: Aggregation and join requests are sent in batches + * `2`: All coprocessor requests are sent in batches + +### tidb_allow_remove_auto_inc New in v2.1.18 and v3.0.4 + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether the `AUTO_INCREMENT` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. + +### tidb_auto_analyze_end_time + +- Scope: GLOBAL +- Default value: 23:59 +0000 +- This variable is used to restrict the time window that the automatic update of statistics is permitted. For example, to only allow automatic statistics updates between 1AM and 3AM, set `tidb_auto_analyze_start_time='01:00 +0000'` and `tidb_auto_analyze_end_time='03:00 +0000'`. + +### tidb_auto_analyze_ratio + +- Scope: GLOBAL +- Default value: 0.5 +- This variable is used to set the threshold when TiDB automatically executes [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) in a background thread to update table statistics. For example, a value of 0.5 means that auto-analyze is triggered when greater than 50% of the rows in a table have been modified. Auto-analyze can be restricted to only execute during certain hours of the day by specifying `tidb_auto_analyze_start_time` and `tidb_auto_analyze_end_time`. > **Note:** > -> `LOCAL` and `@@local.` are the synonyms for `SESSION` and `@@session.` +> Only when the `run-auto-analyze` option is enabled in the starting configuration file of TiDB, the `auto_analyze` feature can be triggered. + +### tidb_auto_analyze_start_time + +- Scope: GLOBAL +- Default value: 00:00 +0000 +- This variable is used to restrict the time window that the automatic update of statistics is permitted. For example, to only allow automatic statistics updates between 1AM and 3AM, set `tidb_auto_analyze_start_time='01:00 +0000'` and `tidb_auto_analyze_end_time='03:00 +0000'`. + + +### tidb_backoff_lock_fast + +- Scope: SESSION | GLOBAL +- Default value: 100 +- This variable is used to set the `backoff` time when the read request meets a lock. + +### tidb_backoff_weight + +- Scope: SESSION | GLOBAL +- Default value: 2 +- This variable is used to increase the weight of the maximum time of TiDB `backoff`, that is, the maximum retry time for sending a retry request when an internal network or other component (TiKV, PD) failure is encountered. This variable can be used to adjust the maximum retry time and the minimum value is 1. + + For example, the base timeout for TiDB to take TSO from PD is 15 seconds. When `tidb_backoff_weight = 2`, the maximum timeout for taking TSO is: *base time \* 2 = 30 seconds*. + + In the case of a poor network environment, appropriately increasing the value of this variable can effectively alleviate error reporting to the application end caused by timeout. If the application end wants to receive the error information more quickly, minimize the value of this variable. + +### tidb_build_stats_concurrency + +- Scope: SESSION +- Default value: 4 +- This variable is used to set the concurrency of executing the `ANALYZE` statement. +- When the variable is set to a larger value, the execution performance of other queries is affected. + +### tidb_check_mb4_value_in_utf8 + +- Scope: SERVER +- Default value: 1, indicating check the validity of UTF-8 data. This default behavior is compatible with MySQL. +- This variable is used to set whether to check the validity of UTF-8 data. +- To upgrade an earlier version (TiDB v2.1.1 or earlier), you may need to disable this option. Otherwise, you can successfully write invalid strings in an earlier version but fail to do this in a later version, because there is no data validity check in the earlier version. For details, see [FAQs After Upgrade](/faq/upgrade-faq.md). + +### tidb_checksum_table_concurrency + +- Scope: SESSION +- Default value: 4 +- This variable is used to set the scan index concurrency of executing the `ADMIN CHECKSUM TABLE` statement. +- When the variable is set to a larger value, the execution performance of other queries is affected. + +### tidb_config + +- Scope: SESSION +- Default value: "" +- This variable is read-only. It is used to obtain the configuration information of the current TiDB server. + +### tidb_constraint_check_in_place + +- Scope: SESSION | GLOBAL +- Default value: 0 +- TiDB supports the optimistic transaction model. This means that conflict check (unique key check) is performed when the transaction is committed. This variable is used to set whether to do a unique key check each time a row of data is written. +- If this variable is enabled, the performance might be affected in a scenario where a large batch of data is written. For example: + + - When this variable is disabled: + + ```sql + tidb> create table t (i int key); + tidb> insert into t values (1); + tidb> begin + tidb> insert into t values (1); + Query OK, 1 row affected + tidb> commit; -- Check only when a transaction is committed. + ERROR 1062 : Duplicate entry '1' for key 'PRIMARY' + ``` + + - After this variable is enabled: + + ```sql + tidb> set @@tidb_constraint_check_in_place=1; + tidb> begin + tidb> insert into t values (1); + ERROR 1062 : Duplicate entry '1' for key 'PRIMARY' + ``` + +### tidb_current_ts + +- Scope: SESSION +- Default value: 0 +- This variable is read-only. It is used to obtain the timestamp of the current transaction. + +### tidb_ddl_error_count_limit + +- Scope: GLOBAL +- Default value: 512 +- This variable is used to set the number of retries when the DDL operation fails. When the number of retries exceeds the parameter value, the wrong DDL operation is canceled. + +### tidb_ddl_reorg_batch_size + +- Scope: GLOBAL +- Default value: 256 +- This variable is used to set the batch size during the `re-organize` phase of the DDL operation. For example, when TiDB executes the `ADD INDEX` operation, the index data needs to backfilled by `tidb_ddl_reorg_worker_cnt` (the number) concurrent workers. Each worker backfills the index data in batches. + - If many updating operations such as `UPDATE` and `REPLACE` exist during the `ADD INDEX` operation, a larger batch size indicates a larger probability of transaction conflicts. In this case, you need to adjust the batch size to a smaller value. The minimum value is 32. + - If the transaction conflict does not exist, you can set the batch size to a large value. The maximum value is 10240. This can increase the speed of the backfilling data, but the write pressure on TiKV also becomes higher. + +### tidb_ddl_reorg_priority + +- Scope: SESSION | GLOBAL +- Default value: `PRIORITY_LOW` +- This variable is used to set the priority of executing the `ADD INDEX` operation in the `re-organize` phase. +- You can set the value of this variable to `PRIORITY_LOW`, `PRIORITY_NORMAL` or `PRIORITY_HIGH`. + +### tidb_ddl_reorg_worker_cnt + +- Scope: GLOBAL +- Default value: 4 +- This variable is used to set the concurrency of the DDL operation in the `re-organize` phase. + +### tidb_disable_txn_auto_retry + +- Scope: SESSION | GLOBAL +- Default: on +- This variable is used to set whether to disable the automatic retry of explicit transactions. The default value of `on` means that transactions will not automatically retry in TiDB and `COMMIT` statements might return errors that need to be handled in the application layer. + + Setting the value to `off` means that TiDB will automatically retry transactions, resulting in fewer errors from `COMMIT` statements. Be careful when making this change, because it might result in lost updates. + + This variable does not affect automatically committed implicit transactions and internally executed transactions in TiDB. The maximum retry count of these transactions is determined by the value of `tidb_retry_limit`. + + For more details, see [limits of retry](/optimistic-transaction.md#limits-of-retry). + +### tidb_distsql_scan_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 15 +- This variable is used to set the concurrency of the `scan` operation. +- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. +- For OLAP scenarios, the maximum value cannot exceed the number of CPU cores of all the TiKV nodes. + +### tidb_enable_cascades_planner + +- Scope: SESSION | GLOBAL +- Default value: OFF +- This variable enables the experimental cascades planner. + +### tidb_enable_chunk_rpc New in v4.0 + +- Scope: SESSION +- Default value: 1 +- This variable is used to control whether to enable the `Chunk` data encoding format in Coprocessor. + +### tidb_enable_fast_analyze + +- Scope: SESSION | GLOBAL +- Default value: 0, indicating not enabling the statistics fast `Analyze` feature. +- This variable is used to set whether to enable the statistics `Fast Analyze` feature. +- If the statistics `Fast Analyze` feature is enabled, TiDB randomly samples about 10,000 rows of data as statistics. When the data is distributed unevenly or the data size is small, the statistics accuracy is low. This might lead to a non-optimal execution plan, for example, selecting a wrong index. If the execution time of the regular `Analyze` statement is acceptable, it is recommended to disable the `Fast Analyze` feature. + +### tidb_enable_noop_functions + +- Scope: SESSION | GLOBAL +- Default value: OFF +- This variable allows TiDB to downgrade errors about setting the isolation level to an unsupported value. It is useful for compatibility purposes. + +```sql +tidb> set tx_isolation='serializable'; +ERROR 8048 (HY000): The isolation level 'serializable' is not supported. Set tidb_skip_isolation_level_check=1 to skip this error +tidb> set tidb_skip_isolation_level_check=1; +Query OK, 0 rows affected (0.00 sec) + +tidb> set tx_isolation='serializable'; +Query OK, 0 rows affected, 1 warning (0.00 sec) +``` + +### tidb_enable_stmt_summary New in v3.0.4 + +- Scope: SESSION | GLOBAL +- Default value: 0 +- This variable is used to enable or disable the statement summary feature. If enabled, SQL execution information like time consumption is recorded to the `information_schema.STATEMENTS_SUMMARY` table to identify and troubleshoot SQL performance issues. + +### tidb_enable_streaming + +- Scope: SERVER +- Default value: 0 +- This variable is used to set whether to enable streaming. + +### tidb_enable_table_partition + +- Scope: SESSION | GLOBAL +- Default value: "on" +- This variable is used to set whether to enable the `TABLE PARTITION` feature. + - `off` indicates disabling the `TABLE PARTITION` feature. In this case, the syntax that creates a partition table can be executed, but the table created is not a partitioned one. + - `on` indicates enabling the `TABLE PARTITION` feature for the supported partition types. Currently, it indicates enabling range partition, hash partition and range column partition with one single column. + - `auto` functions the same way as `on` does. + +- Currently, TiDB only supports range partition and hash partition. + +### tidb_enable_telemetry New in v4.0.2 version + +- Scope: GLOBAL +- Default value: 1 +- This variable dynamically controls whether the telemetry collection in TiDB is enabled. By setting the value to `0`, the telemetry collection is disabled. If the [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-new-in-v402) TiDB configuration item is set to `false` on all TiDB instances, the telemetry collection is always disabled and this system variable will not take effect. See [Telemetry](/telemetry.md) for details. + +### tidb_enable_window_function + +- Scope: SESSION | GLOBAL +- Default value: 1, indicating enabling the window function feature. +- This variable is used to control whether to enable the support for window functions. Note that window functions may use reserved keywords. This might cause SQL statements that could be executed normally cannot be parsed after upgrading TiDB. In this case, you can set `tidb_enable_window_function` to `0`. + +### tidb_expensive_query_time_threshold + +- Scope: SERVER +- Default value: 60 +- This variable is used to set the threshold value that determines whether to print expensive query logs. The unit is second. The difference between expensive query logs and slow query logs is: + - Slow logs are printed after the statement is executed. + - Expensive query logs print the statements that are being executed, with execution time exceeding the threshold value, and their related information. + +### tidb_force_priority + +- Scope: SESSION +- Default value: `NO_PRIORITY` +- This variable is used to change the default priority for statements executed on a TiDB server. A use case is to ensure that a particular user that is performing OLAP queries receives lower priority than users performing OLTP queries. +- You can set the value of this variable to `NO_PRIORITY`, `LOW_PRIORITY`, `DELAYED` or `HIGH_PRIORITY`. + +### tidb_general_log + +- Scope: SERVER +- Default value: 0 +- This variable is used to set whether to record all the SQL statements in the log. + +### tidb_hash_join_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 5 +- This variable is used to set the concurrency of the `hash join` algorithm. + +### tidb_hashagg_final_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 4 +- This variable is used to set the concurrency of executing the concurrent `hash aggregation` algorithm in the `final` phase. +- When the parameter of the aggregate function is not distinct, `HashAgg` is run concurrently and respectively in two phases - the `partial` phase and the `final` phase. + +### tidb_hashagg_partial_concurrency -### The working mechanism of system variables +- Scope: SESSION | GLOBAL +- Default value: 4 +- This variable is used to set the concurrency of executing the concurrent `hash aggregation` algorithm in the `partial` phase. +- When the parameter of the aggregate function is not distinct, `HashAgg` is run concurrently and respectively in two phases - the `partial` phase and the `final` phase. -* Session variables will only initialize their own values based on global variables when a session is created. Changing a global variable does not change the value of the system variable being used by the session that has already been created. +### tidb_index_join_batch_size + +- Scope: SESSION | GLOBAL +- Default value: 25000 +- This variable is used to set the batch size of the `index lookup join` operation. +- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. + +### tidb_index_lookup_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 4 +- This variable is used to set the concurrency of the `index lookup` operation. +- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. + +### tidb_index_lookup_join_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 4 +- This variable is used to set the concurrency of the `index lookup join` algorithm. + +### tidb_index_lookup_size + +- Scope: SESSION | GLOBAL +- Default value: 20000 +- This variable is used to set the batch size of the `index lookup` operation. +- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. + +### tidb_index_serial_scan_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 1 +- This variable is used to set the concurrency of the `serial scan` operation. +- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. + +### tidb_init_chunk_size + +- Scope: SESSION | GLOBAL +- Default value: 32 +- This variable is used to set the number of rows for the initial chunk during the execution process. + +### tidb_max_chunk_size + +- Scope: SESSION | GLOBAL +- Default value: 1024 +- This variable is used to set the maximum number of rows in a chunk during the execution process. + +### tidb_max_delta_schema_count New in v2.1.18 and v3.0.5 + +- Scope: GLOBAL +- Default value: 1024 +- This variable is used to set the maximum number of schema versions (the table IDs modified for corresponding versions) allowed to be cached. The value range is 100 ~ 16384. + +### tidb_mem_quota_hashjoin + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `HashJoin` operator. +- If the memory quota of the `HashJoin` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_mem_quota_indexlookupjoin + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `IndexLookupJoin` operator. +- If the memory quota of the `IndexLookupJoin` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_mem_quota_indexlookupreader + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `IndexLookupReader` operator. +- If the memory quota of the `IndexLookupReader` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_mem_quota_mergejoin + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `MergeJoin` operator. +- If the memory quota of the `MergeJoin` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_mem_quota_nestedloopapply + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `NestedLoopApply` operator. +- If the memory quota of the `NestedLoopApply` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_mem_quota_query + +- Scope: SESSION +- Default value: 1 GB +- This variable is used to set the threshold value of memory quota for a query. +- If the memory quota of a query during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. The initial value of this variable is configured by [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query). + +### tidb_mem_quota_sort + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `Sort` operator. +- If the memory quota of the `Sort` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_mem_quota_topn + +- Scope: SESSION +- Default value: 32 GB +- This variable is used to set the threshold value of memory quota for the `TopN` operator. +- If the memory quota of the `TopN` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. + +### tidb_opt_agg_push_down + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether the optimizer executes the optimization operation of pushing down the aggregate function to the position before Join. +- When the aggregate operation is slow in query, you can set the variable value to 1. + +### tidb_opt_correlation_exp_factor + +- Scope: SESSION | GLOBAL +- Default value: 1 +- When the method that estimates the number of rows based on column order correlation is not available, the heuristic estimation method is used. This variable is used to control the behavior of the heuristic method. + - When the value is 0, the heuristic method is not used. + - When the value is greater than 0: + - A larger value indicates that an index scan will probably be used in the heuristic method. + - A smaller value indicates that a table scan will probably be used in the heuristic method. + +### tidb_opt_correlation_threshold + +- Scope: SESSION | GLOBAL +- Default value: 0.9 +- This variable is used to set the threshold value that determines whether to enable estimating the row count by using column order correlation. If the order correlation between the current column and the `handle` column exceeds the threshold value, this method is enabled. + +### tidb_opt_distinct_agg_push_down + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether the optimizer executes the optimization operation of pushing down the aggregate function with `distinct` (such as `select count(distinct a) from t`) to Coprocessor. +- When the aggregate function with the `distinct` operation is slow in the query, you can set the variable value to `1`. + +In the following example, before `tidb_opt_distinct_agg_push_down` is enabled, TiDB needs to read all data from TiKV and execute `disctinct` on the TiDB side. After `tidb_opt_distinct_agg_push_down` is enabled, `distinct a` is pushed down to Coprocessor, and a `group by` column `test.t.a` is added to `HashAgg_5`. + +```sql +mysql> desc select count(distinct a) from test.t; ++-------------------------+----------+-----------+---------------+------------------------------------------+ +| id | estRows | task | access object | operator info | ++-------------------------+----------+-----------+---------------+------------------------------------------+ +| StreamAgg_6 | 1.00 | root | | funcs:count(distinct test.t.a)->Column#4 | +| └─TableReader_10 | 10000.00 | root | | data:TableFullScan_9 | +| └─TableFullScan_9 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++-------------------------+----------+-----------+---------------+------------------------------------------+ +3 rows in set (0.01 sec) + +mysql> set session tidb_opt_distinct_agg_push_down = 1; +Query OK, 0 rows affected (0.00 sec) + +mysql> desc select count(distinct a) from test.t; ++---------------------------+----------+-----------+---------------+------------------------------------------+ +| id | estRows | task | access object | operator info | ++---------------------------+----------+-----------+---------------+------------------------------------------+ +| HashAgg_8 | 1.00 | root | | funcs:count(distinct test.t.a)->Column#3 | +| └─TableReader_9 | 1.00 | root | | data:HashAgg_5 | +| └─HashAgg_5 | 1.00 | cop[tikv] | | group by:test.t.a, | +| └─TableFullScan_7 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | ++---------------------------+----------+-----------+---------------+------------------------------------------+ +4 rows in set (0.00 sec) +``` + +### tidb_opt_insubq_to_join_and_agg + +- Scope: SESSION | GLOBAL +- Default value: 1 +- This variable is used to set whether to enable the optimization rule that converts a subquery to join and aggregation. +- For example, after you enable this optimization rule, the subquery is converted as follows: ```sql - mysql> SELECT @@GLOBAL.autocommit; - +---------------------+ - | @@GLOBAL.autocommit | - +---------------------+ - | ON | - +---------------------+ - 1 row in set (0.00 sec) - - mysql> SELECT @@SESSION.autocommit; - +----------------------+ - | @@SESSION.autocommit | - +----------------------+ - | ON | - +----------------------+ - 1 row in set (0.00 sec) - - mysql> SET GLOBAL autocommit = OFF; - Query OK, 0 rows affected (0.01 sec) - - mysql> SELECT @@SESSION.autocommit; -- Session variables do not change, and the transactions in the session are executed in the form of autocommit. - +----------------------+ - | @@SESSION.autocommit | - +----------------------+ - | ON | - +----------------------+ - 1 row in set (0.00 sec) - - mysql> SELECT @@GLOBAL.autocommit; - +---------------------+ - | @@GLOBAL.autocommit | - +---------------------+ - | OFF | - +---------------------+ - 1 row in set (0.00 sec) - - mysql> exit - Bye - $ mysql -h127.0.0.1 -P4000 -uroot -D test - Welcome to the MySQL monitor. Commands end with ; or \g. - Your MySQL connection id is 3 - Server version: 5.7.25-TiDB-None MySQL Community Server (Apache License 2.0) - - Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved. - - Oracle is a registered trademark of Oracle Corporation and/or its - affiliates. Other names may be trademarks of their respective - owners. - - Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. - - mysql> SELECT @@SESSION.autocommit; -- The newly created session uses a new global variable. - +----------------------+ - | @@SESSION.autocommit | - +----------------------+ - | OFF | - +----------------------+ - 1 row in set (0.00 sec) + select * from t where t.a in (select aa from t1) ``` -## The fully supported MySQL system variables in TiDB + The subquery is converted to join as follows: -The following MySQL system variables are fully supported in TiDB and have the same behaviors as in MySQL. + ```sql + select * from t, (select aa from t1 group by aa) tmp_t where t.a = tmp_t.aa + ``` -| Name | Scope | Description | -| ---------------- | -------- | -------------------------------------------------- | -| autocommit | GLOBAL \| SESSION | whether automatically commit a transaction| -| sql_mode | GLOBAL \| SESSION | support some of the MySQL SQL modes| -| time_zone | GLOBAL \| SESSION | the time zone of the database | -| tx_isolation | GLOBAL \| SESSION | the isolation level of a transaction | -| hostname | NONE | the hostname of the TiDB server | -| max\_execution\_time | GLOBAL \| SESSION | the execution timeout for a statement, in milliseconds | -| innodb\_lock\_wait\_timeout | GLOBAL \| SESSION | the lock wait time for pessimistic transactions, in seconds | -| windowing\_use\_high\_precision | GLOBAL \| SESSION | whether to use the high precision mode when computing the window function. The default value is ON | -| sql\_select\_limit | GLOBAL \| SESSION | The maximum number of rows to return from the `SELECT` statements. The default value is `2^64 - 1`. | + If `t1` is limited to be `unique` and `not null` in the `aa` column. You can use the following statement, without aggregation. -> **Note:** -> -> Unlike in MySQL, the `max_execution_time` system variable currently works on all kinds of statements in TiDB, not only restricted to the `SELECT` statement. The precision of the timeout value is roughly 100ms. This means the statement might not be terminated in accurate milliseconds as you specify. + ```sql + select * from t, t1 where t.a=t1.a + ``` + +### tidb_opt_write_row_id + +- Scope: SESSION +- Default value: 0 +- This variable is used to set whether to allow `insert`, `replace` and `update` statements to operate on the column `_tidb_rowid`. It is not allowed by default. This variable can be used only when importing data with TiDB tools. + +### tidb_projection_concurrency + +- Scope: SESSION | GLOBAL +- Default value: 4 +- This variable is used to set the concurrency of the `Projection` operator. + +### tidb_query_log_max_len + +- Scope: SESSION +- Default value: 4096 (bytes) +- The maximum length of the SQL statement output. When the output length of a statement is larger than the `tidb_query-log-max-len` value, the statement is truncated to output. + +Usage example: + +```sql +set tidb_query_log_max_len = 20 +``` + +### tidb_record_plan_in_slow_log + +- Scope: SESSION +- Default value: `1` +- Controls whether to include the execution plan of slow queries in the slow log. + +### tidb_replica_read + +- Scope: SESSION | GLOBAL +- Possible values: leader, follower, leader-and-follower +- Default value: leader +- This variable enables [follower reads](/follower-read.md). + +### tidb_retry_limit + +- Scope: SESSION | GLOBAL +- Default value: 10 +- This variable is used to set the maximum number of the retries. When a transaction encounters retryable errors (such as transaction conflicts, very slow transaction commit, or table schema changes), this transaction is re-executed according to this variable. Note that setting `tidb_retry_limit` to `0` disables the automatic retry. + +### tidb_row_format_version + +- Scope: GLOBAL +- Default value: `2` +- Controls the format version of the newly saved data in the table. In TiDB v4.0, the [new storage row format](https://github.com/pingcap/tidb/blob/master/docs/design/2018-07-19-row-format.md) version `2` is used by default to save new data. +- If you upgrade from a TiDB version earlier than 4.0.0 to 4.0.0, the format version is not changed, and TiDB continues to use the old format of version `1` to write data to the table, which means that **only newly created clusters use the new data format by default**. +- Note that modifying this variable does not affect the old data that has been saved, but applies the corresponding version format only to the newly written data after modifying this variable. + +### tidb_scatter_region + +- Scope: GLOBAL +- Default value: 0 +- By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. + +### tidb_skip_utf8_check + +- Scope: SESSION | GLOBAL +- Default value: 0 +- This variable is used to set whether to skip UTF-8 validation. +- Validating UTF-8 characters affects the performance. When you are sure that the input characters are valid UTF-8 characters, you can set the variable value to 1. + +### tidb_slow_log_threshold + +- Scope: SESSION +- Default value: 300ms +- This variable is used to output the threshold value of the time consumed by the slow log. When the time consumed by a query is larger than this value, this query is considered as a slow log and its log is output to the slow query log. + +Usage example: + +```sql +SET tidb_slow_log_threshold = 200; +``` + +### tidb_slow_query_file + +- Scope: SESSION +- Default value: "" +- When `INFORMATION_SCHEMA.SLOW_QUERY` is queried, only the slow query log name set by `slow-query-file` in the configuration file is parsed. The default slow query log name is "tidb-slow.log". To parse other logs, set the `tidb_slow_query_file` session variable to a specific file path, and then query `INFORMATION_SCHEMA.SLOW_QUERY` to parse the slow query log based on the set file path. For details, see [Identify Slow Queries](/identify-slow-queries.md). + +### tidb_snapshot + +- Scope: SESSION +- Default value: "" +- This variable is used to set the time point at which the data is read by the session. For example, when you set the variable to "2017-11-11 20:20:20" or a TSO number like "400036290571534337", the current session reads the data of this moment. + +### tidb_txn_mode + +- Scope: SESSION | GLOBAL +- Default value: "pessimistic" +- This variable is used to set the transaction mode. TiDB 3.0 supports the pessimistic transactions. Since TiDB 3.0.8, the [pessimistic transaction mode](/pessimistic-transaction.md) is enabled by default. +- If you upgrade TiDB from v3.0.7 or earlier versions to v3.0.8 or later versions, the default transaction mode does not change. **Only the newly created clusters use the pessimistic transaction mode by default**. +- If this variable is set to "optimistic" or "", TiDB uses the [optimistic transaction mode](/optimistic-transaction.md). + +### tidb_wait_split_region_finish + +- Scope: SESSION +- Default value: 1, indicating returning the result after all Regions are scattered. +- It usually takes a long time to scatter Regions, which is determined by PD scheduling and TiKV loads. This variable is used to set whether to return the result to the client after all Regions are scattered completely when the `SPLIT REGION` statement is being executed. Value `0` indicates returning the value before finishing scattering all Regions. +- Note that when scattering Regions, the write and read performances for the Region that is being scattered might be affected. In batch-write or data importing scenarios, it is recommended to import data after Regions scattering is finished. + +### tidb_wait_split_region_timeout + +- Scope: SESSION +- Default value: 300 +- This variable is used to set the timeout for executing the `SPLIT REGION` statement. The unit is second. If a statement is not executed completely within the specified time value, a timeout error is returned. + +### time_zone + +- Scope: SESSION | GLOBAL +- Default value: SYSTEM +- This variable sets the sytem time zone. Values can be specified as either an offset such as '-8:00' or a named zone 'America/Los_Angeles'. + +### transaction_isolation + +- Scope: SESSION | GLOBAL +- Default value: REPEATABLE-READ +- This variable sets the transaction isolation. TiDB advertises `REPEATABLE-READ` for compatibility with MySQL, but the actual isolation level is Snapshot Isolation. See [transaction isolation levels](/transaction-isolation-levels.md) for further details. + +### tx_isolation + +This variable is an alias for _transaction_isolation_. + +### version + +- Scope: NONE +- Default value: 5.7.25-TiDB-(tidb version) +- This variable returns the MySQL version, followed by the TiDB version. For example '5.7.25-TiDB-v4.0.0-beta.2-716-g25e003253'. + +### version_comment + +- Scope: NONE +- Default value: (string) +- This variable returns additional details about the TiDB version. For example, 'TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible'. + +### wait_timeout + +- Scope: SESSION | GLOBAL +- Default value: 0 +- This variable controls the idle timeout of user sessions in seconds. A zero-value means unlimited. -## TiDB specific system variables +### windowing_use_high_precision -See [TiDB Specific System Variables](/tidb-specific-system-variables.md). +- Scope: SESSION | GLOBAL +- Default value: ON +- This variable controls whether to use the high precision mode when computing the window functions. \ No newline at end of file diff --git a/tidb-specific-system-variables.md b/tidb-specific-system-variables.md deleted file mode 100644 index 8978a7859fcc2..0000000000000 --- a/tidb-specific-system-variables.md +++ /dev/null @@ -1,595 +0,0 @@ ---- -title: TiDB Specific System Variables -summary: Use system variables specific to TiDB to optimize performance. -category: reference -aliases: ['/docs/dev/tidb-specific-system-variables/','/docs/dev/reference/configuration/tidb-server/tidb-specific-variables/'] ---- - -# TiDB Specific System Variables - -TiDB contains a number of system variables which are specific to its usage, and **do not** apply to MySQL. These variables start with a `tidb_` prefix, and can be tuned to optimize system performance. - -## System variables - -Variables can be set with the `SET` statement, for example: - -``` -set @@tidb_distsql_scan_concurrency = 10 -``` - -If you need to set the global variable, run: - -``` -set @@global.tidb_distsql_scan_concurrency = 10 -``` - -### tidb_snapshot - -- Scope: SESSION -- Default value: "" -- This variable is used to set the time point at which the data is read by the session. For example, when you set the variable to "2017-11-11 20:20:20" or a TSO number like "400036290571534337", the current session reads the data of this moment. - -### tidb_import_data - -- Scope: SESSION -- Default value: 0 -- This variable indicates whether to import data from the dump file currently. -- To speed up importing, the unique index constraint is not checked when the variable is set to 1. -- This variable is only used by Lightning. Do not modify it. - -### tidb_opt_agg_push_down - -- Scope: SESSION -- Default value: 0 -- This variable is used to set whether the optimizer executes the optimization operation of pushing down the aggregate function to the position before Join. -- When the aggregate operation is slow in query, you can set the variable value to 1. - -### tidb_opt_distinct_agg_push_down - -- Scope: SESSION -- Default value: 0 -- This variable is used to set whether the optimizer executes the optimization operation of pushing down the aggregate function with `distinct` (such as `select count(distinct a) from t`) to Coprocessor. -- When the aggregate function with the `distinct` operation is slow in the query, you can set the variable value to `1`. - -In the following example, before `tidb_opt_distinct_agg_push_down` is enabled, TiDB needs to read all data from TiKV and execute `disctinct` on the TiDB side. After `tidb_opt_distinct_agg_push_down` is enabled, `distinct a` is pushed down to Coprocessor, and a `group by` column `test.t.a` is added to `HashAgg_5`. - -```sql -mysql> desc select count(distinct a) from test.t; -+-------------------------+----------+-----------+---------------+------------------------------------------+ -| id | estRows | task | access object | operator info | -+-------------------------+----------+-----------+---------------+------------------------------------------+ -| StreamAgg_6 | 1.00 | root | | funcs:count(distinct test.t.a)->Column#4 | -| └─TableReader_10 | 10000.00 | root | | data:TableFullScan_9 | -| └─TableFullScan_9 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | -+-------------------------+----------+-----------+---------------+------------------------------------------+ -3 rows in set (0.01 sec) - -mysql> set session tidb_opt_distinct_agg_push_down = 1; -Query OK, 0 rows affected (0.00 sec) - -mysql> desc select count(distinct a) from test.t; -+---------------------------+----------+-----------+---------------+------------------------------------------+ -| id | estRows | task | access object | operator info | -+---------------------------+----------+-----------+---------------+------------------------------------------+ -| HashAgg_8 | 1.00 | root | | funcs:count(distinct test.t.a)->Column#3 | -| └─TableReader_9 | 1.00 | root | | data:HashAgg_5 | -| └─HashAgg_5 | 1.00 | cop[tikv] | | group by:test.t.a, | -| └─TableFullScan_7 | 10000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo | -+---------------------------+----------+-----------+---------------+------------------------------------------+ -4 rows in set (0.00 sec) -``` - -### tidb_auto_analyze_ratio - -- Scope: GLOBAL -- Default value: 0.5 -- This variable is used to set the threshold when TiDB automatically executes [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) in a background thread to update table statistics. For example, a value of 0.5 means that auto-analyze is triggered when greater than 50% of the rows in a table have been modified. Auto-analyze can be restricted to only execute during certain hours of the day by specifying `tidb_auto_analyze_start_time` and `tidb_auto_analyze_end_time`. - -> **Note:** -> -> Only when the `run-auto-analyze` option is enabled in the starting configuration file of TiDB, the `auto_analyze` feature can be triggered. - -### tidb_auto_analyze_start_time - -- Scope: GLOBAL -- Default value: 00:00 +0000 -- This variable is used to restrict the time window that the automatic update of statistics is permitted. For example, to only allow automatic statistics updates between 1AM and 3AM, set `tidb_auto_analyze_start_time='01:00 +0000'` and `tidb_auto_analyze_end_time='03:00 +0000'`. - -### tidb_auto_analyze_end_time - -- Scope: GLOBAL -- Default value: 23:59 +0000 -- This variable is used to restrict the time window that the automatic update of statistics is permitted. For example, to only allow automatic statistics updates between 1AM and 3AM, set `tidb_auto_analyze_start_time='01:00 +0000'` and `tidb_auto_analyze_end_time='03:00 +0000'`. - -### tidb_build_stats_concurrency - -- Scope: SESSION -- Default value: 4 -- This variable is used to set the concurrency of executing the `ANALYZE` statement. -- When the variable is set to a larger value, the execution performance of other queries is affected. - -### tidb_checksum_table_concurrency - -- Scope: SESSION -- Default value: 4 -- This variable is used to set the scan index concurrency of executing the `ADMIN CHECKSUM TABLE` statement. -- When the variable is set to a larger value, the execution performance of other queries is affected. - -### tidb_current_ts - -- Scope: SESSION -- Default value: 0 -- This variable is read-only. It is used to obtain the timestamp of the current transaction. - -### tidb_config - -- Scope: SESSION -- Default value: "" -- This variable is read-only. It is used to obtain the configuration information of the current TiDB server. - -### tidb_distsql_scan_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 15 -- This variable is used to set the concurrency of the `scan` operation. -- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. -- For OLAP scenarios, the maximum value cannot exceed the number of CPU cores of all the TiKV nodes. - -### tidb_index_lookup_size - -- Scope: SESSION | GLOBAL -- Default value: 20000 -- This variable is used to set the batch size of the `index lookup` operation. -- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. - -### tidb_index_lookup_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 4 -- This variable is used to set the concurrency of the `index lookup` operation. -- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. - -### tidb_index_lookup_join_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 4 -- This variable is used to set the concurrency of the `index lookup join` algorithm. - -### tidb_hash_join_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 5 -- This variable is used to set the concurrency of the `hash join` algorithm. - -### tidb_index_serial_scan_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 1 -- This variable is used to set the concurrency of the `serial scan` operation. -- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. - -### tidb_projection_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 4 -- This variable is used to set the concurrency of the `Projection` operator. - -### tidb_hashagg_partial_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 4 -- This variable is used to set the concurrency of executing the concurrent `hash aggregation` algorithm in the `partial` phase. -- When the parameter of the aggregate function is not distinct, `HashAgg` is run concurrently and respectively in two phases - the `partial` phase and the `final` phase. - -### tidb_hashagg_final_concurrency - -- Scope: SESSION | GLOBAL -- Default value: 4 -- This variable is used to set the concurrency of executing the concurrent `hash aggregation` algorithm in the `final` phase. -- When the parameter of the aggregate function is not distinct, `HashAgg` is run concurrently and respectively in two phases - the `partial` phase and the `final` phase. - -### tidb_index_join_batch_size - -- Scope: SESSION | GLOBAL -- Default value: 25000 -- This variable is used to set the batch size of the `index lookup join` operation. -- Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. - -### tidb_skip_utf8_check - -- Scope: SESSION | GLOBAL -- Default value: 0 -- This variable is used to set whether to skip UTF-8 validation. -- Validating UTF-8 characters affects the performance. When you are sure that the input characters are valid UTF-8 characters, you can set the variable value to 1. - -### tidb_init_chunk_size - -- Scope: SESSION | GLOBAL -- Default value: 32 -- This variable is used to set the number of rows for the initial chunk during the execution process. - -### tidb_max_chunk_size - -- Scope: SESSION | GLOBAL -- Default value: 1024 -- This variable is used to set the maximum number of rows in a chunk during the execution process. - -### tidb_mem_quota_query - -- Scope: SESSION -- Default value: 1 GB -- This variable is used to set the threshold value of memory quota for a query. -- If the memory quota of a query during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. The initial value of this variable is configured by [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query). - -### tidb_mem_quota_hashjoin - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `HashJoin` operator. -- If the memory quota of the `HashJoin` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_mem_quota_mergejoin - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `MergeJoin` operator. -- If the memory quota of the `MergeJoin` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_mem_quota_sort - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `Sort` operator. -- If the memory quota of the `Sort` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_mem_quota_topn - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `TopN` operator. -- If the memory quota of the `TopN` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_mem_quota_indexlookupreader - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `IndexLookupReader` operator. -- If the memory quota of the `IndexLookupReader` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_mem_quota_indexlookupjoin - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `IndexLookupJoin` operator. -- If the memory quota of the `IndexLookupJoin` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_mem_quota_nestedloopapply - -- Scope: SESSION -- Default value: 32 GB -- This variable is used to set the threshold value of memory quota for the `NestedLoopApply` operator. -- If the memory quota of the `NestedLoopApply` operator during execution exceeds the threshold value, TiDB performs the operation designated by the OOMAction option in the configuration file. - -### tidb_general_log - -- Scope: SERVER -- Default value: 0 -- This variable is used to set whether to record all the SQL statements in the log. - -### tidb_enable_streaming - -- Scope: SERVER -- Default value: 0 -- This variable is used to set whether to enable Streaming. - -### tidb_retry_limit - -- Scope: SESSION | GLOBAL -- Default value: 10 -- This variable is used to set the maximum number of the retries. When a transaction encounters retryable errors (such as transaction conflicts, very slow transaction commit, or table schema changes), this transaction is re-executed according to this variable. Note that setting `tidb_retry_limit` to `0` disables the automatic retry. - -### tidb_disable_txn_auto_retry - -- Scope: SESSION | GLOBAL -- Default: on -- This variable is used to set whether to disable the automatic retry of explicit transactions. The default value of `on` means that transactions will not automatically retry in TiDB and `COMMIT` statements might return errors that need to be handled in the application layer. - - Setting the value to `off` means that TiDB will automatically retry transactions, resulting in fewer errors from `COMMIT` statements. Be careful when making this change, because it might result in lost updates. - - This variable does not affect automatically committed implicit transactions and internally executed transactions in TiDB. The maximum retry count of these transactions is determined by the value of `tidb_retry_limit`. - - For more details, see [limits of retry](/optimistic-transaction.md#limits-of-retry). - -### tidb_backoff_weight - -- Scope: SESSION | GLOBAL -- Default value: 2 -- This variable is used to increase the weight of the maximum time of TiDB `backoff`, that is, the maximum retry time for sending a retry request when an internal network or other component (TiKV, PD) failure is encountered. This variable can be used to adjust the maximum retry time and the minimum value is 1. - - For example, the base timeout for TiDB to take TSO from PD is 15 seconds. When `tidb_backoff_weight = 2`, the maximum timeout for taking TSO is: *base time \* 2 = 30 seconds*. - - In the case of a poor network environment, appropriately increasing the value of this variable can effectively alleviate error reporting to the application end caused by timeout. If the application end wants to receive the error information more quickly, minimize the value of this variable. - -### tidb_enable_table_partition - -- Scope: SESSION | GLOBAL -- Default value: "on" -- This variable is used to set whether to enable the `TABLE PARTITION` feature. - - `off` indicates disabling the `TABLE PARTITION` feature. In this case, the syntax that creates a partition table can be executed, but the table created is not a partitioned one. - - `on` indicates enabling the `TABLE PARTITION` feature for the supported partition types. Currently, it indicates enabling range partition, hash partition and range column partition with one single column. - - `auto` functions the same way as `on` does. - -- Currently, TiDB only supports range partition and hash partition. - -### tidb_backoff_lock_fast - -- Scope: SESSION | GLOBAL -- Default value: 100 -- This variable is used to set the `backoff` time when the read request meets a lock. - -### tidb_ddl_reorg_worker_cnt - -- Scope: GLOBAL -- Default value: 4 -- This variable is used to set the concurrency of the DDL operation in the `re-organize` phase. - -### tidb_ddl_reorg_batch_size - -- Scope: GLOBAL -- Default value: 256 -- This variable is used to set the batch size during the `re-organize` phase of the DDL operation. For example, when TiDB executes the `ADD INDEX` operation, the index data needs to backfilled by `tidb_ddl_reorg_worker_cnt` (the number) concurrent workers. Each worker backfills the index data in batches. - - If many updating operations such as `UPDATE` and `REPLACE` exist during the `ADD INDEX` operation, a larger batch size indicates a larger probability of transaction conflicts. In this case, you need to adjust the batch size to a smaller value. The minimum value is 32. - - If the transaction conflict does not exist, you can set the batch size to a large value. The maximum value is 10240. This can increase the speed of the backfilling data, but the write pressure on TiKV also becomes higher. - -### tidb_ddl_reorg_priority - -- Scope: SESSION | GLOBAL -- Default value: `PRIORITY_LOW` -- This variable is used to set the priority of executing the `ADD INDEX` operation in the `re-organize` phase. -- You can set the value of this variable to `PRIORITY_LOW`, `PRIORITY_NORMAL` or `PRIORITY_HIGH`. - -### tidb_ddl_error_count_limit - -- Scope: GLOBAL -- Default value: 512 -- This variable is used to set the number of retries when the DDL operation fails. When the number of retries exceeds the parameter value, the wrong DDL operation is canceled. - -### tidb_max_delta_schema_count New in v2.1.18 and v3.0.5 - -- Scope: GLOBAL -- Default value: 1024 -- This variable is used to set the maximum number of schema versions (the table IDs modified for corresponding versions) allowed to be cached. The value range is 100 ~ 16384. - -### tidb_force_priority - -- Scope: SESSION -- Default value: `NO_PRIORITY` -- This variable is used to change the default priority for statements executed on a TiDB server. A use case is to ensure that a particular user that is performing OLAP queries receives lower priority than users performing OLTP queries. -- You can set the value of this variable to `NO_PRIORITY`, `LOW_PRIORITY`, `DELAYED` or `HIGH_PRIORITY`. - -### tidb_opt_write_row_id - -- Scope: SESSION -- Default value: 0 -- This variable is used to set whether to allow `insert`, `replace` and `update` statements to operate on the column `_tidb_rowid`. It is not allowed by default. This variable can be used only when importing data with TiDB tools. - -## SHARD_ROW_ID_BITS - -For the tables with non-integer PK or without PK, TiDB uses an implicit auto-increment ROW ID. When a large number of `INSERT` operations occur, the data is written into a single Region, causing a write hot spot. - -To mitigate the hot spot issue, you can configure `SHARD_ROW_ID_BITS`. The ROW ID is scattered and the data is written into multiple different Regions. But setting an overlarge value might lead to an excessively large number of RPC requests, which increases the CPU and network overheads. - -- `SHARD_ROW_ID_BITS = 4` indicates 16 shards -- `SHARD_ROW_ID_BITS = 6` indicates 64 shards -- `SHARD_ROW_ID_BITS = 0` indicates the default 1 shard - -Usage of statements: - -- `CREATE TABLE`: `CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;` -- `ALTER TABLE`: `ALTER TABLE t SHARD_ROW_ID_BITS = 4;` - -### tidb_row_format_version - -- Scope: GLOBAL -- Default value: `2` -- Controls the format version of the newly saved data in the table. In TiDB v4.0, the [new storage row format](https://github.com/pingcap/tidb/blob/master/docs/design/2018-07-19-row-format.md) version `2` is used by default to save new data. -- If you upgrade from a TiDB version earlier than 4.0.0 to 4.0.0, the format version is not changed, and TiDB continues to use the old format of version `1` to write data to the table, which means that **only newly created clusters use the new data format by default**. -- Note that modifying this variable does not affect the old data that has been saved, but applies the corresponding version format only to the newly written data after modifying this variable. - -### tidb_record_plan_in_slow_log - -- Scope: SESSION -- Default value: `1` -- Controls whether to include the execution plan of slow queries in the slow log. - -## tidb_slow_log_threshold - -- Scope: SESSION -- Default value: 300ms -- This variable is used to output the threshold value of the time consumed by the slow log. When the time consumed by a query is larger than this value, this query is considered as a slow log and its log is output to the slow query log. - -Usage example: - -```sql -set tidb_slow_log_threshold = 200 -``` - -## tidb_query_log_max_len - -- Scope: SESSION -- Default value: 4096 (bytes) -- The maximum length of the SQL statement output. When the output length of a statement is larger than the `tidb_query-log-max-len` value, the statement is truncated to output. - -Usage example: - -```sql -set tidb_query_log_max_len = 20 -``` - -### tidb_txn_mode - -- Scope: SESSION | GLOBAL -- Default value: "pessimistic" -- This variable is used to set the transaction mode. TiDB 3.0 supports the pessimistic transactions. Since TiDB 3.0.8, the [pessimistic transaction mode](/pessimistic-transaction.md) is enabled by default. -- If you upgrade TiDB from v3.0.7 or earlier versions to v3.0.8 or later versions, the default transaction mode does not change. **Only the newly created clusters use the pessimistic transaction mode by default**. -- If this variable is set to "optimistic" or "", TiDB uses the [optimistic transaction mode](/optimistic-transaction.md). - -### tidb_constraint_check_in_place - -- Scope: SESSION | GLOBAL -- Default value: 0 -- TiDB supports the optimistic transaction model. This means that conflict check (unique key check) is performed when the transaction is committed. This variable is used to set whether to do a unique key check each time a row of data is written. -- If this variable is enabled, the performance might be affected in a scenario where a large batch of data is written. For example: - - - When this variable is disabled: - - ```sql - tidb >create table t (i int key) - tidb >insert into t values (1); - tidb >begin - tidb >insert into t values (1); - Query OK, 1 row affected - tidb >commit; -- Check only when a transaction is committed. - ERROR 1062 : Duplicate entry '1' for key 'PRIMARY' - ``` - - - After this variable is enabled: - - ```sql - tidb >set @@tidb_constraint_check_in_place=1 - tidb >begin - tidb >insert into t values (1); - ERROR 1062 : Duplicate entry '1' for key 'PRIMARY' - ``` - -### tidb_check_mb4_value_in_utf8 - -- Scope: SERVER -- Default value: 1, indicating check the validity of UTF-8 data. This default behavior is compatible with MySQL. -- This variable is used to set whether to check the validity of UTF-8 data. -- To upgrade an earlier version (TiDB v2.1.1 or earlier), you may need to disable this option. Otherwise, you can successfully write invalid strings in an earlier version but fail to do this in a later version, because there is no data validity check in the earlier version. For details, see [FAQs After Upgrade](/faq/upgrade-faq.md). - -### tidb_opt_insubq_to_join_and_agg - -- Scope: SESSION | GLOBAL -- Default value: 1 -- This variable is used to set whether to enable the optimization rule that converts a subquery to join and aggregation. -- For example, after you enable this optimization rule, the subquery is converted as follows: - - ```sql - select * from t where t.a in (select aa from t1) - ``` - - The subquery is converted to join as follows: - - ```sql - select * from t, (select aa from t1 group by aa) tmp_t where t.a = tmp_t.aa - ``` - - If `t1` is limited to be `unique` and `not null` in the `aa` column. You can use the following statement, without aggregation. - - ```sql - select * from t, t1 where t.a=t1.a - ``` - -### tidb_opt_correlation_threshold - -- Scope: SESSION | GLOBAL -- Default value: 0.9 -- This variable is used to set the threshold value that determines whether to enable estimating the row count by using column order correlation. If the order correlation between the current column and the `handle` column exceeds the threshold value, this method is enabled. - -### tidb_opt_correlation_exp_factor - -- Scope: SESSION | GLOBAL -- Default value: 1 -- When the method that estimates the number of rows based on column order correlation is not available, the heuristic estimation method is used. This variable is used to control the behavior of the heuristic method. - - When the value is 0, the heuristic method is not used. - - When the value is greater than 0: - - A larger value indicates that an index scan will probably be used in the heuristic method. - - A smaller value indicates that a table scan will probably be used in the heuristic method. - -### tidb_enable_window_function - -- Scope: SESSION | GLOBAL -- Default value: 1, indicating enabling the window function feature. -- This variable is used to control whether to enable the support for window functions. Note that window functions may use reserved keywords. This might cause SQL statements that could be executed normally cannot be parsed after upgrading TiDB. In this case, you can set `tidb_enable_window_function` to `0`. - -### tidb_slow_query_file - -- Scope: SESSION -- Default value: "" -- When `INFORMATION_SCHEMA.SLOW_QUERY` is queried, only the slow query log name set by `slow-query-file` in the configuration file is parsed. The default slow query log name is "tidb-slow.log". To parse other logs, set the `tidb_slow_query_file` session variable to a specific file path, and then query `INFORMATION_SCHEMA.SLOW_QUERY` to parse the slow query log based on the set file path. For details, see [Identify Slow Queries](/identify-slow-queries.md). - -### tidb_enable_fast_analyze - -- Scope: SESSION | GLOBAL -- Default value: 0, indicating not enabling the statistics fast `Analyze` feature. -- This variable is used to set whether to enable the statistics `Fast Analyze` feature. -- If the statistics `Fast Analyze` feature is enabled, TiDB randomly samples about 10,000 rows of data as statistics. When the data is distributed unevenly or the data size is small, the statistics accuracy is low. This might lead to a non-optimal execution plan, for example, selecting a wrong index. If the execution time of the regular `Analyze` statement is acceptable, it is recommended to disable the `Fast Analyze` feature. - -### tidb_expensive_query_time_threshold - -- Scope: SERVER -- Default value: 60 -- This variable is used to set the threshold value that determines whether to print expensive query logs. The unit is second. The difference between expensive query logs and slow query logs is: - - Slow logs are printed after the statement is executed. - - Expensive query logs print the statements that are being executed, with execution time exceeding the threshold value, and their related information. - -### tidb_wait_split_region_finish - -- Scope: SESSION -- Default value: 1, indicating returning the result after all Regions are scattered. -- It usually takes a long time to scatter Regions, which is determined by PD scheduling and TiKV loads. This variable is used to set whether to return the result to the client after all Regions are scattered completely when the `SPLIT REGION` statement is being executed. Value `0` indicates returning the value before finishing scattering all Regions. -- Note that when scattering Regions, the write and read performances for the Region that is being scattered might be affected. In batch-write or data importing scenarios, it is recommended to import data after Regions scattering is finished. - -### tidb_wait_split_region_timeout - -- Scope: SESSION -- Default value: 300 -- This variable is used to set the timeout for executing the `SPLIT REGION` statement. The unit is second. If a statement is not executed completely within the specified time value, a timeout error is returned. - -### tidb_scatter_region - -- Scope: GLOBAL -- Default value: 0 -- By default, Regions are split for a new table when it is being created in TiDB. After this variable is enabled, the newly split Regions are scattered immediately during the execution of the `CREATE TABLE` statement. This applies to the scenario where data need to be written in batches right after the tables are created in batches, because the newly split Regions can be scattered in TiKV beforehand and do not have to wait to be scheduled by PD. To ensure the continuous stability of writing data in batches, the `CREATE TABLE` statement returns success only after the Regions are successfully scattered. This makes the statement's execution time multiple times longer than that when you disable this variable. - -### tidb_allow_remove_auto_inc New in v2.1.18 and v3.0.4 - -- Scope: SESSION -- Default value: 0 -- This variable is used to set whether the `AUTO_INCREMENT` property of a column is allowed to be removed by executing `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` statements. It is not allowed by default. - -### tidb_enable_stmt_summary New in v3.0.4 - -- Scope: SESSION | GLOBAL -- Default value: 0 -- This variable is used to enable or disable the statement summary feature. If enabled, SQL execution information like time consumption is recorded to the `performance_schema.events_statements_summary_by_digest` table to identify and troubleshoot SQL performance issues. - -### tidb_enable_chunk_rpc New in v4.0 - -- Scope: SESSION -- Default value: 1 -- This variable is used to control whether to enable the `Chunk` data encoding format in Coprocessor. - -### last_plan_from_cache New in v4.0 - -- Scope: SESSION -- Default value: 0 -- This variable is used to show whether the execution plan used in the previous `execute` statement is taken directly from the plan cache. - -### tidb_allow_batch_cop New in v4.0 version - -- Scope: SESSION | GLOBAL -- Default value: 0 -- This variable is used to control how TiDB sends a coprocessor request to TiFlash. It has the following values: - - * `0`: Never send requests in batches - * `1`: Aggregation and join requests are sent in batches - * `2`: All coprocessor requests are sent in batches - -### tidb_enable_telemetry New in v4.0.2 version - -- Scope: GLOBAL -- Default value: 1 -- This variable dynamically controls whether the telemetry collection in TiDB is enabled. By setting the value to `0`, the telemetry collection is disabled. If the [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-new-in-v402) TiDB configuration item is set to `false` on all TiDB instances, the telemetry collection is always disabled and this system variable will not take effect. See [Telemetry](/telemetry.md) for details. From cd8832ee2900ea859403d813e7a9f51040ddcb65 Mon Sep 17 00:00:00 2001 From: Nullnotnil Date: Sun, 5 Jul 2020 09:39:13 -0600 Subject: [PATCH 02/11] Fix CI (extra new lines) --- system-variables.md | 1 - 1 file changed, 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index 161eaccb59d34..dea57411c1752 100644 --- a/system-variables.md +++ b/system-variables.md @@ -116,7 +116,6 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Default value: 00:00 +0000 - This variable is used to restrict the time window that the automatic update of statistics is permitted. For example, to only allow automatic statistics updates between 1AM and 3AM, set `tidb_auto_analyze_start_time='01:00 +0000'` and `tidb_auto_analyze_end_time='03:00 +0000'`. - ### tidb_backoff_lock_fast - Scope: SESSION | GLOBAL From 843296b31c7a3c27e0cb54052b4c0c7cd8454ec4 Mon Sep 17 00:00:00 2001 From: Nullnotnil Date: Sun, 5 Jul 2020 10:04:35 -0600 Subject: [PATCH 03/11] Fix links to go to new location --- TOC.md | 4 +--- best-practices/high-concurrency-best-practices.md | 2 +- dashboard/dashboard-overview.md | 2 +- dashboard/dashboard-slow-query.md | 2 +- faq/tidb-faq.md | 6 +++--- identify-expensive-queries.md | 2 +- pessimistic-transaction.md | 2 +- releases/release-2.1-ga.md | 8 ++++---- releases/release-2.1.18.md | 2 +- sql-statements/sql-statement-create-index.md | 2 +- sql-statements/sql-statement-create-table.md | 2 +- sql-statements/sql-statement-show-variables.md | 6 +++++- sql-statements/sql-statement-split-region.md | 9 +++------ telemetry.md | 2 +- tidb-best-practices.md | 10 +++++----- tidb-configuration-file.md | 6 +++--- tiflash/tune-tiflash-performance.md | 8 ++++---- transaction-overview.md | 2 +- 18 files changed, 38 insertions(+), 39 deletions(-) diff --git a/TOC.md b/TOC.md index 81c2d16e9f1e4..523b82069dab5 100644 --- a/TOC.md +++ b/TOC.md @@ -408,9 +408,7 @@ + [tikv-server](/tikv-configuration-file.md) + [tiflash-server](/tiflash/tiflash-configuration.md) + [pd-server](/pd-configuration-file.md) - + System Variables - + [MySQL System Variables](/system-variables.md) - + [TiDB Specific System Variables](/tidb-specific-system-variables.md) + + [System Variables](/system-variables.md) + Storage Engines + TiFlash + [Overview](/tiflash/tiflash-overview.md) diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index be0dca2d4aaab..47af08cbf9e4e 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -181,7 +181,7 @@ In this case, the table is simple. In other cases, you might also need to consid **Problem one:** -If a table does not have a primary key, or the primary key is not the `Int` type and you do not want to generate a randomly distributed primary key ID, TiDB provides an implicit `_tidb_rowid` column as the row ID. Generally, when you do not use the `SHARD_ROW_ID_BITS` parameter, the values of the `_tidb_rowid` column are also monotonically increasing, which might causes hotspots too. Refer to [`SHARD_ROW_ID_BITS` description](/tidb-specific-system-variables.md#shard_row_id_bits) for more details. +If a table does not have a primary key, or the primary key is not the `Int` type and you do not want to generate a randomly distributed primary key ID, TiDB provides an implicit `_tidb_rowid` column as the row ID. Generally, when you do not use the `SHARD_ROW_ID_BITS` parameter, the values of the `_tidb_rowid` column are also monotonically increasing, which might causes hotspots too. Refer to [`SHARD_ROW_ID_BITS`](/sql-statements/sql-statement-create-table.md#shard_row_id_bits) for more details. To avoid the hotspot problem in this situation, you can use `SHARD_ROW_ID_BITS` and `PRE_SPLIT_REGIONS` when creating a table. For more details about `PRE_SPLIT_REGIONS`, refer to [Pre-split Regions](/sql-statements/sql-statement-split-region.md#pre_split_regions). diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md index 2d70f997cdada..f6899b14a68c7 100644 --- a/dashboard/dashboard-overview.md +++ b/dashboard/dashboard-overview.md @@ -60,7 +60,7 @@ By default, this area shows the latest 10 slow queries in the entire cluster ove ![Recent slow queries](/media/dashboard/dashboard-overview-slow-query.png) -By default, the SQL query that is executed longer than 300 milliseconds is counted as a slow query and displayed on the table. You can change this threshold by modifying the [tidb_slow_log_threshold](/tidb-specific-system-variables.md#tidb_slow_log_threshold) variable or the [slow-threshold](/tidb-configuration-file.md#slow-threshold) TiDB parameter. +By default, the SQL query that is executed longer than 300 milliseconds is counted as a slow query and displayed on the table. You can change this threshold by modifying the [tidb_slow_log_threshold](/system-variables.md#tidb_slow_log_threshold) variable or the [slow-threshold](/tidb-configuration-file.md#slow-threshold) TiDB parameter. The content displayed in this area is consistent with the more detailed [Slow Queries Page](/dashboard/dashboard-slow-query.md). You can click the **Recent Slow Queries** title to view the complete list. For details of the columns in this table, see this [Slow Queries Page](/dashboard/dashboard-slow-query.md). diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index 734d660f99026..b8bb28bff459a 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -9,7 +9,7 @@ aliases: ['/docs/dev/dashboard/dashboard-slow-query/'] On the Slow Queries page of TiDB Dashboard, you can search and view all slow queries in the cluster. -By default, SQL queries with an execution time of more than 300 milliseconds are considered as slow queries. These queries are recorded in the [slow query logs](/identify-slow-queries.md) and can be searched via TiDB Dashboard. You can adjust the threshold of slow queries through the [`tidb_slow_log_threshold`](/tidb-specific-system-variables.md#tidb_slow_log_threshold) session variable or the [`slow-threshold`](/tidb-configuration-file.md#slow-threshold) TiDB parameter. +By default, SQL queries with an execution time of more than 300 milliseconds are considered as slow queries. These queries are recorded in the [slow query logs](/identify-slow-queries.md) and can be searched via TiDB Dashboard. You can adjust the threshold of slow queries through the [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) session variable or the [`slow-threshold`](/tidb-configuration-file.md#slow-threshold) TiDB parameter. > **Note:** > diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index 06a5bd226c55a..36f1b57e8521f 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -551,7 +551,7 @@ When TiDB is executing a SQL statement, the query will be `EXPENSIVE_QUERY` if e #### How to control or change the execution priority of SQL commits? -TiDB supports changing the priority on a [per-session](/tidb-specific-system-variables.md#tidb_force_priority), [global](/tidb-configuration-file.md#force-priority) or individual statement basis. Priority has the following meaning: +TiDB supports changing the priority on a [per-session](/system-variables.md#tidb_force_priority), [global](/tidb-configuration-file.md#force-priority) or individual statement basis. Priority has the following meaning: - `HIGH_PRIORITY`: this statement has a high priority, that is, TiDB gives priority to this statement and executes it first. @@ -1014,7 +1014,7 @@ See [Introduction to Statistics](/statistics.md). #### How to optimize `select count(1)`? -The `count(1)` statement counts the total number of rows in a table. Improving the degree of concurrency can significantly improve the speed. To modify the concurrency, refer to the [document](/tidb-specific-system-variables.md#tidb_distsql_scan_concurrency). But it also depends on the CPU and I/O resources. TiDB accesses TiKV in every query. When the amount of data is small, all MySQL is in memory, and TiDB needs to conduct a network access. +The `count(1)` statement counts the total number of rows in a table. Improving the degree of concurrency can significantly improve the speed. To modify the concurrency, refer to the [document](/system-variables.md#tidb_distsql_scan_concurrency). But it also depends on the CPU and I/O resources. TiDB accesses TiKV in every query. When the amount of data is small, all MySQL is in memory, and TiDB needs to conduct a network access. Recommendations: @@ -1079,7 +1079,7 @@ See [The TiDB Command Options](/command-line-flags-for-tidb-configuration.md). #### How to scatter the hotspots? -In TiDB, data is divided into Regions for management. Generally, the TiDB hotspot means the Read/Write hotspot in a Region. In TiDB, for the table whose primary key (PK) is not an integer or which has no PK, you can properly break Regions by configuring `SHARD_ROW_ID_BITS` to scatter the Region hotspots. For details, see the introduction of `SHARD_ROW_ID_BITS` in [TiDB Specific System Variables and Syntax](/tidb-specific-system-variables.md#shard_row_id_bits). +In TiDB, data is divided into Regions for management. Generally, the TiDB hotspot means the Read/Write hotspot in a Region. In TiDB, for the table whose primary key (PK) is not an integer or which has no PK, you can properly break Regions by configuring `SHARD_ROW_ID_BITS` to scatter the Region hotspots. For details, see the introduction of `SHARD_ROW_ID_BITS` in [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md#shard_row_id_bits). ### TiKV diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index d24450ec70c55..656f49e898394 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -6,7 +6,7 @@ aliases: ['/docs/dev/identify-expensive-queries/','/docs/dev/how-to/maintain/ide # Identify Expensive Queries -TiDB allows you to identify expensive queries during SQL execution, so you can diagnose and improve the performance of SQL execution. Specifically, TiDB prints the information about statements whose execution time exceeds [`tidb_expensive_query_time_threshold`](/tidb-specific-system-variables.md#tidb_expensive_query_time_threshold) (60 seconds by default) or memory usage exceeds [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) (1 GB by default) to the [tidb-server log file](/tidb-configuration-file.md#logfile) ("tidb.log" by default). +TiDB allows you to identify expensive queries during SQL execution, so you can diagnose and improve the performance of SQL execution. Specifically, TiDB prints the information about statements whose execution time exceeds [`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) (60 seconds by default) or memory usage exceeds [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) (1 GB by default) to the [tidb-server log file](/tidb-configuration-file.md#logfile) ("tidb.log" by default). > **Note:** > diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index bb51f7a81b628..9b53a6070ee02 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -15,7 +15,7 @@ To make the usage of TiDB closer to traditional databases and reduce the cost of ## Switch transaction mode -You can set the transaction mode by configuring the [`tidb_txn_mode`](/tidb-specific-system-variables.md#tidb_txn_mode) system variable. The following command sets all explicit transactions (that is, non-autocommit transactions) executed by newly created sessions in the cluster to the pessimistic transaction mode: +You can set the transaction mode by configuring the [`tidb_txn_mode`](/system-variables.md#tidb_txn_mode) system variable. The following command sets all explicit transactions (that is, non-autocommit transactions) executed by newly created sessions in the cluster to the pessimistic transaction mode: {{< copyable "sql" >}} diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index a2e7559f2aa4d..09ed2dce6e197 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -92,15 +92,15 @@ On November 30, 2018, TiDB 2.1 GA is released. See the following updates in this - [Add the `auto_analyze_ratio` system variables to contorl the ratio of Analyze](/faq/tidb-faq.md#whats-the-trigger-strategy-for-auto-analyze-in-tidb) - - [Add the `tidb_retry_limit` system variable to control the automatic retry times of transactions](/tidb-specific-system-variables.md#tidb_retry_limit) + - [Add the `tidb_retry_limit` system variable to control the automatic retry times of transactions](/system-variables.md#tidb_retry_limit) - - [Add the `tidb_disable_txn_auto_retry` system variable to control whether the transaction retries automatically](/tidb-specific-system-variables.md#tidb_disable_txn_auto_retry) + - [Add the `tidb_disable_txn_auto_retry` system variable to control whether the transaction retries automatically](/system-variables.md#tidb_disable_txn_auto_retry) - [Support using`admin show slow` statement to obtain the slow queries](/identify-slow-queries.md#admin-show-slow-command) - - [Add the `tidb_slow_log_threshold` environment variable to set the threshold of slow log automatically](/tidb-specific-system-variables.md#tidb_slow_log_threshold) + - [Add the `tidb_slow_log_threshold` environment variable to set the threshold of slow log automatically](/system-variables.md#tidb_slow_log_threshold) - - [Add the `tidb_query_log_max_len` environment variable to set the length of the SQL statement to be truncated in the log dynamically](/tidb-specific-system-variables.md#tidb_query_log_max_len) + - [Add the `tidb_query_log_max_len` environment variable to set the length of the SQL statement to be truncated in the log dynamically](/system-variables.md#tidb_query_log_max_len) + DDL diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 898e378ff1e60..3113838a86f94 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -49,7 +49,7 @@ TiDB Ansible version: 2.1.18 - Fix the issue that the `COM_STMT_FETCH` time record in slow query logs is inconsistent with that in MySQL [#12953](https://github.com/pingcap/tidb/pull/12953) - Add an error code in the error message for write conflicts to quickly locate the cause [#12878](https://github.com/pingcap/tidb/pull/12878) + DDL - - Disallow dropping the `AUTO INCREMENT` attribute of a column by default. Modify the value of the `tidb_allow_remove_auto_inc` variable if you do need to drop this attribute. See [TiDB Specific System Variables](/tidb-specific-system-variables.md#tidb_allow_remove_auto_inc-new-in-v2118-and-v304) for more details. [#12146](https://github.com/pingcap/tidb/pull/12146) + - Disallow dropping the `AUTO INCREMENT` attribute of a column by default. Modify the value of the `tidb_allow_remove_auto_inc` variable if you do need to drop this attribute. See [System Variables](/system-variables.md#tidb_allow_remove_auto_inc-new-in-v2118-and-v304) for more details. [#12146](https://github.com/pingcap/tidb/pull/12146) - Support multiple `unique`s when creating a unique index in the `Create Table` statement [#12469](https://github.com/pingcap/tidb/pull/12469) - Fix a compatibility issue that if the foreign key constraint in `CREATE TABLE` statement has no schema, schema of the created table should be used instead of returning a `No Database selected` error [#12678](https://github.com/pingcap/tidb/pull/12678) - Fix the issue that the `invalid list index` error is reported when executing `ADMIN CANCEL DDL JOBS` [#12681](https://github.com/pingcap/tidb/pull/12681) diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 7272194a8e4f9..fe25f7ba61f99 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -155,7 +155,7 @@ For details, see [Invisible index](/sql-statements/sql-statement-alter-index.md# ## Associated session variables -The global variables associated with the `CREATE INDEX` statement are `tidb_ddl_reorg_worker_cnt`, `tidb_ddl_reorg_batch_size` and `tidb_ddl_reorg_priority`. Refer to [TiDB-specific system variables](/tidb-specific-system-variables.md#tidb_ddl_reorg_worker_cnt) for details. +The global variables associated with the `CREATE INDEX` statement are `tidb_ddl_reorg_worker_cnt`, `tidb_ddl_reorg_batch_size` and `tidb_ddl_reorg_priority`. Refer to [system variables](/system-variables.md#tidb_ddl_reorg_worker_cnt) for details. ## MySQL compatibility diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md index d9dfc667db2e0..84080fc7de649 100644 --- a/sql-statements/sql-statement-create-table.md +++ b/sql-statements/sql-statement-create-table.md @@ -225,7 +225,7 @@ table_option: | STATS_PERSISTENT [=] {DEFAULT|0|1} ``` -The `table_option` currently only supports `AUTO_INCREMENT`, `SHARD_ROW_ID_BITS` (see [TiDB Specific System Variables](/tidb-specific-system-variables.md#shard_row_id_bits) for details), `PRE_SPLIT_REGIONS`, `CHARACTER SET`, `COLLATE`, and `COMMENT`, while the others are only supported in syntax. The clauses are separated by a comma `,`. See the following table for details: +The `table_option` currently only supports `AUTO_INCREMENT`, `SHARD_ROW_ID_BITS`, `PRE_SPLIT_REGIONS`, `CHARACTER SET`, `COLLATE`, and `COMMENT`, while the others are only supported in syntax. The clauses are separated by a comma `,`. See the following table for details: | Parameters | Description | Example | | ---------- | ---------- | ------- | diff --git a/sql-statements/sql-statement-show-variables.md b/sql-statements/sql-statement-show-variables.md index 02c4c75040dc7..17235e7374958 100644 --- a/sql-statements/sql-statement-show-variables.md +++ b/sql-statements/sql-statement-show-variables.md @@ -25,7 +25,7 @@ This statement shows a list of variables for the scope of either `GLOBAL` or `SE ## Examples -List all TiDB specific variables. For detailed description, refer to [TiDB Specific System Variables](/tidb-specific-system-variables.md). +List all TiDB specific variables. For detailed description, refer to [System Variables](/system-variables.md). ```sql mysql> SHOW GLOBAL VARIABLES LIKE 'tidb%'; @@ -155,3 +155,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'time_zone%'; ## MySQL compatibility This statement is understood to be fully compatible with MySQL. Any compatibility differences should be [reported via an issue](/report-issue.md) on GitHub. + +## See also + +* [`SET [GLOBAL|SESSION]`](/sql-statements/sql-statement-set-variable.md) \ No newline at end of file diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 4640c6b529259..bce6211bff6c3 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -391,10 +391,7 @@ region3: [ 2<<61 , 3<<61 ) region4: [ 3<<61 , +inf ) ``` -## Related session variable +## See also -There are two `SPLIT REGION` related session variables: `tidb_scatter_region`, `tidb_wait_split_region_finish` and `tidb_wait_split_region_timeout`. For details, see [TiDB specific system variables and syntax](/tidb-specific-system-variables.md). - -## Reference - -[SHOW TABLE REGIONS](/sql-statements/sql-statement-show-table-regions.md) +* [SHOW TABLE REGIONS](/sql-statements/sql-statement-show-table-regions.md) +* Session variables: [`tidb_scatter_region`](/system-variables.md#tidb_scatter_region), [`tidb_wait_split_region_finish`](/system-variables.md#tidb_wait_split_region_finish) and [`tidb_wait_split_region_timeout`](/system-variables.md#tidb_wait_split_region_timeout). \ No newline at end of file diff --git a/telemetry.md b/telemetry.md index af21f034b76ad..bffcec55914e9 100644 --- a/telemetry.md +++ b/telemetry.md @@ -154,7 +154,7 @@ See [Deploy TiDB Operator in Kubernetes](https://docs.pingcap.com/tidb-in-kubern ### Disable TiDB telemetry for deployed TiDB clusters -In existing TiDB clusters, you can also modify the system variable [`tidb_enable_telemetry`](/tidb-specific-system-variables.md#tidb_enable_telemetry-new-in-v402-version) to dynamically disable the TiDB telemetry collection: +In existing TiDB clusters, you can also modify the system variable [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-new-in-v402-version) to dynamically disable the TiDB telemetry collection: {{< copyable "sql" >}} diff --git a/tidb-best-practices.md b/tidb-best-practices.md index fbdf4cc1b4072..a7d2bfdf362ca 100644 --- a/tidb-best-practices.md +++ b/tidb-best-practices.md @@ -116,21 +116,21 @@ Lots of MySQL experience is also applicable to TiDB. It is noted that TiDB has i As data is distributed across many Regions, queries run in TiDB concurrently. But the concurrency by default is not high in case it consumes lots of system resources. Besides, the OLTP query usually does not involve a large amount of data and the low concurrency is enough. But for the OLAP query, the concurrency is high and TiDB modifies the query concurrency through the following system variables: - - [`tidb_distsql_scan_concurrency`](/tidb-specific-system-variables.md#tidb_distsql_scan_concurrency): + - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency): The concurrency of scanning data, including scanning the table and index data. - - [`tidb_index_lookup_size`](/tidb-specific-system-variables.md#tidb_index_lookup_size): + - [`tidb_index_lookup_size`](/system-variables.md#tidb_index_lookup_size): If it needs to access the index to get row IDs before accessing the table data, it uses a batch of row IDs as a single request to access the table data. This parameter sets the size of a batch. The larger batch increases latency, while the smaller one might lead to more queries. The proper size of this parameter is related to the amount of data that the query involves. Generally, no modification is required. - - [`tidb_index_lookup_concurrency`](/tidb-specific-system-variables.md#tidb_index_lookup_concurrency): + - [`tidb_index_lookup_concurrency`](/system-variables.md#tidb_index_lookup_concurrency): If it needs to access the index to get row IDs before accessing the table data, the concurrency of getting data through row IDs every time is modified through this parameter. * Ensure the order of results through indexes - You can use indexes to filter or sort data. Firstly, get row IDs according to the index order. Then, return the row content according to the return order of row IDs. In this way, the returned results are ordered according to the index column. It has been mentioned earlier that the model of scanning index and getting row is parallel + pipeline. If the row is returned according to the index order, a high concurrency between two queries does not reduce latency. Thus, the concurrency is low by default, but it can be modified through the [`tidb_index_serial_scan_concurrency`](/tidb-specific-system-variables.md#tidb_index_serial_scan_concurrency) variable. + You can use indexes to filter or sort data. Firstly, get row IDs according to the index order. Then, return the row content according to the return order of row IDs. In this way, the returned results are ordered according to the index column. It has been mentioned earlier that the model of scanning index and getting row is parallel + pipeline. If the row is returned according to the index order, a high concurrency between two queries does not reduce latency. Thus, the concurrency is low by default, but it can be modified through the [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency) variable. * Reverse index scan @@ -175,7 +175,7 @@ This pseudocode means to split huge chunks of data into small ones and then dele ### Query -For query requirements and specific statements, refer to [TiDB Specific System Variables](/tidb-specific-system-variables.md). +For query requirements and specific statements, refer to [System Variables](/system-variables.md). You can control the concurrency of SQL execution through the `SET` statement and the selection of the `Join` operator through hints. diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index c4c6111e0a9cc..821c679c08df0 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -28,7 +28,7 @@ The TiDB configuration file supports more options than command-line parameters. - The maximum memory available for a single SQL statement. - Default value: `1073741824` (in bytes) - Requests that require more memory than this value are handled based on the behavior defined by `oom-action`. -- This value is the initial value of the system variable [`tidb_mem_quota_query`](/tidb-specific-system-variables.md#tidb_mem_quota_query). +- This value is the initial value of the system variable [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query). ### `oom-use-tmp-storage` @@ -146,7 +146,7 @@ The TiDB configuration file supports more options than command-line parameters. - Enables or disables the telemetry collection in TiDB. - Default value: `true` -- When this configuration is set to `false` on all TiDB instances, the telemetry collection in TiDB is disabled and the [`tidb_enable_telemetry`](/tidb-specific-system-variables.md#tidb_enable_telemetry-new-in-v402-version) system variable does not take effect. See [Telemetry](/telemetry.md) for details. +- When this configuration is set to `false` on all TiDB instances, the telemetry collection in TiDB is disabled and the [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-new-in-v402-version) system variable does not take effect. See [Telemetry](/telemetry.md) for details. ## Log @@ -193,7 +193,7 @@ Configuration items related to log. + Determines whether to record execution plans in the slow log. + Default value: `1` -+ `0` means to disable, and `1` (by default) means to enable. The value of this parameter is the initial value of the [`tidb_record_plan_in_slow_log`](/tidb-specific-system-variables.md#tidb_record_plan_in_slow_log) system variable. ++ `0` means to disable, and `1` (by default) means to enable. The value of this parameter is the initial value of the [`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log) system variable. ### `expensive-threshold` diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index c5128d60babfa..17b623b17cccd 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -15,7 +15,7 @@ If you want to save machine resources and have no requirement on isolation, you ## Tune TiDB parameters -1. For the TiDB node dedicated to OLAP/TiFlash, it is recommended that you increase the value of the [`tidb_distsql_scan_concurrency`](/tidb-specific-system-variables.md#tidb_distsql_scan_concurrency) configuration item for this node to `80`: +1. For the TiDB node dedicated to OLAP/TiFlash, it is recommended that you increase the value of the [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) configuration item for this node to `80`: {{< copyable "sql" >}} @@ -25,7 +25,7 @@ If you want to save machine resources and have no requirement on isolation, you 2. Enable the super batch feature: - You can use the [`tidb_allow_batch_cop`](/tidb-specific-system-variables.md#tidb_allow_batch_cop-new-in-v40-version) variable to set whether to merge Region requests when reading from TiFlash. + You can use the [`tidb_allow_batch_cop`](/system-variables.md#tidb_allow_batch_cop-new-in-v40-version) variable to set whether to merge Region requests when reading from TiFlash. When the number of Regions involved in the query is relatively large, try to set this variable to `1` (effective for coprocessor requests with `aggregation` operators that are pushed down to TiFlash), or set this variable to `2` (effective for all coprocessor requests that are pushed down to TiFlash). @@ -37,7 +37,7 @@ If you want to save machine resources and have no requirement on isolation, you 3. Enable the optimization of pushing down aggregate functions before TiDB operators such as `JOIN` or `UNION`: - You can use the [`tidb_opt_agg_push_down`](/tidb-specific-system-variables.md#tidb_opt_agg_push_down) variable to control the optimizer to execute this optimization. When the aggregate operations are quite slow in the query, try to set this variable to `1`. + You can use the [`tidb_opt_agg_push_down`](/system-variables.md#tidb_opt_agg_push_down) variable to control the optimizer to execute this optimization. When the aggregate operations are quite slow in the query, try to set this variable to `1`. {{< copyable "sql" >}} @@ -47,7 +47,7 @@ If you want to save machine resources and have no requirement on isolation, you 4. Enable the optimization of pushing down aggregate functions with `Distinct` before TiDB operators such as `JOIN` or `UNION`: - You can use the [`tidb_opt_distinct_agg_push_down`](/tidb-specific-system-variables.md#tidb_opt_distinct_agg_push_down) variable to control the optimizer to execute this optimization. When the aggregate operations with `Distinct` are quite slow in the query, try to set this variable to `1`. + You can use the [`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distinct_agg_push_down) variable to control the optimizer to execute this optimization. When the aggregate operations with `Distinct` are quite slow in the query, try to set this variable to `1`. {{< copyable "sql" >}} diff --git a/transaction-overview.md b/transaction-overview.md index ae043d5f911a6..a2421f99b04f7 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -9,7 +9,7 @@ aliases: ['/docs/dev/transaction-overview/','/docs/dev/reference/transactions/ov TiDB supports complete distributed transactions. Both [optimistic transaction model](/optimistic-transaction.md) and [pessimistic transaction model](/pessimistic-transaction.md)(introduced in TiDB 3.0) are available. This document introduces commonly used transaction-related statements, explicit and implicit transactions, isolation levels, lazy check for constraints, and transaction sizes. -The common variables include [`autocommit`](#autocommit), [`tidb_disable_txn_auto_retry`](/tidb-specific-system-variables.md#tidb_disable_txn_auto_retry), [`tidb_retry_limit`](/tidb-specific-system-variables.md#tidb_retry_limit), and [`tidb_txn_mode`](/tidb-specific-system-variables.md#tidb_txn_mode). +The common variables include [`autocommit`](#autocommit), [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry), [`tidb_retry_limit`](/system-variables.md#tidb_retry_limit), and [`tidb_txn_mode`](/system-variables.md#tidb_txn_mode). ## Common syntax From 5c09356bee992fd3e917a1d9c775f89b0e5fcadb Mon Sep 17 00:00:00 2001 From: Null not nil <67764674+nullnotnil@users.noreply.github.com> Date: Fri, 10 Jul 2020 05:52:14 -0600 Subject: [PATCH 04/11] Update system-variables.md --- system-variables.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/system-variables.md b/system-variables.md index dea57411c1752..760bc578e9112 100644 --- a/system-variables.md +++ b/system-variables.md @@ -2,7 +2,7 @@ title: System Variables summary: Use system variables to optimize performance or alter running behavior. category: reference -aliases: ['/docs/dev/tidb-specific-system-variables/','/docs/dev/reference/configuration/tidb-server/tidb-specific-variables/', '/tidb/dev/tidb-specific-system-variables'] +aliases: ['/docs/dev/system-variables/','/docs/dev/reference/configuration/tidb-server/mysql-variables/', '/docs/dev/tidb-specific-system-variables/','/docs/dev/reference/configuration/tidb-server/tidb-specific-variables/'] --- # System Variables @@ -687,4 +687,4 @@ This variable is an alias for _transaction_isolation_. - Scope: SESSION | GLOBAL - Default value: ON -- This variable controls whether to use the high precision mode when computing the window functions. \ No newline at end of file +- This variable controls whether to use the high precision mode when computing the window functions. From b3366203d85c2e85901e673613fd3349627a947c Mon Sep 17 00:00:00 2001 From: Nullnotnil Date: Fri, 10 Jul 2020 08:40:22 -0600 Subject: [PATCH 05/11] Fix additional link --- partitioned-table.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/partitioned-table.md b/partitioned-table.md index 525e269c664f5..8f1b7ed68ea6e 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -1052,4 +1052,4 @@ select * from t; The `tidb_enable_table_partition` environment variable controls whether to enable the partitioned table feature. If this variable is set to `off`, the partition information will be ignored when a table is created, and this table will be created as a normal table. -This variable is only used in table creation. After the table is created, modify this variable value takes no effect. For details, see [TiDB specific system variables](/tidb-specific-system-variables.md#tidb_enable_table_partition). +This variable is only used in table creation. After the table is created, modify this variable value takes no effect. For details, see [system variables](/system-variables.md#tidb_enable_table_partition). From 8af83facc7f1d761dcd35f3036f41709a957e977 Mon Sep 17 00:00:00 2001 From: Null not nil <67764674+nullnotnil@users.noreply.github.com> Date: Mon, 13 Jul 2020 07:49:10 -0600 Subject: [PATCH 06/11] Update system-variables.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index 5f27d891e05ad..4e93ede705317 100644 --- a/system-variables.md +++ b/system-variables.md @@ -7,7 +7,7 @@ aliases: ['/docs/dev/system-variables/','/docs/dev/reference/configuration/tidb- # System Variables -TiDB system variables behavior similar to MySQL, in that settings may apply on a `SESSION`, `GLOBAL` or both `SESSION` and `GLOBAL` scope. Changes to `GLOBAL` scoped variables **only apply** to new connections to TiDB. Variables can be set with the [`SET` statement](/sql-statements/sql-statement-set-variable.md) on a per-session or global basis: +TiDB system variables behave similar to MySQL, in that settings may apply on a `SESSION`, `GLOBAL` or both `SESSION` and `GLOBAL` scope. Changes to `GLOBAL` scoped variables **only apply** to new connections to TiDB. Variables can be set with the [`SET` statement](/sql-statements/sql-statement-set-variable.md) on a per-session or global basis: ```sql # These two identical statements change a session variable From c7215b135efb45c51de7473b79f0c29b768f757f Mon Sep 17 00:00:00 2001 From: Null not nil <67764674+nullnotnil@users.noreply.github.com> Date: Mon, 13 Jul 2020 07:49:20 -0600 Subject: [PATCH 07/11] Update system-variables.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index 4e93ede705317..d756d493a3d4e 100644 --- a/system-variables.md +++ b/system-variables.md @@ -21,7 +21,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; > **Note:** > -> TiDB differs from MySQL in that `GLOBAL` scoped variables **persist** through TiDB server restarts. Changes will also be propagated to other TiDB servers every 2 seconds [TiDB #14531](https://github.com/pingcap/tidb/issues/14531). +> TiDB differs from MySQL in that `GLOBAL` scoped variables **persist** through TiDB server restarts. Changes are also propagated to other TiDB servers every 2 seconds [TiDB #14531](https://github.com/pingcap/tidb/issues/14531). > Additionally, TiDB presents several MySQL variables from MySQL 5.7 as both readable and settable. This is required for compatibility, since it is common for both applications and connectors to read MySQL variables. For example: JDBC connectors both read and set query cache settings, despite not relying on the behavior. ## Variable Reference From c7c5c234d807953cdd37c93ee65b63e4b4e0b07f Mon Sep 17 00:00:00 2001 From: Null not nil <67764674+nullnotnil@users.noreply.github.com> Date: Mon, 13 Jul 2020 07:49:36 -0600 Subject: [PATCH 08/11] Update system-variables.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index d756d493a3d4e..9ef9d2bd35266 100644 --- a/system-variables.md +++ b/system-variables.md @@ -82,7 +82,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Scope: SESSION | GLOBAL - Default value: `2^64 - 1` (18446744073709551615) -- The maximum number of rows to return from the `SELECT` statements. +- The maximum number of rows returned by the `SELECT` statements. ### tidb_allow_batch_cop New in v4.0 version From 51fe4e8f56942747eea2f8053f27a90873467fcf Mon Sep 17 00:00:00 2001 From: Null not nil <67764674+nullnotnil@users.noreply.github.com> Date: Mon, 13 Jul 2020 07:49:43 -0600 Subject: [PATCH 09/11] Update system-variables.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index 9ef9d2bd35266..c74d3f466b4da 100644 --- a/system-variables.md +++ b/system-variables.md @@ -30,7 +30,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Scope: SESSION | GLOBAL - Default value: ON -- whether automatically commit a transaction +- Whether automatically commit a transaction. ### ddl_slow_threshold From ab84e1d4a6a1c85c418f9e13e518574c4cb8da72 Mon Sep 17 00:00:00 2001 From: Null not nil <67764674+nullnotnil@users.noreply.github.com> Date: Mon, 13 Jul 2020 08:19:57 -0600 Subject: [PATCH 10/11] Add v4.0.2 disclaimer --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index c74d3f466b4da..f81c9f5050d17 100644 --- a/system-variables.md +++ b/system-variables.md @@ -78,7 +78,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Default value: `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION` - This variable controls a number of MySQL compatibility behaviors. See [SQL Mode](/sql-mode.md) for more information. -### sql_select_limit +### sql_select_limit New in v4.0.2 version - Scope: SESSION | GLOBAL - Default value: `2^64 - 1` (18446744073709551615) From 2d146fcc7cbe409c5b401ea5c4008e6a4d6157f4 Mon Sep 17 00:00:00 2001 From: Nullnotnil Date: Mon, 13 Jul 2020 08:30:25 -0600 Subject: [PATCH 11/11] Address PR feedback --- system-variables.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/system-variables.md b/system-variables.md index f81c9f5050d17..0146628452b07 100644 --- a/system-variables.md +++ b/system-variables.md @@ -257,7 +257,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Scope: SESSION | GLOBAL - Default value: 0 -- This variable is used to control whether to enable the cascades planner feature. +- This variable is used to control whether to enable the cascades planner, which is currently considered experimental. ### tidb_enable_chunk_rpc New in v4.0 @@ -437,6 +437,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Scope: SESSION | GLOBAL - Default value: 32 +- Range: 1 - 32 - This variable is used to set the number of rows for the initial chunk during the execution process. ### tidb_isolation_read_engines New in v4.0 @@ -456,7 +457,8 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - Scope: SESSION | GLOBAL - Default value: 1024 -- This variable is used to set the maximum number of rows in a chunk during the execution process. +- Minimum value: 32 +- This variable is used to set the maximum number of rows in a chunk during the execution process. Setting to too large of a value may cause cache locality issues. ### tidb_max_delta_schema_count New in v2.1.18 and v3.0.5 @@ -683,7 +685,7 @@ set tidb_query_log_max_len = 20 - Scope: SESSION - Default value: 0 -- After this switch is enabled, if an isolation level unsupported by TiDB is assigned to `tx_isolation`, no error is reported. +- After this switch is enabled, if an isolation level unsupported by TiDB is assigned to `tx_isolation`, no error is reported. This helps improve compatibility with applications that set (but do not depend on) a different isolation level. ```sql tidb> set tx_isolation='serializable';