From 09dad40e40238d5f728db43cb9e453b012f45949 Mon Sep 17 00:00:00 2001 From: Dongpo Liu Date: Tue, 14 Jul 2026 12:21:14 +0200 Subject: [PATCH 1/5] This is an automated cherry-pick of #21938 Signed-off-by: ti-chi-bot --- best-practices/tidb-best-practices.md | 2 +- statistics.md | 20 ++++++---- system-variables.md | 40 +++++++++++++++---- ...v8.1-performance-benchmarking-with-tpcc.md | 4 +- ...v8.5-performance-benchmarking-with-tpcc.md | 4 +- troubleshoot-tidb-oom.md | 3 +- 6 files changed, 51 insertions(+), 22 deletions(-) diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index a941c4e56d88b..4a0c37ffba861 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -129,7 +129,7 @@ Lots of MySQL experience is also applicable to TiDB. It is noted that TiDB has i * 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`](/system-variables.md#tidb_index_serial_scan_concurrency) variable. + You can use indexes to filter or sort data. TiDB first gets row IDs according to the index order, and then returns the row content according to the order of those 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 you can increase it by adjusting [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50). * Reverse index scan diff --git a/statistics.md b/statistics.md index 551b4c7b6353e..80fffbbb14eaa 100644 --- a/statistics.md +++ b/statistics.md @@ -763,23 +763,29 @@ The relationships of the relevant system variables are shown below: #### `tidb_build_stats_concurrency` -When you run the `ANALYZE` statement, the task is divided into multiple small tasks. Each task only works on statistics of one column or index. You can use the [`tidb_build_stats_concurrency`](/system-variables.md#tidb_build_stats_concurrency) variable to control the number of simultaneous small tasks. The default value is `2`. The default value is `4` for v7.4.0 and earlier versions. +This variable controls the concurrency for building statistics during manual `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously. The default value is `2`. The default value is `4` for v7.4.0 and earlier versions. #### `tidb_build_sampling_stats_concurrency` -When analyzing ordinary columns, you can use [`tidb_build_sampling_stats_concurrency`](/system-variables.md#tidb_build_sampling_stats_concurrency-new-in-v750) to control the concurrency of executing sampling tasks. The default value is `2`. +This variable controls the following aspects of `ANALYZE` concurrency: + +- The concurrency for merging samples collected from different Regions. +- The concurrency for collecting statistics on special indexes (such as indexes on generated virtual columns), for example, the number of indexes that TiDB can concurrently collect statistics for. + +The default value is `2`. #### `tidb_analyze_partition_concurrency` -When running the `ANALYZE` statement, you can use [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) to control the concurrency of reading and writing statistics for a partitioned table. The default value is `2`. The default value is `1` for v7.4.0 and earlier versions. +This variable controls the concurrency for saving `ANALYZE` results (writing TopN and histograms to system tables). The default value is `2`. The default value is `1` for v7.4.0 and earlier versions. -#### `tidb_distsql_scan_concurrency` +#### `tidb_analyze_distsql_scan_concurrency` -When you analyze regular columns, you can use the [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) variable to control the number of Regions to be read at one time. The default value is `15`. Note that changing the value will affect query performance. Adjust the value carefully. +This variable controls the following aspects of `ANALYZE` concurrency: -#### `tidb_index_serial_scan_concurrency` +- The concurrency of scanning TiKV Regions. +- The concurrency of scanning Regions for special indexes (indexes generated from virtual columns). -When you analyze index columns, you can use the [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency) variable to control the number of Regions to be read at one time. The default value is `1`. Note that changing the value will affect query performance. Adjust the value carefully. +The default value is `4`. ## See also diff --git a/system-variables.md b/system-variables.md index 82e97cc987f49..d419c6d5cb53d 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1114,13 +1114,24 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a ### tidb_analyze_distsql_scan_concurrency New in v7.6.0 +> **Note:** +> +> In versions earlier than v7.6.0, regular `ANALYZE` region scans are controlled by `tidb_distsql_scan_concurrency`, and index statistics scans are controlled by `tidb_index_serial_scan_concurrency`. Therefore, to adjust the concurrency of scanning TiKV Regions for these versions, consider changing the value of `tidb_distsql_scan_concurrency`. + - Scope: SESSION | GLOBAL - Persists to cluster: Yes - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Type: Integer - Default value: `4` +<<<<<<< HEAD - Range: `[1, 4294967295]` - This variable is used to set the concurrency of the `scan` operation when executing the `ANALYZE` operation. +======= +- Range: `[0, 4294967295]`. In versions earlier than v8.2.0, the minimum value is `1`. When you set it to `0`, it adaptively adjusts the concurrency based on the cluster size. +- This variable controls the following aspects of `ANALYZE` concurrency: + - The concurrency of scanning TiKV Regions. + - The concurrency of scanning Regions for special indexes, such as indexes on generated virtual columns. +>>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) ### tidb_analyze_partition_concurrency @@ -1128,7 +1139,12 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a - Persists to cluster: Yes - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Default value: `2`. The default value is `1` for v7.4.0 and earlier versions. +<<<<<<< HEAD - This variable specifies the concurrency of reading and writing statistics for a partitioned table when TiDB analyzes the partitioned table. +======= +- Range: `[1, 128]`. Before v8.4.0, the value range is `[1, 18446744073709551615]`. +- For manual and auto `ANALYZE`, this variable controls the concurrency for saving `ANALYZE` results, including writing TopN and histograms to system tables. +>>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) ### tidb_analyze_version New in v5.1.0 @@ -1172,7 +1188,7 @@ mysql> SELECT @@tidb_analyze_skip_column_types; +----------------------------------+ | @@tidb_analyze_skip_column_types | +----------------------------------+ -| json,blob,mediumblob,longblob | +| json,blob,mediumblob,longblob,mediumtext,longtext | +----------------------------------+ 1 row in set (0.00 sec) @@ -1250,7 +1266,12 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - Type: Integer - Default value: `1` - Range: `[1, 256]` +<<<<<<< HEAD - This variable is used to set the concurrency of executing the automatic update of statistics. +======= +- This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously +- Starting from v8.5.7 and v9.0.0, the default value of this variable changes from `1` to `2`. If your cluster is upgraded from an earlier version, the value of this variable remains unchanged after the upgrade. +>>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) ### tidb_backoff_lock_fast @@ -1355,8 +1376,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - Default value: `2`. The default value is `4` for v7.4.0 and earlier versions. - Range: `[1, 256]` - Unit: Threads -- 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. +- This variable controls the concurrency for building statistics during manual `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously. ### tidb_build_sampling_stats_concurrency New in v7.5.0 @@ -1367,8 +1387,9 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - Unit: Threads - Default value: `2` - Range: `[1, 256]` -- This variable is used to set the sampling concurrency in the `ANALYZE` process. -- When the variable is set to a larger value, the execution performance of other queries is affected. +- This variable controls the following aspects of `ANALYZE` concurrency: + - The concurrency for merging samples collected from different Regions. + - The concurrency for collecting statistics on special indexes (such as indexes on generated virtual columns), for example, the number of indexes that TiDB can concurrently collect statistics for. ### tidb_capture_plan_baselines New in v4.0 @@ -3339,6 +3360,10 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified ### tidb_index_serial_scan_concurrency +> **Warning:** +> +> This variable is deprecated and no longer controls execution behavior. The concurrency of sequential index scans is now controlled by [`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50), and [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) uses [`tidb_analyze_distsql_scan_concurrency`](#tidb_analyze_distsql_scan_concurrency-new-in-v760) to control the concurrency of index statistics scans. + - Scope: SESSION | GLOBAL - Persists to cluster: Yes - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): Yes @@ -3346,8 +3371,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified - Default value: `1` - Range: `[1, 256]` - Unit: Threads -- 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. +- This variable remains only for backward compatibility. Use [`tidb_executor_concurrency`](#tidb_executor_concurrency-new-in-v50) to control the concurrency of sequential index scans, or [`tidb_analyze_distsql_scan_concurrency`](#tidb_analyze_distsql_scan_concurrency-new-in-v760) to control the concurrency of index statistics scans. ### tidb_init_chunk_size @@ -3824,7 +3848,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified - Persists to cluster: Yes - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Default value: `1` -- This variable specifies the concurrency of merging statistics for a partitioned table when TiDB analyzes the partitioned table. +- This variable controls the concurrency for merging TopN results of partitioned tables. ### tidb_enable_async_merge_global_stats New in v7.5.0 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 8aad399883823..79e74aec086dd 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -96,8 +96,8 @@ This section introduces how to perform the TPC-C performance test step by step. ```sql SET tidb_build_stats_concurrency=16; - SET tidb_distsql_scan_concurrency=16; - SET tidb_index_serial_scan_concurrency=16; + SET tidb_build_sampling_stats_concurrency = 16; + SET tidb_analyze_distsql_scan_concurrency=16; ``` 5. Run the following `go-tpc tpcc` command to conduct stress tests on the TiDB Cloud Dedicated cluster. For each concurrency, the test takes two hours. diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 53abd9096c0cb..3bd5bbd2a576a 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -96,8 +96,8 @@ This section introduces how to perform the TPC-C performance test step by step. ```sql SET tidb_build_stats_concurrency=16; - SET tidb_distsql_scan_concurrency=16; - SET tidb_index_serial_scan_concurrency=16; + SET tidb_build_sampling_stats_concurrency = 16; + SET tidb_analyze_distsql_scan_concurrency=16; ``` 5. Run the following `go-tpc tpcc` command to conduct stress tests on the TiDB Cloud Dedicated cluster. For each concurrency, the test takes two hours. diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 1c2f102cd0681..c888f278f5e63 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -99,7 +99,6 @@ You can take the following measures to reduce the memory usage of SQL statements - Reduce the number of Regions to be read simultaneously or reduce the concurrency of operators to avoid memory problems caused by high concurrency. The corresponding system variables include: - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) - - [`tidb_index_serial_scan_concurrency`](/system-variables.md#tidb_index_serial_scan_concurrency) - [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50) - The concurrency of sessions is too high near the time point when the problem occurs. In this case, consider scaling out the TiDB cluster by adding more TiDB nodes. @@ -195,4 +194,4 @@ To locate the root cause of an OOM issue, you need to collect the following info ## See also - [TiDB Memory Control](/configure-memory-usage.md) -- [Tune TiKV Memory Parameter Performance](/tune-tikv-memory-performance.md) \ No newline at end of file +- [Tune TiKV Memory Parameter Performance](/tune-tikv-memory-performance.md) From f288c4cc6059b2b58ce03180ad6708cb1464349a Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 15 Jul 2026 10:53:35 +0800 Subject: [PATCH 2/5] resolve conflicts --- system-variables.md | 13 ------------- .../v8.1-performance-benchmarking-with-tpcc.md | 4 ++-- .../v8.5-performance-benchmarking-with-tpcc.md | 4 ++-- 3 files changed, 4 insertions(+), 17 deletions(-) diff --git a/system-variables.md b/system-variables.md index d419c6d5cb53d..1827633816ab6 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1123,15 +1123,10 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Type: Integer - Default value: `4` -<<<<<<< HEAD -- Range: `[1, 4294967295]` -- This variable is used to set the concurrency of the `scan` operation when executing the `ANALYZE` operation. -======= - Range: `[0, 4294967295]`. In versions earlier than v8.2.0, the minimum value is `1`. When you set it to `0`, it adaptively adjusts the concurrency based on the cluster size. - This variable controls the following aspects of `ANALYZE` concurrency: - The concurrency of scanning TiKV Regions. - The concurrency of scanning Regions for special indexes, such as indexes on generated virtual columns. ->>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) ### tidb_analyze_partition_concurrency @@ -1139,12 +1134,8 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a - Persists to cluster: Yes - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Default value: `2`. The default value is `1` for v7.4.0 and earlier versions. -<<<<<<< HEAD -- This variable specifies the concurrency of reading and writing statistics for a partitioned table when TiDB analyzes the partitioned table. -======= - Range: `[1, 128]`. Before v8.4.0, the value range is `[1, 18446744073709551615]`. - For manual and auto `ANALYZE`, this variable controls the concurrency for saving `ANALYZE` results, including writing TopN and histograms to system tables. ->>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) ### tidb_analyze_version New in v5.1.0 @@ -1266,12 +1257,8 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - Type: Integer - Default value: `1` - Range: `[1, 256]` -<<<<<<< HEAD -- This variable is used to set the concurrency of executing the automatic update of statistics. -======= - This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously - Starting from v8.5.7 and v9.0.0, the default value of this variable changes from `1` to `2`. If your cluster is upgraded from an earlier version, the value of this variable remains unchanged after the upgrade. ->>>>>>> 3d8180e56a (tidb: update tidb_index_serial_scan_concurrency docs (#21938)) ### tidb_backoff_lock_fast diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 79e74aec086dd..8aad399883823 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -96,8 +96,8 @@ This section introduces how to perform the TPC-C performance test step by step. ```sql SET tidb_build_stats_concurrency=16; - SET tidb_build_sampling_stats_concurrency = 16; - SET tidb_analyze_distsql_scan_concurrency=16; + SET tidb_distsql_scan_concurrency=16; + SET tidb_index_serial_scan_concurrency=16; ``` 5. Run the following `go-tpc tpcc` command to conduct stress tests on the TiDB Cloud Dedicated cluster. For each concurrency, the test takes two hours. diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 3bd5bbd2a576a..53abd9096c0cb 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -96,8 +96,8 @@ This section introduces how to perform the TPC-C performance test step by step. ```sql SET tidb_build_stats_concurrency=16; - SET tidb_build_sampling_stats_concurrency = 16; - SET tidb_analyze_distsql_scan_concurrency=16; + SET tidb_distsql_scan_concurrency=16; + SET tidb_index_serial_scan_concurrency=16; ``` 5. Run the following `go-tpc tpcc` command to conduct stress tests on the TiDB Cloud Dedicated cluster. For each concurrency, the test takes two hours. From 08eaf79e22bd660bf3c28b474b3243bb08abe11e Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 15 Jul 2026 10:58:59 +0800 Subject: [PATCH 3/5] docs: correct v8.1 analyze partition range --- system-variables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-variables.md b/system-variables.md index 1827633816ab6..d89770b4fc6b2 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1134,7 +1134,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a - Persists to cluster: Yes - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Default value: `2`. The default value is `1` for v7.4.0 and earlier versions. -- Range: `[1, 128]`. Before v8.4.0, the value range is `[1, 18446744073709551615]`. +- Range: `[1, 18446744073709551615]` - For manual and auto `ANALYZE`, this variable controls the concurrency for saving `ANALYZE` results, including writing TopN and histograms to system tables. ### tidb_analyze_version New in v5.1.0 From c7178ec1a1eec0d117bc7d8e78272146ed52f67b Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 15 Jul 2026 11:05:57 +0800 Subject: [PATCH 4/5] docs: align conflict resolution with v8.1 --- statistics.md | 2 +- system-variables.md | 7 +++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/statistics.md b/statistics.md index 80fffbbb14eaa..d532c01a75ed4 100644 --- a/statistics.md +++ b/statistics.md @@ -782,7 +782,7 @@ This variable controls the concurrency for saving `ANALYZE` results (writing Top This variable controls the following aspects of `ANALYZE` concurrency: -- The concurrency of scanning TiKV Regions. +- The concurrency of scanning TiKV Regions. - The concurrency of scanning Regions for special indexes (indexes generated from virtual columns). The default value is `4`. diff --git a/system-variables.md b/system-variables.md index d89770b4fc6b2..e0188bcc19360 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1123,7 +1123,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a - Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No - Type: Integer - Default value: `4` -- Range: `[0, 4294967295]`. In versions earlier than v8.2.0, the minimum value is `1`. When you set it to `0`, it adaptively adjusts the concurrency based on the cluster size. +- Range: `[1, 4294967295]` - This variable controls the following aspects of `ANALYZE` concurrency: - The concurrency of scanning TiKV Regions. - The concurrency of scanning Regions for special indexes, such as indexes on generated virtual columns. @@ -1179,7 +1179,7 @@ mysql> SELECT @@tidb_analyze_skip_column_types; +----------------------------------+ | @@tidb_analyze_skip_column_types | +----------------------------------+ -| json,blob,mediumblob,longblob,mediumtext,longtext | +| json,blob,mediumblob,longblob | +----------------------------------+ 1 row in set (0.00 sec) @@ -1257,8 +1257,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - Type: Integer - Default value: `1` - Range: `[1, 256]` -- This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously -- Starting from v8.5.7 and v9.0.0, the default value of this variable changes from `1` to `2`. If your cluster is upgraded from an earlier version, the value of this variable remains unchanged after the upgrade. +- This variable controls the concurrency for building statistics during auto `ANALYZE`, such as the number of table or partition analysis tasks that can be processed simultaneously. ### tidb_backoff_lock_fast From 8171a2f65a9d8b2141f4acef5b3d4dd7f8a9acc5 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 15 Jul 2026 12:19:51 +0800 Subject: [PATCH 5/5] docs: exclude best practices from release-8.1 --- best-practices/tidb-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 4a0c37ffba861..a941c4e56d88b 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -129,7 +129,7 @@ Lots of MySQL experience is also applicable to TiDB. It is noted that TiDB has i * Ensure the order of results through indexes - You can use indexes to filter or sort data. TiDB first gets row IDs according to the index order, and then returns the row content according to the order of those 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 you can increase it by adjusting [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50). + 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