- For Clinic Server in the Chinese mainland, set `region` to `CN` using the following command:
+ When using Clinic Server for users in the Chinese mainland, set `region` to `CN` using the following command:
```bash
tiup diag config clinic.region CN
diff --git a/clustered-indexes.md b/clustered-indexes.md
index a75cf3650f95f..d29cbdd7b6b31 100644
--- a/clustered-indexes.md
+++ b/clustered-indexes.md
@@ -67,7 +67,7 @@ For statements that do not explicitly specify the keyword `CLUSTERED`/`NONCLUSTE
- `ON` indicates that primary keys are created as clustered indexes by default.
- `INT_ONLY` indicates that the behavior is controlled by the configuration item `alter-primary-key`. If `alter-primary-key` is set to `true`, primary keys are created as non-clustered indexes by default. If it is set to `false`, only the primary keys which consist of an integer column are created as clustered indexes.
-The default value of `@@global.tidb_enable_clustered_index` is `INT_ONLY`.
+The default value of `@@global.tidb_enable_clustered_index` is `ON`.
### Add or drop clustered indexes
diff --git a/config-templates/complex-cdc.yaml b/config-templates/complex-cdc.yaml
index d4bf6ea67f4d9..4598b0c232dc1 100644
--- a/config-templates/complex-cdc.yaml
+++ b/config-templates/complex-cdc.yaml
@@ -16,9 +16,9 @@ monitored:
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
-# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
-# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
-# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
+# # - TiDB: https://docs.pingcap.com/tidb/stable/tidb-configuration-file
+# # - TiKV: https://docs.pingcap.com/tidb/stable/tikv-configuration-file
+# # - PD: https://docs.pingcap.com/tidb/stable/pd-configuration-file
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
diff --git a/config-templates/complex-mini.yaml b/config-templates/complex-mini.yaml
index 4a4807867a2ac..85aea0afcba98 100644
--- a/config-templates/complex-mini.yaml
+++ b/config-templates/complex-mini.yaml
@@ -16,9 +16,9 @@ monitored:
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
-# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
-# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
-# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
+# # - TiDB: https://docs.pingcap.com/tidb/stable/tidb-configuration-file
+# # - TiKV: https://docs.pingcap.com/tidb/stable/tikv-configuration-file
+# # - PD: https://docs.pingcap.com/tidb/stable/pd-configuration-file
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
diff --git a/config-templates/complex-tidb-binlog.yaml b/config-templates/complex-tidb-binlog.yaml
index 6981030e2b69f..fe8aa7eb7b388 100644
--- a/config-templates/complex-tidb-binlog.yaml
+++ b/config-templates/complex-tidb-binlog.yaml
@@ -16,9 +16,9 @@ monitored:
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
-# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
-# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
-# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
+# # - TiDB: https://docs.pingcap.com/tidb/stable/tidb-configuration-file
+# # - TiKV: https://docs.pingcap.com/tidb/stable/tikv-configuration-file
+# # - PD: https://docs.pingcap.com/tidb/stable/pd-configuration-file
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
diff --git a/config-templates/complex-tiflash.yaml b/config-templates/complex-tiflash.yaml
index 66e41c6ba2f3c..f473f9f404379 100644
--- a/config-templates/complex-tiflash.yaml
+++ b/config-templates/complex-tiflash.yaml
@@ -16,9 +16,9 @@ monitored:
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
-# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
-# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
-# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
+# # - TiDB: https://docs.pingcap.com/tidb/stable/tidb-configuration-file
+# # - TiKV: https://docs.pingcap.com/tidb/stable/tikv-configuration-file
+# # - PD: https://docs.pingcap.com/tidb/stable/pd-configuration-file
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
diff --git a/config-templates/complex-tispark.yaml b/config-templates/complex-tispark.yaml
index f32bd1677cbb3..622ba8406b4be 100644
--- a/config-templates/complex-tispark.yaml
+++ b/config-templates/complex-tispark.yaml
@@ -16,9 +16,9 @@ monitored:
# # Server configs are used to specify the runtime configuration of TiDB components.
# # All configuration items can be found in TiDB docs:
-# # - TiDB: https://pingcap.com/docs/stable/reference/configuration/tidb-server/configuration-file/
-# # - TiKV: https://pingcap.com/docs/stable/reference/configuration/tikv-server/configuration-file/
-# # - PD: https://pingcap.com/docs/stable/reference/configuration/pd-server/configuration-file/
+# # - TiDB: https://docs.pingcap.com/tidb/stable/tidb-configuration-file
+# # - TiKV: https://docs.pingcap.com/tidb/stable/tikv-configuration-file
+# # - PD: https://docs.pingcap.com/tidb/stable/pd-configuration-file
# # All configuration items use points to represent the hierarchy, e.g:
# # readpool.storage.use-unified-pool
# #
diff --git a/configure-placement-rules.md b/configure-placement-rules.md
index 994ec78d6760e..fb57a08487ad6 100644
--- a/configure-placement-rules.md
+++ b/configure-placement-rules.md
@@ -95,7 +95,7 @@ In this way, PD enables this feature after the cluster is successfully bootstrap
}
```
-For a bootstrapped cluster, you can also enable Placement Rules online through pd-ctl:
+For a bootstrapped cluster, you can also enable Placement Rules dynamically through pd-ctl:
{{< copyable "shell-regular" >}}
diff --git a/constraints.md b/constraints.md
index 165d475096f0c..3f2ce1dadab90 100644
--- a/constraints.md
+++ b/constraints.md
@@ -157,7 +157,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill');
ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username'
```
-The first `INSERT` statement caused a duplicate key error. This causes additional network communication overhead and may reduce the throughput of insert operations.
+The first `INSERT` statement caused a duplicate key error. This causes additional network communication overhead and may reduce the throughput of insert operations.
### Pessimistic transactions
diff --git a/correlated-subquery-optimization.md b/correlated-subquery-optimization.md
index 1021e24dce258..1477dfe06f48f 100644
--- a/correlated-subquery-optimization.md
+++ b/correlated-subquery-optimization.md
@@ -57,20 +57,20 @@ explain select * from t1 where t1.a < (select /*+ NO_DECORRELATE() */ sum(t2.a)
```
```sql
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
-| Projection_10 | 10000.00 | root | | test.t1.a, test.t1.b |
-| └─Apply_12 | 10000.00 | root | | CARTESIAN inner join, other cond:lt(cast(test.t1.a, decimal(10,0) BINARY), Column#7) |
-| ├─TableReader_14(Build) | 10000.00 | root | | data:TableFullScan_13 |
-| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
-| └─MaxOneRow_15(Probe) | 1.00 | root | | |
-| └─HashAgg_27 | 1.00 | root | | funcs:sum(Column#10)->Column#7 |
-| └─IndexLookUp_28 | 1.00 | root | | |
-| ├─IndexRangeScan_25(Build) | 10.00 | cop[tikv] | table:t2, index:idx(b) | range: decided by [eq(test.t2.b, test.t1.b)], keep order:false, stats:pseudo |
-| └─HashAgg_17(Probe) | 1.00 | cop[tikv] | | funcs:sum(test.t2.a)->Column#10 |
-| └─TableRowIDScan_26 | 10.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
+| Projection_10 | 10000.00 | root | | test.t1.a, test.t1.b |
+| └─Apply_12 | 10000.00 | root | | CARTESIAN inner join, other cond:lt(cast(test.t1.a, decimal(10,0) BINARY), Column#7) |
+| ├─TableReader_14(Build) | 10000.00 | root | | data:TableFullScan_13 |
+| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+| └─MaxOneRow_15(Probe) | 10000.00 | root | | |
+| └─StreamAgg_20 | 10000.00 | root | | funcs:sum(Column#14)->Column#7 |
+| └─Projection_45 | 100000.00 | root | | cast(test.t2.a, decimal(10,0) BINARY)->Column#14 |
+| └─IndexLookUp_44 | 100000.00 | root | | |
+| ├─IndexRangeScan_42(Build) | 100000.00 | cop[tikv] | table:t2, index:idx(b) | range: decided by [eq(test.t2.b, test.t1.b)], keep order:false, stats:pseudo |
+| └─TableRowIDScan_43(Probe) | 100000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
```
Disabling the decorrelation rule can also achieve the same effect:
@@ -84,20 +84,20 @@ explain select * from t1 where t1.a < (select sum(t2.a) from t2 where t2.b = t1.
```
```sql
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
-| Projection_10 | 10000.00 | root | | test.t1.a, test.t1.b |
-| └─Apply_12 | 10000.00 | root | | CARTESIAN inner join, other cond:lt(cast(test.t1.a, decimal(10,0) BINARY), Column#7) |
-| ├─TableReader_14(Build) | 10000.00 | root | | data:TableFullScan_13 |
-| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
-| └─MaxOneRow_15(Probe) | 1.00 | root | | |
-| └─HashAgg_27 | 1.00 | root | | funcs:sum(Column#10)->Column#7 |
-| └─IndexLookUp_28 | 1.00 | root | | |
-| ├─IndexRangeScan_25(Build) | 10.00 | cop[tikv] | table:t2, index:idx(b) | range: decided by [eq(test.t2.b, test.t1.b)], keep order:false, stats:pseudo |
-| └─HashAgg_17(Probe) | 1.00 | cop[tikv] | | funcs:sum(test.t2.a)->Column#10 |
-| └─TableRowIDScan_26 | 10.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
+| Projection_10 | 10000.00 | root | | test.t1.a, test.t1.b |
+| └─Apply_12 | 10000.00 | root | | CARTESIAN inner join, other cond:lt(cast(test.t1.a, decimal(10,0) BINARY), Column#7) |
+| ├─TableReader_14(Build) | 10000.00 | root | | data:TableFullScan_13 |
+| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+| └─MaxOneRow_15(Probe) | 10000.00 | root | | |
+| └─StreamAgg_20 | 10000.00 | root | | funcs:sum(Column#14)->Column#7 |
+| └─Projection_45 | 100000.00 | root | | cast(test.t2.a, decimal(10,0) BINARY)->Column#14 |
+| └─IndexLookUp_44 | 100000.00 | root | | |
+| ├─IndexRangeScan_42(Build) | 100000.00 | cop[tikv] | table:t2, index:idx(b) | range: decided by [eq(test.t2.b, test.t1.b)], keep order:false, stats:pseudo |
+| └─TableRowIDScan_43(Probe) | 100000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
```
After disabling the subquery decorrelation rule, you can see `range: decided by [eq(test.t2.b, test.t1.b)]` in `operator info` of `IndexRangeScan_25(Build)`. It means that the decorrelation of correlated subquery is not performed and TiDB uses the index range query.
diff --git a/daily-check.md b/daily-check.md
index 62dd3ded55a8b..6d82b984dd4c9 100644
--- a/daily-check.md
+++ b/daily-check.md
@@ -67,13 +67,13 @@ The time it takes for TiDB to obtain TSO from PD. The following are reasons for
-You can view the load, memory available, network traffic, and I/O utilities. When a bottleneck is found, it is recommended to scale out the capacity, or to optimize the cluster topology, SQL, cluster parameters, etc.
+You can view the load, memory available, network traffic, and I/O utilities. When a bottleneck is found, it is recommended to scale out the capacity, or to optimize the cluster topology, SQL, and cluster parameters.
### Exceptions
-You can view the errors triggered by the execution of SQL statements on each TiDB instance. These include syntax error, primary key conflicts, etc.
+You can view the errors triggered by the execution of SQL statements on each TiDB instance. These include syntax error and primary key conflicts.
### GC status
diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md
index baa49107e5ba8..37c772d46a8a9 100644
--- a/dashboard/dashboard-overview.md
+++ b/dashboard/dashboard-overview.md
@@ -76,7 +76,7 @@ This area summarizes the total number of instances and abnormal instances of TiD
The statuses in the image above are described as follows:
- Up: The instance is running properly (including the offline storage instance).
-- Down: The instance is running abnormally, such as network disconnection, process crash, and so on.
+- Down: The instance is running abnormally, such as network disconnection and process crash.
Click the **Instance** title to enter the [Cluster Info Page](/dashboard/dashboard-cluster-info.md) that shows the detailed running status of each instance.
diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md
index b4c1c08147ef1..389db941175d7 100644
--- a/dashboard/dashboard-profiling.md
+++ b/dashboard/dashboard-profiling.md
@@ -12,7 +12,7 @@ aliases: ['/docs/dev/dashboard/dashboard-profiling/']
Manual Profiling allows users to collect current performance data **on demand** for each TiDB, TiKV, PD and TiFlash instances with a single click. The collected performance data can be visualized as FlameGraph or DAG.
-With these performance data, experts can analyze current resource consumption details like instance's CPU and memory, to help pinpoint sophisticated ongoing performance problems, such as high CPU overhead, high memory usage, process stalls, and so on.
+With these performance data, experts can analyze current resource consumption details like instance's CPU and memory, to help pinpoint sophisticated ongoing performance problems, such as high CPU overhead, high memory usage, and process stalls.
After initiates the profiling, TiDB Dashboard collects current performance data for a period of time (30 seconds by default). Therefore this feature can only be used to analyze ongoing problems that the cluster is facing now and has no significant effect on historical problems. If you want to collect and analyze performance data **at any time**, see [Continuous Profiling](/dashboard/continuous-profiling.md).
diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md
index 5dfec81cd69da..b321e2e231f2b 100644
--- a/data-type-date-and-time.md
+++ b/data-type-date-and-time.md
@@ -90,7 +90,7 @@ DATE
### `TIME` type
-For the `TIME` type, the format is `HH:MM:SS[.fraction]` and valid values range from '-838:59:59.000000' to '838:59:59.000000'. `TIME` is used not only to indicate the time within a day but also to indicate the time interval between 2 events. An optional `fsp` value in the range from 0 to 6 may be given to specify fractional seconds precision. If omitted, the default precision is 0:
+For the `TIME` type, the format is `HH:MM:SS[.fraction]` and valid values range from '-838:59:59.000000' to '838:59:59.000000'. `TIME` is used not only to indicate the time within a day but also to indicate the time interval between 2 events. An optional `fsp` value in the range from 0 to 6 may be given to specify fractional seconds precision. If omitted, the default precision is 0:
```sql
TIME[(fsp)]
@@ -104,7 +104,7 @@ TIME[(fsp)]
`DATETIME` contains both date-portion and time-portion. Valid values range from '0000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999'.
-TiDB displays `DATETIME` values in `YYYY-MM-DD HH:MM:SS[.fraction]` format, but permits assignment of values to `DATETIME` columns using either strings or numbers. An optional fsp value in the range from 0 to 6 may be given to specify fractional seconds precision. If omitted, the default precision is 0:
+TiDB displays `DATETIME` values in `YYYY-MM-DD HH:MM:SS[.fraction]` format, but permits assignment of values to `DATETIME` columns using either strings or numbers. An optional fsp value in the range from 0 to 6 may be given to specify fractional seconds precision. If omitted, the default precision is 0:
```sql
DATETIME[(fsp)]
@@ -122,7 +122,7 @@ TIMESTAMP[(fsp)]
#### Timezone Handling
-When `TIMESTAMP` is to be stored, TiDB converts the `TIMESTAMP` value from the current time zone to UTC time zone. When `TIMESTAMP` is to be retrieved, TiDB converts the stored `TIMESTAMP` value from UTC time zone to the current time zone (Note: `DATETIME` is not handled in this way). The default time zone for each connection is the server's local time zone, which can be modified by the environment variable `time_zone`.
+When `TIMESTAMP` is to be stored, TiDB converts the `TIMESTAMP` value from the current time zone to UTC time zone. When `TIMESTAMP` is to be retrieved, TiDB converts the stored `TIMESTAMP` value from UTC time zone to the current time zone (Note: `DATETIME` is not handled in this way). The default time zone for each connection is the server's local time zone, which can be modified by the environment variable `time_zone`.
> **Warning:**
>
@@ -259,4 +259,4 @@ When numeral `00` is inserted to `YEAR(4)`, the result is 0000 rather than 2000.
If you want the result to be 2000, specify the value to be 2000.
-The two-digit year-portion might not be properly calculated in some functions such `MIN()` and `MAX()`. For these functions, the four-digit format suites better.
+The two-digit year-portion might not be properly calculated in some functions such `MIN()` and `MAX()`. For these functions, the four-digit format suites better.
diff --git a/data-type-json.md b/data-type-json.md
index 7a40ed924a510..15a8d2fbdf1d4 100644
--- a/data-type-json.md
+++ b/data-type-json.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/data-type-json/','/docs/dev/reference/sql/data-types/json/'
# JSON Type
-TiDB supports the `JSON` (JavaScript Object Notation) data type, which is useful for storing semi-structured data. The `JSON` data type provides the following advantages over storing `JSON`-format strings in a string column:
+TiDB supports the `JSON` (JavaScript Object Notation) data type, which is useful for storing semi-structured data. The `JSON` data type provides the following advantages over storing `JSON`-format strings in a string column:
- Use the Binary format for serialization. The internal format permits quick read access to `JSON` document elements.
- Automatic validation of the JSON documents stored in `JSON` columns. Only valid documents can be stored.
diff --git a/data-type-overview.md b/data-type-overview.md
index bc0adfe045dc5..d0fe1b8c59586 100644
--- a/data-type-overview.md
+++ b/data-type-overview.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/data-type-overview/','/docs/dev/reference/sql/data-types/ov
# Data Types
-TiDB supports all the data types in MySQL except the `SPATIAL` type. This includes all the [numeric types](/data-type-numeric.md), [string types](/data-type-string.md), [date & time types](/data-type-date-and-time.md), and [the JSON type](/data-type-json.md).
+TiDB supports all the data types in MySQL except the `SPATIAL` type. This includes all the [numeric types](/data-type-numeric.md), [string types](/data-type-string.md), [date & time types](/data-type-date-and-time.md), and [the JSON type](/data-type-json.md).
The definitions used for datatypes are specified as `T(M[, D])`. Where by:
diff --git a/data-type-string.md b/data-type-string.md
index fb39f07e53956..2b4fc5289aecb 100644
--- a/data-type-string.md
+++ b/data-type-string.md
@@ -38,7 +38,7 @@ The space occupied by a single character might differ for different character se
### `TEXT` type
-`TEXT` is a string of variable-length. M represents the maximum column length in characters, ranging from 0 to 65,535. The maximum row length and the character set being used determine the `TEXT` length.
+`TEXT` is a string of variable-length. The maximum column length is 65,535 bytes. The optional M argument is in characters and is used to automatically select the fittest type of a `TEXT` column. For example `TEXT(60)` will yield a `TINYTEXT` data type that can hold up to 255 bytes, which fits a 60-character UTF-8 string that has up to 4 bytes per character (4×60=240). Using the M argument is not recommended.
```sql
TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name]
@@ -54,7 +54,7 @@ TINYTEXT [CHARACTER SET charset_name] [COLLATE collation_name]
### `MEDIUMTEXT` type
-The `MEDIUMTEXT` type is similar to the [`TEXT` type](#text-type). The difference is that the maximum column length of `MEDIUMTEXT` is 16,777,215.
+The `MEDIUMTEXT` type is similar to the [`TEXT` type](#text-type). The difference is that the maximum column length of `MEDIUMTEXT` is 16,777,215. But due to the [Limitation on a single column in TiDB](/tidb-limitations.md#limitation-on-a-single-column), the maximum storage size of a single column in TiDB is 6 MiB by default and can be increased to 120 MiB by changing the configuration.
```sql
MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name]
@@ -62,7 +62,7 @@ MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name]
### `LONGTEXT` type
-The `LONGTEXT` type is similar to the [`TEXT` type](#text-type). The difference is that the maximum column length of `LONGTEXT` is 4,294,967,295. But due to the [Limitation on a single column in TiDB](/tidb-limitations.md#limitation-on-a-single-column), the maximum storage size of a single column in TiDB is 6 MB.
+The `LONGTEXT` type is similar to the [`TEXT` type](#text-type). The difference is that the maximum column length of `LONGTEXT` is 4,294,967,295. But due to the [Limitation on a single column in TiDB](/tidb-limitations.md#limitation-on-a-single-column), the maximum storage size of a single column in TiDB is 6 MiB by default and can be increased to 120 MiB by changing the configuration.
```sql
LONGTEXT [CHARACTER SET charset_name] [COLLATE collation_name]
@@ -102,7 +102,7 @@ TINYBLOB
### `MEDIUMBLOB` type
-The `MEDIUMBLOB` type is similar to the [`BLOB` type](#blob-type). The difference is that the maximum column length of `MEDIUMBLOB` is 16,777,215.
+The `MEDIUMBLOB` type is similar to the [`BLOB` type](#blob-type). The difference is that the maximum column length of `MEDIUMBLOB` is 16,777,215. But due to the [Limitation on a single column in TiDB](/tidb-limitations.md#limitation-on-a-single-column), the maximum storage size of a single column in TiDB is 6 MiB by default and can be increased to 120 MiB by changing the configuration.
```sql
MEDIUMBLOB
@@ -110,7 +110,7 @@ MEDIUMBLOB
### `LONGBLOB` type
-The `LONGBLOB` type is similar to the [`BLOB` type](#blob-type). The difference is that the maximum column length of `LONGBLOB` is 4,294,967,295. But due to the [Limitation on a single column in TiDB](/tidb-limitations.md#limitation-on-a-single-column), the maximum storage size of a single column in TiDB is 6 MB.
+The `LONGBLOB` type is similar to the [`BLOB` type](#blob-type). The difference is that the maximum column length of `LONGBLOB` is 4,294,967,295. But due to the [Limitation on a single column in TiDB](/tidb-limitations.md#limitation-on-a-single-column), the maximum storage size of a single column in TiDB is 6 MiB by default and can be increased to 120 MiB by changing the configuration.
```sql
LONGBLOB
diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md
index ac46f4a6c76c3..1d3c26b95ee9c 100644
--- a/develop/dev-guide-choose-driver-or-orm.md
+++ b/develop/dev-guide-choose-driver-or-orm.md
@@ -109,12 +109,12 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67
> **Note:**
>
> - Currently, Hibernate does [not support nested transactions](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres).
->
->
->
+
+
+
> - Since v6.2.0, TiDB supports [savepoint](/sql-statements/sql-statement-savepoint.md). To use the `Propagation.NESTED` transaction propagation option in `@Transactional`, that is, to set `@Transactional(propagation = Propagation.NESTED)`, make sure that your TiDB is v6.2.0 or later.
->
->
+
+
diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md
index 96052d518b919..06d9a268f602b 100644
--- a/develop/dev-guide-create-table.md
+++ b/develop/dev-guide-create-table.md
@@ -215,7 +215,7 @@ CREATE TABLE `bookshop`.`ratings` (
If you need to prevent duplicate values in a column, you can use the `UNIQUE` constraint.
-For example, to make sure that users' nicknames are unique, you can rewrite the table creation SQL statement for the `users` table like this:
+For example, to make sure that users' nicknames are unique, you can rewrite the table creation SQL statement for the `users` table like this:
{{< copyable "sql" >}}
diff --git a/develop/dev-guide-delete-data.md b/develop/dev-guide-delete-data.md
index ed3f0c7336645..add694031fd75 100644
--- a/develop/dev-guide-delete-data.md
+++ b/develop/dev-guide-delete-data.md
@@ -60,7 +60,7 @@ Suppose you find an application error within a specific time period and you need
{{< copyable "sql" >}}
```sql
-SELECT COUNT(*) FROM `ratings` WHERE `rated_at` >= "2022-04-15 00:00:00" AND `rated_at` <= "2022-04-15 00:15:00";
+SELECT COUNT(*) FROM `ratings` WHERE `rated_at` >= "2022-04-15 00:00:00" AND `rated_at` <= "2022-04-15 00:15:00";
```
If more than 10,000 records are returned, use [Bulk-Delete](#bulk-delete) to delete them.
@@ -73,7 +73,7 @@ If fewer than 10,000 records are returned, use the following example to delete t
In SQL, the example is as follows:
```sql
-DELETE FROM `ratings` WHERE `rated_at` >= "2022-04-15 00:00:00" AND `rated_at` <= "2022-04-15 00:15:00";
+DELETE FROM `ratings` WHERE `rated_at` >= "2022-04-15 00:00:00" AND `rated_at` <= "2022-04-15 00:15:00";
```
@@ -86,7 +86,7 @@ In Java, the example is as follows:
// ds is an entity of com.mysql.cj.jdbc.MysqlDataSource
try (Connection connection = ds.getConnection()) {
- String sql = "DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ?";
+ String sql = "DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ?";
PreparedStatement preparedStatement = connection.prepareStatement(sql);
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.MILLISECOND, 0);
@@ -130,7 +130,7 @@ func main() {
startTime := time.Date(2022, 04, 15, 0, 0, 0, 0, time.UTC)
endTime := time.Date(2022, 04, 15, 0, 15, 0, 0, time.UTC)
- bulkUpdateSql := fmt.Sprintf("DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ?")
+ bulkUpdateSql := fmt.Sprintf("DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ?")
result, err := db.Exec(bulkUpdateSql, startTime, endTime)
if err != nil {
panic(err)
@@ -241,7 +241,7 @@ public class BatchDeleteExample
public static void batchDelete (MysqlDataSource ds) {
try (Connection connection = ds.getConnection()) {
- String sql = "DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ? LIMIT 1000";
+ String sql = "DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ? LIMIT 1000";
PreparedStatement preparedStatement = connection.prepareStatement(sql);
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.MILLISECOND, 0);
@@ -303,7 +303,7 @@ func main() {
// deleteBatch delete at most 1000 lines per batch
func deleteBatch(db *sql.DB, startTime, endTime time.Time) (int64, error) {
- bulkUpdateSql := fmt.Sprintf("DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ? LIMIT 1000")
+ bulkUpdateSql := fmt.Sprintf("DELETE FROM `bookshop`.`ratings` WHERE `rated_at` >= ? AND `rated_at` <= ? LIMIT 1000")
result, err := db.Exec(bulkUpdateSql, startTime, endTime)
if err != nil {
return -1, err
diff --git a/develop/dev-guide-implicit-type-conversion.md b/develop/dev-guide-implicit-type-conversion.md
index fcbbf5a5067ee..6c50656403748 100644
--- a/develop/dev-guide-implicit-type-conversion.md
+++ b/develop/dev-guide-implicit-type-conversion.md
@@ -9,7 +9,7 @@ This document introduces the rules and possible consequences of implicit type co
## Conversion rules
-When the data types on the two sides of the predicate in a SQL statement do not match, TiDB implicitly convert the data types on one or both sides to a compatible data type for predicate operations.
+When the data types on the two sides of the predicate in a SQL statement do not match, TiDB implicitly convert the data types on one or both sides to a compatible data type for predicate operations.
The rules for implicit type conversion in TiDB are as follows:
diff --git a/develop/dev-guide-optimistic-and-pessimistic-transaction.md b/develop/dev-guide-optimistic-and-pessimistic-transaction.md
index cb4e219cb2f4c..aed3fa6d6d024 100644
--- a/develop/dev-guide-optimistic-and-pessimistic-transaction.md
+++ b/develop/dev-guide-optimistic-and-pessimistic-transaction.md
@@ -821,7 +821,7 @@ The following code uses two threads to simulate the process that two users buy t
### Write an optimistic transaction example
-
+
diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md
index 03750ce20c5b8..ba8747b43879e 100644
--- a/develop/dev-guide-paginate-results.md
+++ b/develop/dev-guide-paginate-results.md
@@ -24,7 +24,7 @@ When pagination is used, it is recommended that you sort query results with the
-For example, to let users of the [Bookshop](/develop/dev-guide-bookshop-schema-design.md) application view the latest published books in a paginated manner, you can use the `LIMIT 0, 10` statement, which returns the first page of the result list, with a maximum of 10 records per page. To get the second page, you can change the statement to `LIMIT 10, 10`, and so on.
+For example, to let users of the [Bookshop](/develop/dev-guide-bookshop-schema-design.md) application view the latest published books in a paginated manner, you can use the `LIMIT 0, 10` statement, which returns the first page of the result list, with a maximum of 10 records per page. To get the second page, you can change the statement to `LIMIT 10, 10`.
{{< copyable "sql" >}}
diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md
index 8a964bfcef70d..520153e8e9416 100644
--- a/develop/dev-guide-third-party-tools-compatibility.md
+++ b/develop/dev-guide-third-party-tools-compatibility.md
@@ -156,3 +156,55 @@ TiDB fixes it in the following ways:
- Client side: This bug has been fixed in **pingcap/mysql-connector-j** and you can use the [pingcap/mysql-connector-j](https://github.com/pingcap/mysql-connector-j) instead of the official MySQL Connector/J.
- Server side: This compatibility issue has been fixed since TiDB v6.3.0 and you can upgrade the server to v6.3.0 or later versions.
+
+## Compatibility with Sequelize
+
+The compatibility information described in this section is based on [Sequelize v6.21.4](https://www.npmjs.com/package/sequelize/v/6.21.4).
+
+According to the test results, TiDB supports most of the Sequelize features ([using `MySQL` as the dialect](https://sequelize.org/docs/v6/other-topics/dialect-specific-things/#mysql)).
+
+Unsupported features are:
+
+- Foreign key constraints (including many-to-many relationships) are not supported.
+- [`GEOMETRY`](https://github.com/pingcap/tidb/issues/6347) is not supported.
+- Modification of integer primary key is not supported.
+- `PROCEDURE` is not supported.
+- The `READ-UNCOMMITTED` and `SERIALIZABLE` [isolation levels](/system-variables.md#transaction_isolation) are not supported.
+- Modification of a column's `AUTO_INCREMENT` attribute is not allowed by default.
+- `FULLTEXT`, `HASH`, and `SPATIAL` indexes are not supported.
+
+### Modification of integer primary key is not supported
+
+**Description**
+
+Modification of integer primary key is not supported. TiDB uses primary key as an index for data organization if the primary key is integer type. Refer to [Issue #18090](https://github.com/pingcap/tidb/issues/18090) and [Clustered Indexes](/clustered-indexes.md) for more details.
+
+### The `READ-UNCOMMITTED` and `SERIALIZABLE` isolation levels are not supported
+
+**Description**
+
+TiDB does not support the `READ-UNCOMMITTED` and `SERIALIZABLE` isolation levels. If the isolation level is set to `READ-UNCOMMITTED` or `SERIALIZABLE`, TiDB throws an error.
+
+**Way to avoid**
+
+Use only the isolation level that TiDB supports: `REPEATABLE-READ` or `READ-COMMITTED`.
+
+If you want TiDB to be compatible with other applications that set the `SERIALIZABLE` isolation level but not depend on `SERIALIZABLE`, you can set [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check) to `1`. In such case, TiDB ignores the unsupported isolation level error.
+
+### Modification of a column's `AUTO_INCREMENT` attribute is not allowed by default
+
+**Description**
+
+Adding or removing the `AUTO_INCREMENT` attribute of a column via `ALTER TABLE MODIFY` or `ALTER TABLE CHANGE` command is not allowed by default.
+
+**Way to avoid**
+
+Refer to the [restrictions of `AUTO_INCREMENT`](/auto-increment.md#restrictions).
+
+To allow the removal of the `AUTO_INCREMENT` attribute, set `@@tidb_allow_remove_auto_inc` to `true`.
+
+### `FULLTEXT`, `HASH`, and `SPATIAL` indexes are not supported
+
+**Description**
+
+`FULLTEXT`, `HASH`, and `SPATIAL` indexes are not supported.
diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md
index dc57d5830b661..03190b406d9e6 100644
--- a/develop/dev-guide-transaction-overview.md
+++ b/develop/dev-guide-transaction-overview.md
@@ -54,7 +54,7 @@ After the above transaction is executed successfully, the table should look like
### Start a transaction
-To explicitly start a new transaction, you can use either `BEGIN` or `START TRANSACTION`.
+To explicitly start a new transaction, you can use either `BEGIN` or `START TRANSACTION`.
{{< copyable "sql" >}}
diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md
index c38618d270076..dddfb81835afe 100644
--- a/dm/dm-best-practices.md
+++ b/dm/dm-best-practices.md
@@ -65,7 +65,7 @@ When you create a table, you can declare that the primary key is either a cluste
```sql
CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM, b varchar(255));
- Select a, a<<5 ,b from t order by a <<5 desc
+ Select a, a<<5 ,b from t order by a <<5 desc
```
The following table summarizes the pros and cons of each solution.
@@ -182,7 +182,7 @@ You can configure the filter rules as soon as you start configuring the data sou
> **Note:**
>
-> When you migrate and merge MySQL shards, if you have configured filter rules in the data source, you must make sure that the rules match between the data source and the migration task. If they do not match, it may cause the issue that the migration task can not receive incremental data for a long time.
+> When you migrate and merge MySQL shards, if you have configured filter rules in the data source, you must make sure that the rules match between the data source and the migration task. If they do not match, it may cause the issue that the migration task cannot receive incremental data for a long time.
#### Use the relay log
diff --git a/dm/dm-enable-tls.md b/dm/dm-enable-tls.md
index 9e3fb4693cfc9..aee3506601dd0 100644
--- a/dm/dm-enable-tls.md
+++ b/dm/dm-enable-tls.md
@@ -109,7 +109,7 @@ This section introduces how to enable encrypted data transmission between DM com
### Enable encrypted data transmission for downstream TiDB
-1. Configure the downstream TiDB to use encrypted connections. For detailed operatons, refer to [Configure TiDB server to use secure connections](/enable-tls-between-clients-and-servers.md#configure-tidb-server-to-use-secure-connections).
+1. Configure the downstream TiDB to use encrypted connections. For detailed operatons, refer to [Configure TiDB server to use secure connections](/enable-tls-between-clients-and-servers.md#configure-tidb-server-to-use-secure-connections).
2. Set the TiDB client certificate in the task configuration file:
diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md
index 9dbcacdea1e4e..dfb3cd9d87d7a 100644
--- a/dm/dm-error-handling.md
+++ b/dm/dm-error-handling.md
@@ -97,8 +97,8 @@ However, you need to reset the data migration task in some cases. For details, r
|
Error Code
| Error Description | How to Handle |
| :----------- | :------------------------------------------------------------ | :----------------------------------------------------------- |
| `code=10001` | Abnormal database operation. | Further analyze the error message and error stack. |
-| `code=10002` | The `bad connection` error from the underlying database. It usually indicates that the connection between DM and the downstream TiDB instance is abnormal (possibly caused by network failure, TiDB restart and so on) and the currently requested data is not sent to TiDB. | DM provides automatic recovery for such error. If the recovery is not successful for a long time, check the network or TiDB status. |
-| `code=10003` | The `invalid connection` error from the underlying database. It usually indicates that the connection between DM and the downstream TiDB instance is abnormal (possibly caused by network failure, TiDB restart and so on) and the currently requested data is partly sent to TiDB. | DM provides automatic recovery for such error. If the recovery is not successful for a long time, further check the error message and analyze the information based on the actual situation. |
+| `code=10002` | The `bad connection` error from the underlying database. It usually indicates that the connection between DM and the downstream TiDB instance is abnormal (possibly caused by network failure or TiDB restart) and the currently requested data is not sent to TiDB. | DM provides automatic recovery for such error. If the recovery is not successful for a long time, check the network or TiDB status. |
+| `code=10003` | The `invalid connection` error from the underlying database. It usually indicates that the connection between DM and the downstream TiDB instance is abnormal (possibly caused by network failure or TiDB restart) and the currently requested data is partly sent to TiDB. | DM provides automatic recovery for such error. If the recovery is not successful for a long time, further check the error message and analyze the information based on the actual situation. |
| `code=10005` | Occurs when performing the `QUERY` type SQL statements. | |
| `code=10006` | Occurs when performing the `EXECUTE` type SQL statements, including DDL statements and DML statements of the `INSERT`, `UPDATE`or `DELETE` type. For more detailed error information, check the error message which usually includes the error code and error information returned for database operations.
| |
@@ -112,7 +112,7 @@ However, you need to reset the data migration task in some cases. For details, r
#### Reason
-The `invalid connection` error indicates that anomalies have occurred in the connection between DM and the downstream TiDB database (such as network failure, TiDB restart, TiKV busy and so on) and that a part of the data for the current request has been sent to TiDB.
+The `invalid connection` error indicates that anomalies have occurred in the connection between DM and the downstream TiDB database (such as network failure, TiDB restart, and TiKV busy) and that a part of the data for the current request has been sent to TiDB.
#### Solutions
@@ -125,7 +125,7 @@ Because DM has the feature of concurrently migrating data to the downstream in m
#### Reason
-The `driver: bad connection` error indicates that anomalies have occurred in the connection between DM and the upstream TiDB database (such as network failure, TiDB restart and so on) and that the data of the current request has not yet been sent to TiDB at that moment.
+The `driver: bad connection` error indicates that anomalies have occurred in the connection between DM and the upstream TiDB database (such as network failure and TiDB restart) and that the data of the current request has not yet been sent to TiDB at that moment.
#### Solution
diff --git a/dm/dm-faq.md b/dm/dm-faq.md
index 777c3487e88e5..2ed0424b03628 100644
--- a/dm/dm-faq.md
+++ b/dm/dm-faq.md
@@ -109,7 +109,7 @@ Record the position information in the global checkpoint (`is_global=1`) corresp
- The checkpoint rows to be updated match `id=(source-id)` and `is_global=1`.
- - The checkpoint columns to be updated are `binlog_name` and `binlog_pos`.
+ - The checkpoint columns to be updated are `binlog_name` and `binlog_pos`.
3. Set `safe-mode: true` for the `syncers` in the task to ensure reentrant execution.
@@ -351,7 +351,7 @@ For data sources that can be replicated normally (such as `mysql2` in the above
## In DM v2.0, how do I handle the error "heartbeat config is different from previous used: serverID not equal" when switching the connection between DM-workers and MySQL instances in a virtual IP environment with the `heartbeat` feature enabled?
-The `heartbeat` feature is disabled by default in DM v2.0 and later versions. If you enable the feature in the task configuration file, it interferes with the high availability feature. To solve this issue, you can disable the `heartbeat` feature by setting `enable-heartbeat` to `false` in the task configuration file, and then reload the task configuration file. DM will forcibly disable the `heartbeat` feature in subsequent releases.
+The `heartbeat` feature is disabled by default in DM v2.0 and later versions. If you enable the feature in the task configuration file, it interferes with the high availability feature. To solve this issue, you can disable the `heartbeat` feature by setting `enable-heartbeat` to `false` in the task configuration file, and then reload the task configuration file. DM will forcibly disable the `heartbeat` feature in subsequent releases.
## Why does a DM-master fail to join the cluster after it restarts and DM reports the error "fail to start embed etcd, RawCause: member xxx has already been bootstrapped"?
diff --git a/dm/dm-handle-alerts.md b/dm/dm-handle-alerts.md
index 2a0b9eaa8ef93..2ed1b231aa36c 100644
--- a/dm/dm-handle-alerts.md
+++ b/dm/dm-handle-alerts.md
@@ -162,7 +162,7 @@ This document introduces how to deal with the alert information in DM.
- Description:
- When the binlog replication processing unit encounters an error, this unit moves to the `Paused` state, and an alert is triggered immediately.
+ When the binlog replication processing unit encounters an error, this unit moves to the `Paused` state, and an alert is triggered immediately.
- Solution:
diff --git a/dm/dm-hardware-and-software-requirements.md b/dm/dm-hardware-and-software-requirements.md
index afd2ce3fe4978..eb384aa2ee6e9 100644
--- a/dm/dm-hardware-and-software-requirements.md
+++ b/dm/dm-hardware-and-software-requirements.md
@@ -70,5 +70,5 @@ You can estimate the data volume by using the following SQL statements to summar
{{< copyable "sql" >}}
```sql
- select table_name,table_schema,sum(data_length)/1024/1024 as data_length,sum(index_length)/1024/1024 as index_length,sum(data_length+index_length)/1024/1024 as sum from information_schema.tables where table_schema = "${schema_name}" group by table_name,table_schema order by sum desc limit 5;
+ select table_name,table_schema,sum(data_length)/1024/1024 as data_length,sum(index_length)/1024/1024 as index_length,sum(data_length+index_length)/1024/1024 as sum from information_schema.tables where table_schema = "${schema_name}" group by table_name,table_schema order by sum desc limit 5;
```
\ No newline at end of file
diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md
index 08449bb367e76..720d635eb3ca7 100644
--- a/dm/dm-manage-schema.md
+++ b/dm/dm-manage-schema.md
@@ -1,9 +1,9 @@
---
-title: Manage Table Schemas of Tables to be Migrated using TiDB Data Migration
+title: Manage Table Schemas of Tables to Be Migrated Using TiDB Data Migration
summary: Learn how to manage the schema of the table to be migrated in DM.
---
-# Manage Table Schemas of Tables to be Migrated using TiDB Data Migration
+# Manage Table Schemas of Tables to Be Migrated Using TiDB Data Migration
This document describes how to manage the schema of the table in DM during migration using [dmctl](/dm/dmctl-introduction.md).
diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md
index ca897de053d02..06a6bc4600df2 100644
--- a/dm/dm-performance-test.md
+++ b/dm/dm-performance-test.md
@@ -164,4 +164,4 @@ sysbench --test=oltp_insert --tables=4 --num-threads=32 --mysql-host=172.17.4.40
#### Get test results
-To observe the migration status of DM, you can run the `query-status` command. To observe the monitoring metrics of DM, you can use Grafana. Here the monitoring metrics refer to `finished sqls jobs` (the number of jobs finished per unit time), etc. For more information, see [Binlog Migration Monitoring Metrics](/dm/monitor-a-dm-cluster.md#binlog-replication).
+To observe the migration status of DM, you can run the `query-status` command. To observe the monitoring metrics of DM, you can use Grafana. Here the monitoring metrics refer to `finished sqls jobs` (the number of jobs finished per unit time), and other related metrics. For more information, see [Binlog Migration Monitoring Metrics](/dm/monitor-a-dm-cluster.md#binlog-replication).
diff --git a/dm/dm-worker-intro.md b/dm/dm-worker-intro.md
index b43c8181a9ff6..76429c4ed457e 100644
--- a/dm/dm-worker-intro.md
+++ b/dm/dm-worker-intro.md
@@ -79,7 +79,7 @@ The downstream database (TiDB) user must have the following privileges:
Execute the following `GRANT` statement for the databases or tables that you need to migrate:
```sql
-GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX ON db.table TO 'your_user'@'your_wildcard_of_host';
+GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX ON db.table TO 'your_user'@'your_wildcard_of_host';
```
### Minimal privilege required by each processing unit
diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md
index 03264505d116e..d4e52b7f4aed2 100644
--- a/dm/feature-online-ddl.md
+++ b/dm/feature-online-ddl.md
@@ -132,7 +132,7 @@ The SQL statements mostly used by pt-osc and the corresponding operation of DM a
```sql
CREATE TABLE `test`.`_test4_new` ( id int(11) NOT NULL AUTO_INCREMENT,
- date date DEFAULT NULL, account_id bigint(20) DEFAULT NULL, conversion_price decimal(20,3) DEFAULT NULL, ocpc_matched_conversions bigint(20) DEFAULT NULL, ad_cost decimal(20,3) DEFAULT NULL,cl2 varchar(20) COLLATE utf8mb4_bin NOT NULL,cl1 varchar(20) COLLATE utf8mb4_bin NOT NULL,PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ;
+ date date DEFAULT NULL, account_id bigint(20) DEFAULT NULL, conversion_price decimal(20,3) DEFAULT NULL, ocpc_matched_conversions bigint(20) DEFAULT NULL, ad_cost decimal(20,3) DEFAULT NULL,cl2 varchar(20) COLLATE utf8mb4_bin NOT NULL,cl1 varchar(20) COLLATE utf8mb4_bin NOT NULL,PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ;
```
DM does not create the `_test4_new` table. DM deletes the `dm_meta.{task_name}_onlineddl` record in the downstream according to `ghost_schema`, `ghost_table`, and the `server_id` of `dm_worker`, and clears the related information in memory.
diff --git a/dm/feature-shard-merge.md b/dm/feature-shard-merge.md
index 1e1f2771fb905..7bc428738efab 100644
--- a/dm/feature-shard-merge.md
+++ b/dm/feature-shard-merge.md
@@ -14,7 +14,7 @@ DM supports merging and migrating the data of multiple upstream sharded tables i
> **Note:**
>
-> - To merge and migrate data from sharded tables, you must set `shard-mode` in the task configuration file.
+> - To merge and migrate data from sharded tables, you must set `shard-mode` in the task configuration file.
> - DM uses the pessimistic mode by default for the merge of the sharding support feature. (If there is no special description in the document, use the pessimistic mode by default.)
> - It is not recommended to use this mode if you do not understand the principles and restrictions of the optimistic mode. Otherwise, it may cause serious consequences such as migration interruption and even data inconsistency.
diff --git a/dm/manually-upgrade-dm-1.0-to-2.0.md b/dm/manually-upgrade-dm-1.0-to-2.0.md
index bbc68e57dbfde..25d6b22fb5360 100644
--- a/dm/manually-upgrade-dm-1.0-to-2.0.md
+++ b/dm/manually-upgrade-dm-1.0-to-2.0.md
@@ -13,7 +13,7 @@ For how to automatically upgrade the TiDB DM tool from v1.0.x to v2.0+, refer to
>
> - Currently, upgrading DM from v1.0.x to v2.0+ is not supported when the data migration task is in the process of full export or full import.
> - As the gRPC protocol used for interaction between the components of the DM cluster is updated greatly, you need to make sure that the DM components (including dmctl) use the same version before and after the upgrade.
-> - Because the metadata storage of the DM cluster (such as checkpoint, shard DDL lock status and online DDL metadata, etc.) is updated greatly, the metadata of v1.0.x cannot be reused automatically in v2.0+. So you need to make sure the following requirements are satisfied before performing the upgrade operation:
+> - Because the metadata storage of the DM cluster (such as checkpoint, shard DDL lock status, and online DDL metadata) is updated greatly, the metadata of v1.0.x cannot be reused automatically in v2.0+. So you need to make sure the following requirements are satisfied before performing the upgrade operation:
> - All data migration tasks are not in the process of shard DDL coordination.
> - All data migration tasks are not in the process of online DDL coordination.
diff --git a/dumpling-overview.md b/dumpling-overview.md
index d6f505ef98b9a..69183e3267245 100644
--- a/dumpling-overview.md
+++ b/dumpling-overview.md
@@ -91,7 +91,7 @@ dumpling \
In the command above:
-+ The `-h`, `-p`, and `-u` option respectively mean the address, the port, and the user. If a password is required for authentication, you can use `-p $YOUR_SECRET_PASSWORD` to pass the password to Dumpling.
++ The `-h`, `-P`, and `-u` option respectively mean the address, the port, and the user. If a password is required for authentication, you can use `-p $YOUR_SECRET_PASSWORD` to pass the password to Dumpling.
diff --git a/dynamic-config.md b/dynamic-config.md
index da7fc2afc955d..71e47111ab8d5 100644
--- a/dynamic-config.md
+++ b/dynamic-config.md
@@ -1,18 +1,18 @@
---
-title: Modify Configuration Online
-summary: Learn how to change the cluster configuration online.
+title: Modify Configuration Dynamically
+summary: Learn how to dynamically modify the cluster configuration.
aliases: ['/docs/dev/dynamic-config/']
---
-# Modify Configuration Online
+# Modify Configuration Dynamically
-This document describes how to modify the cluster configuration online.
+This document describes how to dynamically modify the cluster configuration.
-You can update the configuration of components (including TiDB, TiKV, and PD) online using SQL statements, without restarting the cluster components. Currently, the method of changing TiDB instance configuration is different from that of changing configuration of other components (such TiKV and PD).
+You can dynamically update the configuration of components (including TiDB, TiKV, and PD) using SQL statements, without restarting the cluster components. Currently, the method of changing TiDB instance configuration is different from that of changing configuration of other components (such TiKV and PD).
## Common Operations
-This section describes the common operations of modifying configuration online.
+This section describes the common operations of dynamically modifying configuration.
### View instance configuration
@@ -50,11 +50,11 @@ show config where name like '%log%'
show config where type='tikv' and name='log.level'
```
-### Modify TiKV configuration online
+### Modify TiKV configuration dynamically
> **Note:**
>
-> - After changing TiKV configuration items online, the TiKV configuration file is automatically updated. However, you also need to modify the corresponding configuration items by executing `tiup edit-config`; otherwise, operations such as `upgrade` and `reload` will overwrite your changes. For details of modifying configuration items, refer to [Modify configuration using TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration).
+> - After dynamically changing TiKV configuration items, the TiKV configuration file is automatically updated. However, you also need to modify the corresponding configuration items by executing `tiup edit-config`; otherwise, operations such as `upgrade` and `reload` will overwrite your changes. For details of modifying configuration items, refer to [Modify configuration using TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration).
> - After executing `tiup edit-config`, you do not need to execute `tiup reload`.
When using the `set config` statement, you can modify the configuration of a single instance or of all instances according to the instance address or the component type.
@@ -118,7 +118,7 @@ If some modifications fail, you need to re-execute the corresponding statement o
If a configuration item is successfully modified, the result is persisted in the configuration file, which will prevail in the subsequent operations. The names of some configuration items might conflict with TiDB reserved words, such as `limit` and `key`. For these configuration items, use backtick `` ` `` to enclose them. For example, `` `raftstore.raft-log-gc-size-limit` ``.
-The following TiKV configuration items can be modified online:
+The following TiKV configuration items can be modified dynamically:
| Configuration item | Description |
| :--- | :--- |
@@ -231,7 +231,7 @@ In the table above, parameters with the `{db-name}` or `{db-name}.{cf-name}` pre
For detailed parameter description, refer to [TiKV Configuration File](/tikv-configuration-file.md).
-### Modify PD configuration online
+### Modify PD configuration dynamically
Currently, PD does not support the separate configuration for each instance. All PD instances share the same configuration.
@@ -251,7 +251,7 @@ Query OK, 0 rows affected (0.01 sec)
If a configuration item is successfully modified, the result is persisted in etcd instead of in the configuration file; the configuration in etcd will prevail in the subsequent operations. The names of some configuration items might conflict with TiDB reserved words. For these configuration items, use backtick `` ` `` to enclose them. For example, `` `schedule.leader-schedule-limit` ``.
-The following PD configuration items can be modified online:
+The following PD configuration items can be modified dynamically:
| Configuration item | Description |
| :--- | :--- |
@@ -263,7 +263,7 @@ The following PD configuration items can be modified online:
| `schedule.split-merge-interval` | Determines the time interval of performing split and merge operations on the same Region |
| `schedule.max-snapshot-count` | Determines the maximum number of snapshots that a single store can send or receive at the same time |
| `schedule.max-pending-peer-count` | Determines the maximum number of pending peers in a single store |
-| `schedule.max-store-down-time` | The downtime after which PD judges that the disconnected store can not be recovered |
+| `schedule.max-store-down-time` | The downtime after which PD judges that the disconnected store cannot be recovered |
| `schedule.leader-schedule-policy` | Determines the policy of Leader scheduling |
| `schedule.leader-schedule-limit` | The number of Leader scheduling tasks performed at the same time |
| `schedule.region-schedule-limit` | The number of Region scheduling tasks performed at the same time |
@@ -294,11 +294,11 @@ The following PD configuration items can be modified online:
For detailed parameter description, refer to [PD Configuration File](/pd-configuration-file.md).
-### Modify TiDB configuration online
+### Modify TiDB configuration dynamically
Currently, the method of changing TiDB configuration is different from that of changing TiKV and PD configurations. You can modify TiDB configuration by using [system variables](/system-variables.md).
-The following example shows how to modify `slow-threshold` online by using the `tidb_slow_log_threshold` variable.
+The following example shows how to dynamically modify `slow-threshold` by using the `tidb_slow_log_threshold` variable.
The default value of `slow-threshold` is 300 ms. You can set it to 200 ms by using `tidb_slow_log_threshold`.
@@ -327,7 +327,7 @@ select @@tidb_slow_log_threshold;
1 row in set (0.00 sec)
```
-The following TiDB configuration items can be modified online:
+The following TiDB configuration items can be modified dynamically:
| Configuration item | SQL variable | Description |
| :--- | :--- |
@@ -335,7 +335,7 @@ The following TiDB configuration items can be modified online:
| `log.slow-threshold` | `tidb_slow_log_threshold` | The threshold of slow log |
| `log.expensive-threshold` | `tidb_expensive_query_time_threshold` | The threshold of a expensive query |
-### Modify TiFlash configuration online
+### Modify TiFlash configuration dynamically
Currently, you can modify the TiFlash configuration `max_threads` by using the system variable [`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610), which specifies the maximum concurrency for TiFlash to execute a request.
diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md
index ba4fc8b204f24..a29d911894fce 100644
--- a/ecosystem-tool-user-case.md
+++ b/ecosystem-tool-user-case.md
@@ -12,9 +12,9 @@ This document introduces the common use cases of TiDB tools and how to choose th
If you need to deploy and operate TiDB on physical or virtual machines, you can install [TiUP](/tiup/tiup-overview.md), and then use TiUP to manage TiDB components such as TiDB, PD, and TiKV.
-## Deploy and operate TiDB in Kubernetes
+## Deploy and operate TiDB on Kubernetes
-If you need to deploy and operate TiDB in Kubernetes, you can deploy a Kubernetes cluster, and then deploy [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable). After that, you can use TiDB Operator to deploy and operate a TiDB cluster.
+If you need to deploy and operate TiDB on Kubernetes, you can deploy a Kubernetes cluster, and then deploy [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable). After that, you can use TiDB Operator to deploy and operate a TiDB cluster.
## Import data from CSV to TiDB
diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md
index 0b4f7e1c95708..d460234e16b4f 100644
--- a/ecosystem-tool-user-guide.md
+++ b/ecosystem-tool-user-guide.md
@@ -25,14 +25,14 @@ The following are the basics of TiUP:
- [Manage TiUP Components with TiUP Commands](/tiup/tiup-component-management.md)
- Applicable TiDB versions: v4.0 and later versions
-### Deploy and operate TiDB in Kubernetes - TiDB Operator
+### Deploy and operate TiDB on Kubernetes - TiDB Operator
-[TiDB Operator](https://github.com/pingcap/tidb-operator) is an automatic operation system for managing TiDB clusters in Kubernetes. It provides full life-cycle management for TiDB including deployment, upgrades, scaling, backup, and configuration changes. With TiDB Operator, TiDB can run seamlessly in the Kubernetes clusters deployed on a public or private cloud.
+[TiDB Operator](https://github.com/pingcap/tidb-operator) is an automatic operation system for managing TiDB clusters on Kubernetes. It provides full life-cycle management for TiDB including deployment, upgrades, scaling, backup, and configuration changes. With TiDB Operator, TiDB can run seamlessly in the Kubernetes clusters deployed on a public or private cloud.
The following are the basics of TiDB Operator:
- [TiDB Operator Architecture](https://docs.pingcap.com/tidb-in-kubernetes/stable/architecture)
-- [Get Started with TiDB Operator in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/get-started/)
+- [Get Started with TiDB Operator on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/get-started/)
- Applicable TiDB versions: v2.1 and later versions
## Data management tools
@@ -48,7 +48,7 @@ The following are the basics of DM:
- Source: MySQL/MariaDB
- Target: TiDB clusters
- Supported TiDB versions: all versions
-- Kubernetes support: use [TiDB Operator](https://github.com/pingcap/tidb-operator) to deploy TiDB DM in Kubernetes.
+- Kubernetes support: use [TiDB Operator](https://github.com/pingcap/tidb-operator) to deploy TiDB DM on Kubernetes.
If the data volume is less than 1 TB, it is recommended to migrate data from MySQL/MariaDB to TiDB directly using DM. The migration process includes full data migration and incremental data replication.
@@ -93,7 +93,7 @@ The following are the basics of TiDB Lightning:
- Other compatible CSV files
- Parquet files exported from Amazon Aurora or Apache Hive
- Supported TiDB versions: v2.1 and later versions
-- Kubernetes support: Yes. See [Quickly restore data into a TiDB cluster in Kubernetes using TiDB Lightning](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-data-using-tidb-lightning) for details.
+- Kubernetes support: Yes. See [Quickly restore data into a TiDB cluster on Kubernetes using TiDB Lightning](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-data-using-tidb-lightning) for details.
> **Note:**
>
@@ -128,7 +128,7 @@ The following are the basics of TiDB Binlog:
- Source: TiDB clusters
- Target: TiDB clusters, MySQL, Kafka, or incremental backup files
- Supported TiDB versions: v2.1 and later versions
-- Kubernetes support: Yes. See [TiDB Binlog Cluster Operations](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tidb-binlog) and [TiDB Binlog Drainer Configurations in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-tidb-binlog-drainer) for details.
+- Kubernetes support: Yes. See [TiDB Binlog Cluster Operations](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tidb-binlog) and [TiDB Binlog Drainer Configurations on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-tidb-binlog-drainer) for details.
### sync-diff-inspector
diff --git a/enable-tls-between-clients-and-servers.md b/enable-tls-between-clients-and-servers.md
index a68404a124f68..03152365a33a7 100644
--- a/enable-tls-between-clients-and-servers.md
+++ b/enable-tls-between-clients-and-servers.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/enable-tls-between-clients-and-servers/','/docs/dev/how-to/
# Enable TLS between TiDB Clients and Servers
-Non-encrypted connection between TiDB's server and clients is allowed by default, which enables third parties that monitor channel traffic to know the data sent and received between the server and the client, including but not limited to query content, query results, and so on. If a channel is untrustworthy (such as if the client is connected to the TiDB server via a public network), then a non-encrypted connection is prone to information leakage. In this case, for security reasons, it is recommended to require an encrypted connection.
+Non-encrypted connection between TiDB's server and clients is allowed by default, which enables third parties that monitor channel traffic to know the data sent and received between the server and the client, including query content and query results. If a channel is untrustworthy (such as if the client is connected to the TiDB server via a public network), then a non-encrypted connection is prone to information leakage. In this case, for security reasons, it is recommended to require an encrypted connection.
The TiDB server supports the encrypted connection based on the TLS (Transport Layer Security). The protocol is consistent with MySQL encrypted connections and is directly supported by existing MySQL clients such as MySQL Client, MySQL Shell and MySQL drivers. TLS is sometimes referred to as SSL (Secure Sockets Layer). Because the SSL protocol has [known security vulnerabilities](https://en.wikipedia.org/wiki/Transport_Layer_Security), TiDB does not support SSL. TiDB supports the following protocols: TLSv1.0, TLSv1.1, TLSv1.2 and TLSv1.3.
@@ -101,7 +101,7 @@ create user 'u1'@'%' require x509;
## Check whether the current connection uses encryption
-Use the `SHOW STATUS LIKE "%Ssl%";` statement to get the details of the current connection, including whether encryption is used, the encryption protocol used by encrypted connections, the TLS version number and so on.
+Use the `SHOW STATUS LIKE "%Ssl%";` statement to get the details of the current connection, including whether encryption is used, the encryption protocol used by encrypted connections and the TLS version number.
See the following example of the result in an encrypted connection. The results change according to different TLS versions or encryption protocols supported by the client.
diff --git a/encryption-at-rest.md b/encryption-at-rest.md
index 7084e1ec7376e..d0b0783cf7143 100644
--- a/encryption-at-rest.md
+++ b/encryption-at-rest.md
@@ -10,7 +10,7 @@ aliases: ['/docs/dev/encryption at rest/']
>
> If your cluster is deployed on AWS and uses the EBS storage, it is recommended to use the EBS encryption. See [AWS documentation - EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html). You are using the non-EBS storage on AWS such as the local NVMe storage, it is recommended to use encryption at rest introduced in this document.
-Encryption at rest means that data is encrypted when it is stored. For databases, this feature is also referred to as TDE (transparent data encryption). This is opposed to encryption in flight (TLS) or encryption in use (rarely used). Different things could be doing encryption at rest (SSD drive, file system, cloud vendor, etc), but by having TiKV do the encryption before storage this helps ensure that attackers must authenticate with the database to gain access to data. For example, when an attacker gains access to the physical machine, data cannot be accessed by copying files on disk.
+Encryption at rest means that data is encrypted when it is stored. For databases, this feature is also referred to as TDE (transparent data encryption). This is opposed to encryption in flight (TLS) or encryption in use (rarely used). Different things could be doing encryption at rest (such as SSD drive, file system, and cloud vendor), but by having TiKV do the encryption before storage this helps ensure that attackers must authenticate with the database to gain access to data. For example, when an attacker gains access to the physical machine, data cannot be accessed by copying files on disk.
## Encryption support in different TiDB components
@@ -48,7 +48,7 @@ BR supports S3 server-side encryption (SSE) when backing up data to S3. A custom
### Logging
-TiKV, TiDB, and PD info logs might contain user data for debugging purposes. The info log and this data in it are not encrypted. It is recommended to enable [log redaction](/log-redaction.md).
+TiKV, TiDB, and PD info logs might contain user data for debugging purposes. The info log and this data in it are not encrypted. It is recommended to enable [log redaction](/log-redaction.md).
## TiKV encryption at rest
diff --git a/experimental-features.md b/experimental-features.md
index 452cbf43ea05c..cc20e7ec43f23 100644
--- a/experimental-features.md
+++ b/experimental-features.md
@@ -11,7 +11,6 @@ This document introduces the experimental features of TiDB in different versions
## Performance
+ [Support collecting statistics for `PREDICATE COLUMNS`](/statistics.md#collect-statistics-on-some-columns) (Introduced in v5.4)
-+ [Support synchronously loading statistics](/statistics.md#load-statistics). (Introduced in v5.4)
+ [Control the memory quota for collecting statistics](/statistics.md#the-memory-quota-for-collecting-statistics). (Introduced in v6.1.0)
+ [Cost Model Version 2](/cost-model.md#cost-model-version-2). (Introduced in v6.2.0)
+ [FastScan](/develop/dev-guide-use-fastscan.md). (Introduced in v6.2.0)
diff --git a/explain-joins.md b/explain-joins.md
index fdcbb7f6d2024..fa1ef33cae6aa 100644
--- a/explain-joins.md
+++ b/explain-joins.md
@@ -41,6 +41,10 @@ ANALYZE TABLE t1, t2;
If the number of estimated rows that need to be joined is small (typically less than 10000 rows), it is preferable to use the index join method. This method of join works similar to the primary method of join used in MySQL. In the following example, the operator `├─TableReader_28(Build)` first reads the table `t1`. For each row that matches, TiDB will probe the table `t2`:
+> **Note:**
+>
+> In the returned execution plan, for all probe-side child nodes of `IndexJoin` and `Apply` operators, the meaning of `estRows` since v6.4.0 is different from that before v6.4.0. For more details, see [TiDB Query Execution Plan Overview](/explain-overview.md#understand-explain-output).
+
{{< copyable "sql" >}}
```sql
@@ -48,17 +52,16 @@ EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_
```
```sql
-+---------------------------------+-----------+-----------+------------------------------+--------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+---------------------------------+-----------+-----------+------------------------------+--------------------------------------------------------------------------------+
-| IndexJoin_10 | 180000.00 | root | | inner join, inner:IndexLookUp_9, outer key:test.t1.id, inner key:test.t2.t1_id |
-| ├─TableReader_28(Build) | 142020.00 | root | | data:TableFullScan_27 |
-| │ └─TableFullScan_27 | 142020.00 | cop[tikv] | table:t1 | keep order:false |
-| └─IndexLookUp_9(Probe) | 1.27 | root | | |
-| ├─IndexRangeScan_7(Build) | 1.27 | cop[tikv] | table:t2, index:t1_id(t1_id) | range: decided by [eq(test.t2.t1_id, test.t1.id)], keep order:false |
-| └─TableRowIDScan_8(Probe) | 1.27 | cop[tikv] | table:t2 | keep order:false |
-+---------------------------------+-----------+-----------+------------------------------+--------------------------------------------------------------------------------+
-6 rows in set (0.00 sec)
++---------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++---------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
+| IndexJoin_11 | 90000.00 | root | | inner join, inner:IndexLookUp_10, outer key:test.t1.id, inner key:test.t2.t1_id, equal cond:eq(test.t1.id, test.t2.t1_id) |
+| ├─TableReader_29(Build) | 71010.00 | root | | data:TableFullScan_28 |
+| │ └─TableFullScan_28 | 71010.00 | cop[tikv] | table:t1 | keep order:false |
+| └─IndexLookUp_10(Probe) | 90000.00 | root | | |
+| ├─IndexRangeScan_8(Build) | 90000.00 | cop[tikv] | table:t2, index:t1_id(t1_id) | range: decided by [eq(test.t2.t1_id, test.t1.id)], keep order:false |
+| └─TableRowIDScan_9(Probe) | 90000.00 | cop[tikv] | table:t2 | keep order:false |
++---------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
```
Index join is efficient in memory usage, but might be slower to execute than other join methods when a large number of probe operations are required. Consider also the following query:
@@ -83,46 +86,41 @@ EXPLAIN ANALYZE SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.int_
```
```sql
-Query OK, 0 rows affected (0.29 sec)
-
-+-----------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------+-----------------------+------+
-| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
-+-----------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------+-----------------------+------+
-| IndexJoin_13 | 90000.00 | 20000 | root | | time:613.19955ms, loops:21, inner:{total:42.494047ms, concurrency:5, task:12, construct:33.149671ms, fetch:9.322956ms, build:8.66µs}, probe:32.435355ms | inner join, inner:TableReader_9, outer key:test.t2.t1_id, inner key:test.t1.id | 269.63341903686523 MB | N/A |
-| ├─TableReader_19(Build) | 90000.00 | 90000 | root | | time:586.613252ms, loops:95, cop_task: {num: 3, max: 205.893949ms, min: 185.051354ms, avg: 194.878702ms, p95: 205.893949ms, max_proc_keys: 31715, p95_proc_keys: 31715, tot_proc: 332ms, tot_wait: 4ms, rpc_num: 4, rpc_time: 584.907774ms, copr_cache_hit_ratio: 0.00}, backoff{regionMiss: 2ms} | data:TableFullScan_18 | 182.624906539917 MB | N/A |
-| │ └─TableFullScan_18 | 90000.00 | 90000 | cop[tikv] | table:t2 | time:0ns, loops:0, tikv_task:{proc max:72ms, min:64ms, p80:72ms, p95:72ms, iters:102, tasks:3} | keep order:false | N/A | N/A |
-| └─TableReader_9(Probe) | 0.00 | 5 | root | | time:8.432051ms, loops:14, cop_task: {num: 14, max: 629.805µs, min: 226.129µs, avg: 420.979µs, p95: 629.805µs, max_proc_keys: 4, p95_proc_keys: 4, rpc_num: 15, rpc_time: 5.953229ms, copr_cache_hit_ratio: 0.00} | data:Selection_8 | N/A | N/A |
-| └─Selection_8 | 0.00 | 5 | cop[tikv] | | time:0ns, loops:0, tikv_task:{proc max:0s, min:0s, p80:0s, p95:0s, iters:14, tasks:14} | eq(test.t1.int_col, 1) | N/A | N/A |
-| └─TableRangeScan_7 | 1.00 | 25 | cop[tikv] | table:t1 | time:0ns, loops:0, tikv_task:{proc max:0s, min:0s, p80:0s, p95:0s, iters:14, tasks:14} | range: decided by [test.t2.t1_id], keep order:false | N/A | N/A |
-+-----------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------------------------+-----------------------+------+
-6 rows in set (0.61 sec)
-
-+------------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
-+------------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| HashJoin_19 | 90000.00 | 20000 | root | | time:406.098528ms, loops:22, build_hash_table:{total:148.574644ms, fetch:146.843636ms, build:1.731008ms}, probe:{concurrency:5, total:2.026547436s, max:406.039309ms, probe:205.337813ms, fetch:1.821209623s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 30.00731658935547 MB | 0 Bytes |
-| ├─TableReader_22(Build) | 71.01 | 10000 | root | | time:147.072725ms, loops:12, cop_task: {num: 3, max: 145.847743ms, min: 50.932527ms, avg: 113.009029ms, p95: 145.847743ms, max_proc_keys: 31724, p95_proc_keys: 31724, tot_proc: 284ms, rpc_num: 3, rpc_time: 338.950488ms, copr_cache_hit_ratio: 0.00} | data:Selection_21 | 29.679713249206543 MB | N/A |
-| │ └─Selection_21 | 71.01 | 10000 | cop[tikv] | | time:0ns, loops:0, tikv_task:{proc max:132ms, min:48ms, p80:132ms, p95:132ms, iters:83, tasks:3} | eq(test.t1.int_col, 1) | N/A | N/A |
-| │ └─TableFullScan_20 | 71010.00 | 71010 | cop[tikv] | table:t1 | time:0ns, loops:0, tikv_task:{proc max:128ms, min:48ms, p80:128ms, p95:128ms, iters:83, tasks:3} | keep order:false | N/A | N/A |
-| └─TableReader_24(Probe) | 90000.00 | 90000 | root | | time:365.918504ms, loops:91, cop_task: {num: 3, max: 398.62145ms, min: 338.460345ms, avg: 358.732721ms, p95: 398.62145ms, max_proc_keys: 31715, p95_proc_keys: 31715, tot_proc: 536ms, rpc_num: 3, rpc_time: 1.076128895s, copr_cache_hit_ratio: 0.00} | data:TableFullScan_23 | 182.62489891052246 MB | N/A |
-| └─TableFullScan_23 | 90000.00 | 90000 | cop[tikv] | table:t2 | time:0ns, loops:0, tikv_task:{proc max:100ms, min:40ms, p80:100ms, p95:100ms, iters:102, tasks:3} | keep order:false | N/A | N/A |
-+------------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-6 rows in set (0.41 sec)
-
-+------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
-+------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| HashJoin_20 | 90000.00 | 20000 | root | | time:441.897092ms, loops:21, build_hash_table:{total:138.600864ms, fetch:136.353899ms, build:2.246965ms}, probe:{concurrency:5, total:2.207403854s, max:441.850032ms, probe:148.01937ms, fetch:2.059384484s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 30.00731658935547 MB | 0 Bytes |
-| ├─TableReader_25(Build) | 71.01 | 10000 | root | | time:138.081807ms, loops:12, cop_task: {num: 3, max: 134.702901ms, min: 53.356202ms, avg: 93.372186ms, p95: 134.702901ms, max_proc_keys: 31724, p95_proc_keys: 31724, tot_proc: 236ms, rpc_num: 3, rpc_time: 280.017658ms, copr_cache_hit_ratio: 0.00} | data:Selection_24 | 29.680171966552734 MB | N/A |
-| │ └─Selection_24 | 71.01 | 10000 | cop[tikv] | | time:0ns, loops:0, tikv_task:{proc max:80ms, min:52ms, p80:80ms, p95:80ms, iters:83, tasks:3} | eq(test.t1.int_col, 1) | N/A | N/A |
-| │ └─TableFullScan_23 | 71010.00 | 71010 | cop[tikv] | table:t1 | time:0ns, loops:0, tikv_task:{proc max:80ms, min:52ms, p80:80ms, p95:80ms, iters:83, tasks:3} | keep order:false | N/A | N/A |
-| └─TableReader_22(Probe) | 90000.00 | 90000 | root | | time:413.560548ms, loops:91, cop_task: {num: 3, max: 432.938474ms, min: 231.263355ms, avg: 365.710741ms, p95: 432.938474ms, max_proc_keys: 31715, p95_proc_keys: 31715, tot_proc: 488ms, rpc_num: 3, rpc_time: 1.097021983s, copr_cache_hit_ratio: 0.00} | data:TableFullScan_21 | 182.62489891052246 MB | N/A |
-| └─TableFullScan_21 | 90000.00 | 90000 | cop[tikv] | table:t2 | time:0ns, loops:0, tikv_task:{proc max:80ms, min:80ms, p80:80ms, p95:80ms, iters:102, tasks:3} | keep order:false | N/A | N/A |
-+------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-6 rows in set (0.44 sec)
++-----------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+---------+------+
+| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
++-----------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+---------+------+
+| IndexJoin_14 | 90000.00 | 0 | root | | time:330.2ms, loops:1, inner:{total:72.2ms, concurrency:5, task:12, construct:58.6ms, fetch:13.5ms, build:2.12µs}, probe:26.1ms | inner join, inner:TableReader_10, outer key:test.t2.t1_id, inner key:test.t1.id, equal cond:eq(test.t2.t1_id, test.t1.id) | 88.5 MB | N/A |
+| ├─TableReader_20(Build) | 90000.00 | 90000 | root | | time:307.2ms, loops:96, cop_task: {num: 24, max: 130.6ms, min: 170.9µs, avg: 33.5ms, p95: 105ms, max_proc_keys: 10687, p95_proc_keys: 9184, tot_proc: 472ms, rpc_num: 24, rpc_time: 802.4ms, copr_cache_hit_ratio: 0.62, distsql_concurrency: 15} | data:TableFullScan_19 | 58.6 MB | N/A |
+| │ └─TableFullScan_19 | 90000.00 | 90000 | cop[tikv] | table:t2 | tikv_task:{proc max:34ms, min:0s, avg: 15.3ms, p80:24ms, p95:30ms, iters:181, tasks:24}, scan_detail: {total_process_keys: 69744, total_process_keys_size: 217533936, total_keys: 69753, get_snapshot_time: 701.6µs, rocksdb: {delete_skipped_count: 97368, key_skipped_count: 236847, block: {cache_hit_count: 3509}}} | keep order:false | N/A | N/A |
+| └─TableReader_10(Probe) | 12617.92 | 0 | root | | time:11.9ms, loops:12, cop_task: {num: 42, max: 848.8µs, min: 199µs, avg: 451.8µs, p95: 846.2µs, max_proc_keys: 7, p95_proc_keys: 5, rpc_num: 42, rpc_time: 18.3ms, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15} | data:Selection_9 | N/A | N/A |
+| └─Selection_9 | 12617.92 | 0 | cop[tikv] | | tikv_task:{proc max:0s, min:0s, avg: 0s, p80:0s, p95:0s, iters:42, tasks:42}, scan_detail: {total_process_keys: 56, total_process_keys_size: 174608, total_keys: 77, get_snapshot_time: 727.7µs, rocksdb: {block: {cache_hit_count: 154}}} | eq(test.t1.int_col, 1) | N/A | N/A |
+| └─TableRangeScan_8 | 90000.00 | 56 | cop[tikv] | table:t1 | tikv_task:{proc max:0s, min:0s, avg: 0s, p80:0s, p95:0s, iters:42, tasks:42} | range: decided by [test.t2.t1_id], keep order:false | N/A | N/A |
++-----------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+---------+------+
+
++------------------------------+----------+---------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
++------------------------------+----------+---------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| HashJoin_20 | 90000.00 | 0 | root | | time:313.6ms, loops:1, build_hash_table:{total:24.6ms, fetch:21.2ms, build:3.32ms}, probe:{concurrency:5, total:1.57s, max:313.5ms, probe:18.9ms, fetch:1.55s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 32.0 MB | 0 Bytes |
+| ├─TableReader_23(Build) | 9955.54 | 10000 | root | | time:23.6ms, loops:12, cop_task: {num: 11, max: 504.6µs, min: 203.7µs, avg: 377.4µs, p95: 504.6µs, rpc_num: 11, rpc_time: 3.92ms, copr_cache_hit_ratio: 1.00, distsql_concurrency: 15} | data:Selection_22 | 14.9 MB | N/A |
+| │ └─Selection_22 | 9955.54 | 10000 | cop[tikv] | | tikv_task:{proc max:104ms, min:3ms, avg: 24.4ms, p80:33ms, p95:104ms, iters:113, tasks:11}, scan_detail: {get_snapshot_time: 241.4µs, rocksdb: {block: {}}} | eq(test.t1.int_col, 1) | N/A | N/A |
+| │ └─TableFullScan_21 | 71010.00 | 71010 | cop[tikv] | table:t1 | tikv_task:{proc max:101ms, min:3ms, avg: 23.8ms, p80:33ms, p95:101ms, iters:113, tasks:11} | keep order:false | N/A | N/A |
+| └─TableReader_25(Probe) | 90000.00 | 90000 | root | | time:293.7ms, loops:91, cop_task: {num: 24, max: 105.7ms, min: 210.9µs, avg: 31.4ms, p95: 103.8ms, max_proc_keys: 10687, p95_proc_keys: 9184, tot_proc: 407ms, rpc_num: 24, rpc_time: 752.2ms, copr_cache_hit_ratio: 0.62, distsql_concurrency: 15} | data:TableFullScan_24 | 58.6 MB | N/A |
+| └─TableFullScan_24 | 90000.00 | 90000 | cop[tikv] | table:t2 | tikv_task:{proc max:31ms, min:0s, avg: 13ms, p80:19ms, p95:26ms, iters:181, tasks:24}, scan_detail: {total_process_keys: 69744, total_process_keys_size: 217533936, total_keys: 69753, get_snapshot_time: 637.2µs, rocksdb: {delete_skipped_count: 97368, key_skipped_count: 236847, block: {cache_hit_count: 3509}}} | keep order:false | N/A | N/A |
++------------------------------+----------+---------+-----------+---------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+
++------------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
++------------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| HashJoin_21 | 90000.00 | 0 | root | | time:331.7ms, loops:1, build_hash_table:{total:32.7ms, fetch:26ms, build:6.73ms}, probe:{concurrency:5, total:1.66s, max:331.3ms, probe:16ms, fetch:1.64s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 32.3 MB | 0 Bytes |
+| ├─TableReader_26(Build) | 9955.54 | 10000 | root | | time:30.4ms, loops:13, cop_task: {num: 11, max: 1.87ms, min: 844.7µs, avg: 1.29ms, p95: 1.87ms, rpc_num: 11, rpc_time: 13.5ms, copr_cache_hit_ratio: 1.00, distsql_concurrency: 15} | data:Selection_25 | 12.2 MB | N/A |
+| │ └─Selection_25 | 9955.54 | 10000 | cop[tikv] | | tikv_task:{proc max:104ms, min:3ms, avg: 24.4ms, p80:33ms, p95:104ms, iters:113, tasks:11}, scan_detail: {get_snapshot_time: 521µs, rocksdb: {block: {}}} | eq(test.t1.int_col, 1) | N/A | N/A |
+| │ └─TableFullScan_24 | 71010.00 | 71010 | cop[tikv] | table:t1 | tikv_task:{proc max:101ms, min:3ms, avg: 23.8ms, p80:33ms, p95:101ms, iters:113, tasks:11} | keep order:false | N/A | N/A |
+| └─TableReader_23(Probe) | 90000.00 | 90000 | root | | time:308.6ms, loops:91, cop_task: {num: 24, max: 123.3ms, min: 518.9µs, avg: 32.4ms, p95: 113.4ms, max_proc_keys: 10687, p95_proc_keys: 9184, tot_proc: 499ms, rpc_num: 24, rpc_time: 776ms, copr_cache_hit_ratio: 0.62, distsql_concurrency: 15} | data:TableFullScan_22 | 58.6 MB | N/A |
+| └─TableFullScan_22 | 90000.00 | 90000 | cop[tikv] | table:t2 | tikv_task:{proc max:44ms, min:0s, avg: 16.8ms, p80:27ms, p95:40ms, iters:181, tasks:24}, scan_detail: {total_process_keys: 69744, total_process_keys_size: 217533936, total_keys: 69753, get_snapshot_time: 955.4µs, rocksdb: {delete_skipped_count: 97368, key_skipped_count: 236847, block: {cache_hit_count: 3509}}} | keep order:false | N/A | N/A |
++------------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
```
-In the above example, the index join operation is missing an index on `t1.int_col`. Once this index is added, the performance of the operation improves from `0.61 sec` to `0.14 sec`, as the following result shows:
+In the above example, the index join operation is missing an index on `t1.int_col`. Once this index is added, the performance of the operation improves from `0.3 sec` to `0.06 sec`, as the following result shows:
```sql
-- Re-add index
@@ -134,44 +132,39 @@ EXPLAIN ANALYZE SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.int_
```
```sql
-Query OK, 0 rows affected (3.65 sec)
-
-+---------------------------------+----------+---------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------+-----------------------+------+
-| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
-+---------------------------------+----------+---------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------+-----------------------+------+
-| IndexJoin_11 | 90000.00 | 0 | root | | time:136.876686ms, loops:1, inner:{total:114.948158ms, concurrency:5, task:7, construct:5.329114ms, fetch:109.610054ms, build:2.38µs}, probe:1.699799ms | inner join, inner:IndexLookUp_10, outer key:test.t1.id, inner key:test.t2.t1_id | 29.864535331726074 MB | N/A |
-| ├─TableReader_32(Build) | 10000.00 | 10000 | root | | time:95.755212ms, loops:12, cop_task: {num: 3, max: 95.652443ms, min: 30.758712ms, avg: 57.545129ms, p95: 95.652443ms, max_proc_keys: 31724, p95_proc_keys: 31724, tot_proc: 124ms, rpc_num: 3, rpc_time: 172.528417ms, copr_cache_hit_ratio: 0.00} | data:Selection_31 | 29.679298400878906 MB | N/A |
-| │ └─Selection_31 | 10000.00 | 10000 | cop[tikv] | | time:0ns, loops:0, tikv_task:{proc max:44ms, min:28ms, p80:44ms, p95:44ms, iters:84, tasks:3} | eq(test.t1.int_col, 1) | N/A | N/A |
-| │ └─TableFullScan_30 | 71010.00 | 71010 | cop[tikv] | table:t1 | time:0ns, loops:0, tikv_task:{proc max:44ms, min:28ms, p80:44ms, p95:44ms, iters:84, tasks:3} | keep order:false | N/A | N/A |
-| └─IndexLookUp_10(Probe) | 9.00 | 0 | root | | time:103.93801ms, loops:7 | | 2.1787109375 KB | N/A |
-| ├─IndexRangeScan_8(Build) | 9.00 | 0 | cop[tikv] | table:t2, index:t1_id(t1_id) | time:0s, loops:0, cop_task: {num: 7, max: 23.969244ms, min: 12.003682ms, avg: 14.659066ms, p95: 23.969244ms, tot_proc: 100ms, rpc_num: 7, rpc_time: 102.435966ms, copr_cache_hit_ratio: 0.00}, tikv_task:{proc max:24ms, min:12ms, p80:16ms, p95:24ms, iters:7, tasks:7} | range: decided by [eq(test.t2.t1_id, test.t1.id)], keep order:false | N/A | N/A |
-| └─TableRowIDScan_9(Probe) | 9.00 | 0 | cop[tikv] | table:t2 | time:0ns, loops:0 | keep order:false | N/A | N/A |
-+---------------------------------+----------+---------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------+-----------------------+------+
-7 rows in set (0.14 sec)
-
-+------------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
-+------------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| HashJoin_31 | 90000.00 | 0 | root | | time:402.263795ms, loops:1, build_hash_table:{total:128.467151ms, fetch:126.871282ms, build:1.595869ms}, probe:{concurrency:5, total:2.010969815s, max:402.212295ms, probe:8.924769ms, fetch:2.002045046s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 29.689788818359375 MB | 0 Bytes |
-| ├─TableReader_34(Build) | 10000.00 | 10000 | root | | time:126.765972ms, loops:11, cop_task: {num: 3, max: 126.721293ms, min: 54.375481ms, avg: 84.518849ms, p95: 126.721293ms, max_proc_keys: 31724, p95_proc_keys: 31724, tot_proc: 208ms, rpc_num: 3, rpc_time: 253.478218ms, copr_cache_hit_ratio: 0.00} | data:Selection_33 | 29.679292678833008 MB | N/A |
-| │ └─Selection_33 | 10000.00 | 10000 | cop[tikv] | | time:0ns, loops:0, tikv_task:{proc max:72ms, min:56ms, p80:72ms, p95:72ms, iters:84, tasks:3} | eq(test.t1.int_col, 1) | N/A | N/A |
-| │ └─TableFullScan_32 | 71010.00 | 71010 | cop[tikv] | table:t1 | time:0ns, loops:0, tikv_task:{proc max:72ms, min:56ms, p80:72ms, p95:72ms, iters:84, tasks:3} | keep order:false | N/A | N/A |
-| └─TableReader_36(Probe) | 90000.00 | 90000 | root | | time:400.447175ms, loops:90, cop_task: {num: 3, max: 400.838264ms, min: 309.474053ms, avg: 341.01943ms, p95: 400.838264ms, max_proc_keys: 31719, p95_proc_keys: 31719, tot_proc: 528ms, rpc_num: 3, rpc_time: 1.02298055s, copr_cache_hit_ratio: 0.00} | data:TableFullScan_35 | 182.62786674499512 MB | N/A |
-| └─TableFullScan_35 | 90000.00 | 90000 | cop[tikv] | table:t2 | time:0ns, loops:0, tikv_task:{proc max:108ms, min:72ms, p80:108ms, p95:108ms, iters:102, tasks:3} | keep order:false | N/A | N/A |
-+------------------------------+----------+---------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-6 rows in set (0.40 sec)
-
-+------------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
-+------------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-| HashJoin_32 | 90000.00 | 0 | root | | time:356.282882ms, loops:1, build_hash_table:{total:154.187155ms, fetch:151.259305ms, build:2.92785ms}, probe:{concurrency:5, total:1.781087041s, max:356.238312ms, probe:7.406146ms, fetch:1.773680895s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 29.689788818359375 MB | 0 Bytes |
-| ├─TableReader_41(Build) | 10000.00 | 10000 | root | | time:151.190175ms, loops:11, cop_task: {num: 3, max: 151.055697ms, min: 56.214348ms, avg: 96.70463ms, p95: 151.055697ms, max_proc_keys: 31724, p95_proc_keys: 31724, tot_proc: 240ms, rpc_num: 3, rpc_time: 290.019942ms, copr_cache_hit_ratio: 0.00} | data:Selection_40 | 29.679292678833008 MB | N/A |
-| │ └─Selection_40 | 10000.00 | 10000 | cop[tikv] | | time:0ns, loops:0, tikv_task:{proc max:80ms, min:56ms, p80:80ms, p95:80ms, iters:84, tasks:3} | eq(test.t1.int_col, 1) | N/A | N/A |
-| │ └─TableFullScan_39 | 71010.00 | 71010 | cop[tikv] | table:t1 | time:0ns, loops:0, tikv_task:{proc max:80ms, min:56ms, p80:80ms, p95:80ms, iters:84, tasks:3} | keep order:false | N/A | N/A |
-| └─TableReader_43(Probe) | 90000.00 | 90000 | root | | time:354.68523ms, loops:90, cop_task: {num: 3, max: 354.313475ms, min: 328.460762ms, avg: 345.530558ms, p95: 354.313475ms, max_proc_keys: 31719, p95_proc_keys: 31719, tot_proc: 508ms, rpc_num: 3, rpc_time: 1.036492374s, copr_cache_hit_ratio: 0.00} | data:TableFullScan_42 | 182.62786102294922 MB | N/A |
-| └─TableFullScan_42 | 90000.00 | 90000 | cop[tikv] | table:t2 | time:0ns, loops:0, tikv_task:{proc max:84ms, min:64ms, p80:84ms, p95:84ms, iters:102, tasks:3} | keep order:false | N/A | N/A |
-+------------------------------+----------+---------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-----------------------+---------+
-6 rows in set (0.36 sec)
++----------------------------------+----------+---------+-----------+------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----------+------+
+| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
++----------------------------------+----------+---------+-----------+------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----------+------+
+| IndexJoin_12 | 90000.00 | 0 | root | | time:65.6ms, loops:1, inner:{total:129.7ms, concurrency:5, task:7, construct:7.13ms, fetch:122.5ms, build:16.4µs}, probe:2.54ms | inner join, inner:IndexLookUp_11, outer key:test.t1.id, inner key:test.t2.t1_id, equal cond:eq(test.t1.id, test.t2.t1_id) | 28.7 MB | N/A |
+| ├─TableReader_33(Build) | 9955.54 | 10000 | root | | time:15.4ms, loops:16, cop_task: {num: 11, max: 1.52ms, min: 211.5µs, avg: 416.8µs, p95: 1.52ms, rpc_num: 11, rpc_time: 4.36ms, copr_cache_hit_ratio: 1.00, distsql_concurrency: 15} | data:Selection_32 | 13.9 MB | N/A |
+| │ └─Selection_32 | 9955.54 | 10000 | cop[tikv] | | tikv_task:{proc max:104ms, min:3ms, avg: 24.4ms, p80:33ms, p95:104ms, iters:113, tasks:11}, scan_detail: {get_snapshot_time: 185µs, rocksdb: {block: {}}} | eq(test.t1.int_col, 1) | N/A | N/A |
+| │ └─TableFullScan_31 | 71010.00 | 71010 | cop[tikv] | table:t1 | tikv_task:{proc max:101ms, min:3ms, avg: 23.8ms, p80:33ms, p95:101ms, iters:113, tasks:11} | keep order:false | N/A | N/A |
+| └─IndexLookUp_11(Probe) | 90000.00 | 0 | root | | time:115.6ms, loops:7 | | 555 Bytes | N/A |
+| ├─IndexRangeScan_9(Build) | 90000.00 | 0 | cop[tikv] | table:t2, index:t1_id(t1_id) | time:114.3ms, loops:7, cop_task: {num: 7, max: 42ms, min: 1.3ms, avg: 16.2ms, p95: 42ms, tot_proc: 71ms, rpc_num: 7, rpc_time: 113.2ms, copr_cache_hit_ratio: 0.29, distsql_concurrency: 15}, tikv_task:{proc max:37ms, min:0s, avg: 11.3ms, p80:20ms, p95:37ms, iters:7, tasks:7}, scan_detail: {total_keys: 9296, get_snapshot_time: 141.9µs, rocksdb: {block: {cache_hit_count: 18592}}} | range: decided by [eq(test.t2.t1_id, test.t1.id)], keep order:false | N/A | N/A |
+| └─TableRowIDScan_10(Probe) | 90000.00 | 0 | cop[tikv] | table:t2 | | keep order:false | N/A | N/A |
++----------------------------------+----------+---------+-----------+------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------+-----------+------+
+
++------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
++------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| HashJoin_32 | 90000.00 | 0 | root | | time:320.2ms, loops:1, build_hash_table:{total:19.3ms, fetch:16.8ms, build:2.52ms}, probe:{concurrency:5, total:1.6s, max:320.1ms, probe:16.1ms, fetch:1.58s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 32.0 MB | 0 Bytes |
+| ├─TableReader_35(Build) | 9955.54 | 10000 | root | | time:18.6ms, loops:12, cop_task: {num: 11, max: 713.8µs, min: 197.3µs, avg: 368.5µs, p95: 713.8µs, rpc_num: 11, rpc_time: 3.83ms, copr_cache_hit_ratio: 1.00, distsql_concurrency: 15} | data:Selection_34 | 14.9 MB | N/A |
+| │ └─Selection_34 | 9955.54 | 10000 | cop[tikv] | | tikv_task:{proc max:104ms, min:3ms, avg: 24.4ms, p80:33ms, p95:104ms, iters:113, tasks:11}, scan_detail: {get_snapshot_time: 178.9µs, rocksdb: {block: {}}} | eq(test.t1.int_col, 1) | N/A | N/A |
+| │ └─TableFullScan_33 | 71010.00 | 71010 | cop[tikv] | table:t1 | tikv_task:{proc max:101ms, min:3ms, avg: 23.8ms, p80:33ms, p95:101ms, iters:113, tasks:11} | keep order:false | N/A | N/A |
+| └─TableReader_37(Probe) | 90000.00 | 90000 | root | | time:304.4ms, loops:91, cop_task: {num: 24, max: 114ms, min: 251.1µs, avg: 33.1ms, p95: 110.4ms, max_proc_keys: 10687, p95_proc_keys: 9184, tot_proc: 492ms, rpc_num: 24, rpc_time: 793ms, copr_cache_hit_ratio: 0.62, distsql_concurrency: 15} | data:TableFullScan_36 | 58.6 MB | N/A |
+| └─TableFullScan_36 | 90000.00 | 90000 | cop[tikv] | table:t2 | tikv_task:{proc max:38ms, min:3ms, avg: 14.1ms, p80:23ms, p95:35ms, iters:181, tasks:24}, scan_detail: {total_process_keys: 69744, total_process_keys_size: 217533936, total_keys: 139497, get_snapshot_time: 577.2µs, rocksdb: {delete_skipped_count: 44208, key_skipped_count: 253431, block: {cache_hit_count: 3527}}} | keep order:false | N/A | N/A |
++------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+
++------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
++------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
+| HashJoin_33 | 90000.00 | 0 | root | | time:306.3ms, loops:1, build_hash_table:{total:20.5ms, fetch:17.1ms, build:3.45ms}, probe:{concurrency:5, total:1.53s, max:305.9ms, probe:17.1ms, fetch:1.51s} | inner join, equal:[eq(test.t1.id, test.t2.t1_id)] | 32.0 MB | 0 Bytes |
+| ├─TableReader_42(Build) | 9955.54 | 10000 | root | | time:19.6ms, loops:12, cop_task: {num: 11, max: 1.07ms, min: 246.1µs, avg: 600µs, p95: 1.07ms, rpc_num: 11, rpc_time: 6.17ms, copr_cache_hit_ratio: 1.00, distsql_concurrency: 15} | data:Selection_41 | 19.7 MB | N/A |
+| │ └─Selection_41 | 9955.54 | 10000 | cop[tikv] | | tikv_task:{proc max:104ms, min:3ms, avg: 24.4ms, p80:33ms, p95:104ms, iters:113, tasks:11}, scan_detail: {get_snapshot_time: 282.9µs, rocksdb: {block: {}}} | eq(test.t1.int_col, 1) | N/A | N/A |
+| │ └─TableFullScan_40 | 71010.00 | 71010 | cop[tikv] | table:t1 | tikv_task:{proc max:101ms, min:3ms, avg: 23.8ms, p80:33ms, p95:101ms, iters:113, tasks:11} | keep order:false | N/A | N/A |
+| └─TableReader_44(Probe) | 90000.00 | 90000 | root | | time:289.2ms, loops:91, cop_task: {num: 24, max: 108.2ms, min: 252.8µs, avg: 31.3ms, p95: 106.1ms, max_proc_keys: 10687, p95_proc_keys: 9184, tot_proc: 445ms, rpc_num: 24, rpc_time: 750.4ms, copr_cache_hit_ratio: 0.62, distsql_concurrency: 15} | data:TableFullScan_43 | 58.6 MB | N/A |
+| └─TableFullScan_43 | 90000.00 | 90000 | cop[tikv] | table:t2 | tikv_task:{proc max:31ms, min:3ms, avg: 13.3ms, p80:24ms, p95:30ms, iters:181, tasks:24}, scan_detail: {total_process_keys: 69744, total_process_keys_size: 217533936, total_keys: 139497, get_snapshot_time: 730.2µs, rocksdb: {delete_skipped_count: 44208, key_skipped_count: 253431, block: {cache_hit_count: 3527}}} | keep order:false | N/A | N/A |
++------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+---------+---------+
```
> **Note:**
diff --git a/explain-overview.md b/explain-overview.md
index 6b3e8cae09cd5..03041376ac3dc 100644
--- a/explain-overview.md
+++ b/explain-overview.md
@@ -57,6 +57,80 @@ The following describes the output of the `EXPLAIN` statement above:
* `access object` shows the table, partition and index that is being accessed. The parts of the index are also shown, as in the case above that the column `a` from the index was used. This can be useful in cases where you have composite indexes.
* `operator info` shows additional details about the access. See [Operator info overview](#operator-info-overview) for additional details.
+> **Note:**
+>
+> In the returned execution plan, for all probe-side child nodes of `IndexJoin` and `Apply` operators, the meaning of `estRows` since v6.4.0 is different from that before v6.4.0.
+>
+> Before v6.4.0, `estRows` means the number of estimated rows to be processed by the probe side operators for each row from the build side operators. Since v6.4.0, `estRows` means the **total number** of estimated rows to be processed by the probe side operators. The actual number of rows displayed (indicated by the `actRows` column) in the result of `EXPLAIN ANALYZE` means the total row count, so since v6.4.0 the meanings of `estRows` and `actRows` for the probe side child nodes of `IndexJoin` and `Apply` operators are consistent.
+>
+>
+> For example：
+>
+> ```sql
+> CREATE TABLE t1(a INT, b INT);
+> CREATE TABLE t2(a INT, b INT, INDEX ia(a));
+> EXPLAIN SELECT /*+ INL_JOIN(t2) */ * FROM t1 JOIN t2 ON t1.a = t2.a;
+> EXPLAIN SELECT (SELECT a FROM t2 WHERE t2.a = t1.b LIMIT 1) FROM t1;
+> ```
+>
+> ```sql
+> -- Before v6.4.0:
+> +---------------------------------+----------+-----------+-----------------------+-----------------------------------------------------------------------------------------------------------------+
+> | id | estRows | task | access object | operator info |
+> +---------------------------------+----------+-----------+-----------------------+-----------------------------------------------------------------------------------------------------------------+
+> | IndexJoin_12 | 12487.50 | root | | inner join, inner:IndexLookUp_11, outer key:test.t1.a, inner key:test.t2.a, equal cond:eq(test.t1.a, test.t2.a) |
+> | ├─TableReader_24(Build) | 9990.00 | root | | data:Selection_23 |
+> | │ └─Selection_23 | 9990.00 | cop[tikv] | | not(isnull(test.t1.a)) |
+> | │ └─TableFullScan_22 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+> | └─IndexLookUp_11(Probe) | 1.25 | root | | |
+> | ├─Selection_10(Build) | 1.25 | cop[tikv] | | not(isnull(test.t2.a)) |
+> | │ └─IndexRangeScan_8 | 1.25 | cop[tikv] | table:t2, index:ia(a) | range: decided by [eq(test.t2.a, test.t1.a)], keep order:false, stats:pseudo |
+> | └─TableRowIDScan_9(Probe) | 1.25 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
+> +---------------------------------+----------+-----------+-----------------------+-----------------------------------------------------------------------------------------------------------------+
+> +---------------------------------+----------+-----------+-----------------------+------------------------------------------------------------------------------+
+> | id | estRows | task | access object | operator info |
+> +---------------------------------+----------+-----------+-----------------------+------------------------------------------------------------------------------+
+> | Projection_12 | 10000.00 | root | | test.t2.a |
+> | └─Apply_14 | 10000.00 | root | | CARTESIAN left outer join |
+> | ├─TableReader_16(Build) | 10000.00 | root | | data:TableFullScan_15 |
+> | │ └─TableFullScan_15 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+> | └─Limit_17(Probe) | 1.00 | root | | offset:0, count:1 |
+> | └─IndexReader_21 | 1.00 | root | | index:Limit_20 |
+> | └─Limit_20 | 1.00 | cop[tikv] | | offset:0, count:1 |
+> | └─IndexRangeScan_19 | 1.00 | cop[tikv] | table:t2, index:ia(a) | range: decided by [eq(test.t2.a, test.t1.b)], keep order:false, stats:pseudo |
+> +---------------------------------+----------+-----------+-----------------------+------------------------------------------------------------------------------+
+>
+> -- Since v6.4.0:
+>
+> -- You can find that the `estRows` column values for `IndexLookUp_11`, `Selection_10`, `IndexRangeScan_8`, and `TableRowIDScan_9` since v6.4.0 are different from that before v6.4.0.
+> +---------------------------------+----------+-----------+-----------------------+-----------------------------------------------------------------------------------------------------------------+
+> | id | estRows | task | access object | operator info |
+> +---------------------------------+----------+-----------+-----------------------+-----------------------------------------------------------------------------------------------------------------+
+> | IndexJoin_12 | 12487.50 | root | | inner join, inner:IndexLookUp_11, outer key:test.t1.a, inner key:test.t2.a, equal cond:eq(test.t1.a, test.t2.a) |
+> | ├─TableReader_24(Build) | 9990.00 | root | | data:Selection_23 |
+> | │ └─Selection_23 | 9990.00 | cop[tikv] | | not(isnull(test.t1.a)) |
+> | │ └─TableFullScan_22 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+> | └─IndexLookUp_11(Probe) | 12487.50 | root | | |
+> | ├─Selection_10(Build) | 12487.50 | cop[tikv] | | not(isnull(test.t2.a)) |
+> | │ └─IndexRangeScan_8 | 12500.00 | cop[tikv] | table:t2, index:ia(a) | range: decided by [eq(test.t2.a, test.t1.a)], keep order:false, stats:pseudo |
+> | └─TableRowIDScan_9(Probe) | 12487.50 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
+> +---------------------------------+----------+-----------+-----------------------+-----------------------------------------------------------------------------------------------------------------+
+>
+> -- You can find that the `estRows` column values for `Limit_17`, `IndexReader_21`, `Limit_20`, and `IndexRangeScan_19` since v6.4.0 are different from that before v6.4.0.
+> +---------------------------------+----------+-----------+-----------------------+------------------------------------------------------------------------------+
+> | id | estRows | task | access object | operator info |
+> +---------------------------------+----------+-----------+-----------------------+------------------------------------------------------------------------------+
+> | Projection_12 | 10000.00 | root | | test.t2.a |
+> | └─Apply_14 | 10000.00 | root | | CARTESIAN left outer join |
+> | ├─TableReader_16(Build) | 10000.00 | root | | data:TableFullScan_15 |
+> | │ └─TableFullScan_15 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+> | └─Limit_17(Probe) | 10000.00 | root | | offset:0, count:1 |
+> | └─IndexReader_21 | 10000.00 | root | | index:Limit_20 |
+> | └─Limit_20 | 10000.00 | cop[tikv] | | offset:0, count:1 |
+> | └─IndexRangeScan_19 | 10000.00 | cop[tikv] | table:t2, index:ia(a) | range: decided by [eq(test.t2.a, test.t1.b)], keep order:false, stats:pseudo |
+> +---------------------------------+----------+-----------+-----------------------+------------------------------------------------------------------------------+
+> ```
+
### Operator overview
An operator is a particular step that is executed as part of returning query results. The operators that perform table scans (of the disk or the TiKV Block Cache) are listed as follows:
@@ -84,7 +158,7 @@ In the `WHERE`/`HAVING`/`ON` conditions, the TiDB optimizer analyzes the result
> **Note:**
>
-> - In order to use an index, the condition must be _sargable_. For example, the condition `YEAR(date_column) < 1992` can not use an index, but `date_column < '1992-01-01` can.
+> - In order to use an index, the condition must be _sargable_. For example, the condition `YEAR(date_column) < 1992` cannot use an index, but `date_column < '1992-01-01` can.
> - It is recommended to compare data of the same type and [character set and collation](/character-set-and-collation.md). Mixing types may require additional `cast` operations, or prevent indexes from being used.
> - You can also use `AND` (intersection) and `OR` (union) to combine the range query conditions of one column. For a multi-dimensional composite index, you can use conditions in multiple columns. For example, regarding the composite index `(a, b, c)`:
> - When `a` is an equivalent query, continue to figure out the query range of `b`; when `b` is also an equivalent query, continue to figure out the query range of `c`.
@@ -94,7 +168,7 @@ In the `WHERE`/`HAVING`/`ON` conditions, the TiDB optimizer analyzes the result
Currently, calculation tasks of TiDB can be divided into two categories: cop tasks and root tasks. A `cop[tikv]` task indicates that the operator is performed inside the TiKV coprocessor. A `root` task indicates that it will be completed inside of TiDB.
-One of the goals of SQL optimization is to push the calculation down to TiKV as much as possible. The Coprocessor in TiKV supports most of the built-in SQL functions (including the aggregate functions and the scalar functions), SQL `LIMIT` operations, index scans, and table scans. However, all `Join` operations can only be performed as root tasks in TiDB.
+One of the goals of SQL optimization is to push the calculation down to TiKV as much as possible. The Coprocessor in TiKV supports most of the built-in SQL functions (including the aggregate functions and the scalar functions), SQL `LIMIT` operations, index scans, and table scans.
### Operator info overview
diff --git a/explain-partitions.md b/explain-partitions.md
index b7c939233216b..d695576ae65f0 100644
--- a/explain-partitions.md
+++ b/explain-partitions.md
@@ -79,7 +79,7 @@ Starting from the inner-most (`└─TableFullScan_19`) operator and working bac
* TiDB successfully identified that only one partition (`p2017`) needed to be accessed. This is noted under `access object`.
* The partition itself was scanned in the operator `└─TableFullScan_19` and then `└─Selection_20` was applied to filter for rows that have a start date of `2017-06-01 00:00:00.000000`.
* The rows that match `└─Selection_20` are then stream aggregated in the coprocessor, which natively understands the `count` function.
-* Each coprocessor request then sends back one row to `└─TableReader_22` inside TiDB, which is then stream aggregated under `StreamAgg_21` and one row is returned to the client.
+* Each coprocessor request then sends back one row to `└─TableReader_22` inside TiDB, which is then stream aggregated under `StreamAgg_21` and one row is returned to the client.
In the following example, partition pruning does not eliminate any partitions:
diff --git a/explain-subqueries.md b/explain-subqueries.md
index 5f67a8c5ac1ca..72180298c4aef 100644
--- a/explain-subqueries.md
+++ b/explain-subqueries.md
@@ -54,19 +54,17 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2);
```
```sql
-+----------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+----------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
-| IndexJoin_14 | 5.00 | root | | inner join, inner:IndexLookUp_13, outer key:test.t2.t1_id, inner key:test.t1.id, equal cond:eq(test.t2.t1_id, test.t1.id) |
-| ├─StreamAgg_49(Build) | 5.00 | root | | group by:test.t2.t1_id, funcs:firstrow(test.t2.t1_id)->test.t2.t1_id |
-| │ └─IndexReader_50 | 5.00 | root | | index:StreamAgg_39 |
-| │ └─StreamAgg_39 | 5.00 | cop[tikv] | | group by:test.t2.t1_id, |
-| │ └─IndexFullScan_31 | 50000.00 | cop[tikv] | table:t2, index:t1_id(t1_id) | keep order:true |
-| └─IndexLookUp_13(Probe) | 1.00 | root | | |
-| ├─IndexRangeScan_11(Build) | 1.00 | cop[tikv] | table:t1, index:PRIMARY(id) | range: decided by [eq(test.t1.id, test.t2.t1_id)], keep order:false |
-| └─TableRowIDScan_12(Probe) | 1.00 | cop[tikv] | table:t1 | keep order:false |
-+----------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
-8 rows in set (0.00 sec)
++--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
+| IndexJoin_15 | 21.11 | root | | inner join, inner:TableReader_12, outer key:test.t2.t1_id, inner key:test.t1.id, equal cond:eq(test.t2.t1_id, test.t1.id) |
+| ├─StreamAgg_44(Build) | 21.11 | root | | group by:test.t2.t1_id, funcs:firstrow(test.t2.t1_id)->test.t2.t1_id |
+| │ └─IndexReader_45 | 21.11 | root | | index:StreamAgg_34 |
+| │ └─StreamAgg_34 | 21.11 | cop[tikv] | | group by:test.t2.t1_id, |
+| │ └─IndexFullScan_26 | 90000.00 | cop[tikv] | table:t2, index:t1_id(t1_id) | keep order:true |
+| └─TableReader_12(Probe) | 21.11 | root | | data:TableRangeScan_11 |
+| └─TableRangeScan_11 | 21.11 | cop[tikv] | table:t1 | range: decided by [test.t2.t1_id], keep order:false |
++--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
```
From the query results above, you can see that TiDB uses the index join operation `| IndexJoin_14` to join and transform the subquery. In the execution plan, the execution process is as follows:
@@ -85,17 +83,15 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t3);
```
```sql
-+----------------------------------+---------+-----------+-----------------------------+---------------------------------------------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+----------------------------------+---------+-----------+-----------------------------+---------------------------------------------------------------------------------------------------------------------------+
-| IndexJoin_17 | 1978.13 | root | | inner join, inner:IndexLookUp_16, outer key:test.t3.t1_id, inner key:test.t1.id, equal cond:eq(test.t3.t1_id, test.t1.id) |
-| ├─TableReader_44(Build) | 1978.00 | root | | data:TableFullScan_43 |
-| │ └─TableFullScan_43 | 1978.00 | cop[tikv] | table:t3 | keep order:false |
-| └─IndexLookUp_16(Probe) | 1.00 | root | | |
-| ├─IndexRangeScan_14(Build) | 1.00 | cop[tikv] | table:t1, index:PRIMARY(id) | range: decided by [eq(test.t1.id, test.t3.t1_id)], keep order:false |
-| └─TableRowIDScan_15(Probe) | 1.00 | cop[tikv] | table:t1 | keep order:false |
-+----------------------------------+---------+-----------+-----------------------------+---------------------------------------------------------------------------------------------------------------------------+
-6 rows in set (0.01 sec)
++-----------------------------+---------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++-----------------------------+---------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
+| IndexJoin_18 | 999.00 | root | | inner join, inner:TableReader_15, outer key:test.t3.t1_id, inner key:test.t1.id, equal cond:eq(test.t3.t1_id, test.t1.id) |
+| ├─IndexReader_41(Build) | 999.00 | root | | index:IndexFullScan_40 |
+| │ └─IndexFullScan_40 | 999.00 | cop[tikv] | table:t3, index:t1_id(t1_id) | keep order:false |
+| └─TableReader_15(Probe) | 999.00 | root | | data:TableRangeScan_14 |
+| └─TableRangeScan_14 | 999.00 | cop[tikv] | table:t1 | range: decided by [test.t3.t1_id], keep order:false |
++-----------------------------+---------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+
```
Semantically because `t3.t1_id` is guaranteed unique, it can be executed directly as an `INNER JOIN`.
@@ -111,17 +107,16 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2 WHERE t1_id != t1.int
```
```sql
-+-----------------------------+-----------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+-----------------------------+-----------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------+
-| MergeJoin_9 | 45446.40 | root | | semi join, left key:test.t1.id, right key:test.t2.t1_id, other cond:ne(test.t2.t1_id, test.t1.int_col) |
-| ├─IndexReader_24(Build) | 180000.00 | root | | index:IndexFullScan_23 |
-| │ └─IndexFullScan_23 | 180000.00 | cop[tikv] | table:t2, index:t1_id(t1_id) | keep order:true |
-| └─TableReader_22(Probe) | 56808.00 | root | | data:Selection_21 |
-| └─Selection_21 | 56808.00 | cop[tikv] | | ne(test.t1.id, test.t1.int_col) |
-| └─TableFullScan_20 | 71010.00 | cop[tikv] | table:t1 | keep order:true |
-+-----------------------------+-----------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------+
-6 rows in set (0.00 sec)
++-----------------------------+----------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++-----------------------------+----------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------+
+| MergeJoin_9 | 45446.40 | root | | semi join, left key:test.t1.id, right key:test.t2.t1_id, other cond:ne(test.t2.t1_id, test.t1.int_col) |
+| ├─IndexReader_24(Build) | 90000.00 | root | | index:IndexFullScan_23 |
+| │ └─IndexFullScan_23 | 90000.00 | cop[tikv] | table:t2, index:t1_id(t1_id) | keep order:true |
+| └─TableReader_22(Probe) | 56808.00 | root | | data:Selection_21 |
+| └─Selection_21 | 56808.00 | cop[tikv] | | ne(test.t1.id, test.t1.int_col) |
+| └─TableFullScan_20 | 71010.00 | cop[tikv] | table:t1 | keep order:true |
++-----------------------------+----------+-----------+------------------------------+--------------------------------------------------------------------------------------------------------+
```
From the result above, you can see that TiDB uses a `Semi Join` algorithm. Semi-join differs from inner join: semi-join only permits the first value on the right key (`t2.t1_id`), which means that the duplicates are eliminated as a part of the join operator task. The join algorithm is also Merge Join, which is like an efficient zipper-merge as the operator reads data from both the left and the right side in sorted order.
@@ -137,17 +132,16 @@ EXPLAIN SELECT * FROM t3 WHERE t1_id NOT IN (SELECT id FROM t1 WHERE int_col < 1
```
```sql
-+-----------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+-----------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------+
-| IndexMergeJoin_20 | 1598.40 | root | | anti semi join, inner:TableReader_15, outer key:test.t3.t1_id, inner key:test.t1.id |
-| ├─TableReader_28(Build) | 1998.00 | root | | data:TableFullScan_27 |
-| │ └─TableFullScan_27 | 1998.00 | cop[tikv] | table:t3 | keep order:false |
-| └─TableReader_15(Probe) | 1.00 | root | | data:Selection_14 |
-| └─Selection_14 | 1.00 | cop[tikv] | | lt(test.t1.int_col, 100) |
-| └─TableRangeScan_13 | 1.00 | cop[tikv] | table:t1 | range: decided by [test.t3.t1_id], keep order:true |
-+-----------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------+
-6 rows in set (0.00 sec)
++-----------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++-----------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------------------------------------------------+
+| IndexJoin_16 | 799.20 | root | | anti semi join, inner:TableReader_12, outer key:test.t3.t1_id, inner key:test.t1.id, equal cond:eq(test.t3.t1_id, test.t1.id) |
+| ├─TableReader_28(Build) | 999.00 | root | | data:TableFullScan_27 |
+| │ └─TableFullScan_27 | 999.00 | cop[tikv] | table:t3 | keep order:false |
+| └─TableReader_12(Probe) | 999.00 | root | | data:Selection_11 |
+| └─Selection_11 | 999.00 | cop[tikv] | | lt(test.t1.int_col, 100) |
+| └─TableRangeScan_10 | 999.00 | cop[tikv] | table:t1 | range: decided by [test.t3.t1_id], keep order:false |
++-----------------------------+---------+-----------+---------------+-------------------------------------------------------------------------------------------------------------------------------+
```
This query starts by reading the table `t3` and then probes the table `t1` based on the `PRIMARY KEY`. The join type is an _anti semi join_; anti because this example is for the non-existence of the value (`NOT IN`) and semi-join because only the first row needs to match before the join is rejected.
diff --git a/explore-htap.md b/explore-htap.md
index d73c2cfe13603..5d32d5cb3d9a2 100644
--- a/explore-htap.md
+++ b/explore-htap.md
@@ -44,7 +44,7 @@ Before exploring the features of TiDB HTAP, you need to deploy TiDB and the corr
- TiFlash
- If you have deployed a TiDB cluster with no TiFlash node, add the TiFlash nodes in the current TiDB cluster. For detailed information, see [Scale out a TiFlash cluster](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster).
- - If you have not deployed a TiDB cluster, see [Deploy a TiDB Cluster using TiUP](/production-deployment-using-tiup.md). Based on the minimal TiDB topology, you also need to deploy the [topology of TiFlash](/tiflash-deployment-topology.md).
+ - If you have not deployed a TiDB cluster, see [Deploy a TiDB Cluster using TiUP](/production-deployment-using-tiup.md). Based on the minimal TiDB topology, you also need to deploy the [topology of TiFlash](/tiflash-deployment-topology.md).
- When deciding how to choose the number of TiFlash nodes, consider the following scenarios:
- If your use case requires OLTP with small-scale analytical processing and Ad-Hoc queries, deploy one or several TiFlash nodes. They can dramatically increase the speed of analytic queries.
diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md
index eb46a0b0875c9..48a0dc68e435d 100644
--- a/exporting-grafana-snapshots.md
+++ b/exporting-grafana-snapshots.md
@@ -10,11 +10,11 @@ summary: Learn how to export snapshots of Grafana Dashboard, and how to visualiz
# Export Grafana Snapshots
-Metrics data is important in troubleshooting. When you request remote assistance, sometimes the support staff need to view the Grafana dashboards to diagnose problems. [MetricsTool](https://metricstool.pingcap.com/) can help export snapshots of Grafana dashboards as local files and visualize these snapshots. You can share these snapshots with outsiders and allow them to accurately read out the graphs, without giving out access to other sensitive information on the Grafana server.
+Metrics data is important in troubleshooting. When you request remote assistance, sometimes the support staff need to view the Grafana dashboards to diagnose problems. [MetricsTool](https://metricstool.pingcap.net/) can help export snapshots of Grafana dashboards as local files and visualize these snapshots. You can share these snapshots with outsiders and allow them to accurately read out the graphs, without giving out access to other sensitive information on the Grafana server.
## Usage
-MetricsTool can be accessed from . It consists of three sets of tools:
+MetricsTool can be accessed from . It consists of three sets of tools:
* **Export**: A user script running on the browser's Developer Tool, allowing you to download a snapshot of all visible panels in the current dashboard on any Grafana v6.x.x server.
diff --git a/faq/faq-overview.md b/faq/faq-overview.md
index 51fdac5de833d..2d86a673b2b86 100644
--- a/faq/faq-overview.md
+++ b/faq/faq-overview.md
@@ -10,7 +10,7 @@ This document summarizes frequently asked questions (FAQs) about TiDB.
| Category | Related documents |
| :------- | :------------------- |
| TiDB architecture and principles | [TiDB Architecture FAQs](/faq/tidb-faq.md) |
-| Deployment | - [Deployment FAQs](/faq/deploy-and-maintain-faq.md)
- [TiUP FAQs](/tiup/tiup-faq.md)
- [TiDB in Kubernetes FAQs](https://docs.pingcap.com/tidb-in-kubernetes/stable/faq)
|
+| Deployment | - [Deployment FAQs](/faq/deploy-and-maintain-faq.md)
- [TiUP FAQs](/tiup/tiup-faq.md)
- [TiDB on Kubernetes FAQs](https://docs.pingcap.com/tidb-in-kubernetes/stable/faq)
|
| Data migration | - [Data Migration FAQs](/faq/migration-tidb-faq.md)
- Data import
- [TiDB Lightning FAQs](/tidb-lightning/tidb-lightning-faq.md)
- [DM FAQs](/dm/dm-faq.md)
- Incremental data replication
- [TiCDC FAQs](/ticdc/ticdc-faq.md)
- [TiDB Binlog FAQs](/tidb-binlog/tidb-binlog-faq.md)
|
| Data backup and restore | [Backup & Restore FAQs](/br/backup-and-restore-faq.md) |
| SQL operations | [SQL FAQs](/faq/sql-faq.md) |
diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md
index a195904a7d55b..c639c9816fd58 100644
--- a/faq/manage-cluster-faq.md
+++ b/faq/manage-cluster-faq.md
@@ -87,7 +87,7 @@ Currently no.
You can scale out your TiDB cluster without interrupting the online services.
- If your cluster is deployed using [TiUP](/production-deployment-using-tiup.md), refer to [Scale a TiDB Cluster Using TiUP](/scale-tidb-using-tiup.md).
-- If your cluster is deployed using [TiDB Operator](/tidb-operator-overview.md) in Kubernetes, refer to [Manually Scale TiDB in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/scale-a-tidb-cluster).
+- If your cluster is deployed using [TiDB Operator](/tidb-operator-overview.md) on Kubernetes, refer to [Manually Scale TiDB on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/scale-a-tidb-cluster).
### How to scale TiDB horizontally?
@@ -334,7 +334,7 @@ TiKV implements the Column Family (CF) feature of RocksDB. By default, the KV da
### Why is the TiKV channel full?
- The Raftstore thread is too slow or blocked by I/O. You can view the CPU usage status of Raftstore.
-- TiKV is too busy (CPU, disk I/O, etc.) and cannot manage to handle it.
+- TiKV is too busy (such as CPU and disk I/O) and cannot manage to handle it.
### Why does TiKV frequently switch Region leader?
diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md
index 184e5be388ee0..b8bc8a7d455ba 100644
--- a/faq/migration-tidb-faq.md
+++ b/faq/migration-tidb-faq.md
@@ -138,7 +138,7 @@ No. Currently, the data replication depends on the application itself.
### How to migrate the traffic quickly?
-It is recommended to migrate application data from MySQL to TiDB using [TiDB Data Migration](/dm/dm-overview.md) tool. You can migrate the read and write traffic in batches by editing the network configuration as needed. Deploy a stable network LB (HAproxy, LVS, F5, DNS, etc.) on the upper layer, in order to implement seamless migration by directly editing the network configuration.
+It is recommended to migrate application data from MySQL to TiDB using [TiDB Data Migration](/dm/dm-overview.md) tool. You can migrate the read and write traffic in batches by editing the network configuration as needed. Deploy a stable network LB (such as HAproxy, LVS, F5, and DNS) on the upper layer, in order to implement seamless migration by directly editing the network configuration.
### Is there a limit for the total write and read capacity in TiDB?
diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md
index 8a606e4a56134..4de084b75282f 100644
--- a/faq/upgrade-faq.md
+++ b/faq/upgrade-faq.md
@@ -26,7 +26,7 @@ In addition, during the cluster upgrade, **DO NOT** execute any DDL statement. O
### How to upgrade TiDB using the binary?
-It is not recommended to upgrade TiDB using the binary. Instead, it is recommended to [upgrade TiDB using TiUP](/upgrade-tidb-using-tiup.md) or [upgrade a TiDB cluster in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster), which ensures both version consistency and compatibility.
+It is not recommended to upgrade TiDB using the binary. Instead, it is recommended to [upgrade TiDB using TiUP](/upgrade-tidb-using-tiup.md) or [upgrade a TiDB cluster on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster), which ensures both version consistency and compatibility.
## After upgrade FAQs
diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md
index 8583ee84742bf..d02310e009029 100644
--- a/functions-and-operators/precision-math.md
+++ b/functions-and-operators/precision-math.md
@@ -51,7 +51,7 @@ DECIMAL columns do not store a leading `+` character or `-` character or leading
DECIMAL columns do not permit values larger than the range implied by the column definition. For example, a `DECIMAL(3,0)` column supports a range of `-999` to `999`. A `DECIMAL(M,D)` column permits at most `M - D` digits to the left of the decimal point.
-For more information about the internal format of the DECIMAL values, see [`mydecimal.go`](https://github.com/pingcap/tidb/blob/master/types/mydecimal.go) in TiDB souce code.
+For more information about the internal format of the DECIMAL values, see [`mydecimal.go`](https://github.com/pingcap/tidb/blob/master/types/mydecimal.go) in TiDB souce code.
## Expression handling
@@ -81,7 +81,7 @@ If a number is inserted into an exact type column (DECIMAL or integer), it is in
To insert strings into numeric columns, TiDB handles the conversion from string to number as follows if the string has nonnumeric contents:
- In strict mode, a string (including an empty string) that does not begin with a number cannot be used as a number. An error, or a warning occurs.
-- A string that begins with a number can be converted, but the trailing nonnumeric portion is truncated. In strict mode, if the truncated portion contains anything other than spaces, an error, or a warning occurs.
+- A string that begins with a number can be converted, but the trailing nonnumeric portion is truncated. In strict mode, if the truncated portion contains anything other than spaces, an error, or a warning occurs.
By default, the result of the division by 0 is NULL and no warning. By setting the SQL mode appropriately, division by 0 can be restricted. If you enable the `ERROR_FOR_DIVISION_BY_ZERO` SQL mode, TiDB handles division by 0 differently:
diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md
index 7f4caecb2ec82..5617aa66f6846 100644
--- a/garbage-collection-configuration.md
+++ b/garbage-collection-configuration.md
@@ -54,7 +54,7 @@ Based on the `DISTRIBUTED` GC mode, the mechanism of GC in Compaction Filter use
enable-compaction-filter = true
```
-You can also enable this GC mechanism by modifying the configuration online. See the following example:
+You can also enable this GC mechanism by modifying the configuration dynamically. See the following example:
{{< copyable "sql" >}}
diff --git a/generated-columns.md b/generated-columns.md
index f188476df42b4..dfe993c6920d7 100644
--- a/generated-columns.md
+++ b/generated-columns.md
@@ -24,7 +24,7 @@ You can create an index on a generated column whether it is virtual or stored.
One of the main usage of generated columns is to extract data from the JSON data type and indexing the data.
-In both MySQL 5.7 and TiDB, columns of type JSON can not be indexed directly. That is, the following table schema is **not supported**:
+In both MySQL 5.7 and TiDB, columns of type JSON cannot be indexed directly. That is, the following table schema is **not supported**:
{{< copyable "sql" >}}
diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md
index a81f6871184ea..daf0ba5c74976 100644
--- a/grafana-overview-dashboard.md
+++ b/grafana-overview-dashboard.md
@@ -8,7 +8,7 @@ aliases: ['/docs/dev/grafana-overview-dashboard/','/docs/dev/reference/key-monit
If you use TiUP to deploy the TiDB cluster, the monitoring system (Prometheus & Grafana) is deployed at the same time. For more information, see [TiDB Monitoring Framework Overview](/tidb-monitoring-framework.md).
-The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Disk Performance, Performance\_overview, and so on. A lot of metrics are there to help you diagnose.
+The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Disk Performance, and Performance\_overview. A lot of metrics are there to help you diagnose.
For routine operations, you can get an overview of the component (PD, TiDB, TiKV) status and the entire cluster from the Overview dashboard, where the key metrics are displayed. This document provides a detailed description of these key metrics.
@@ -37,7 +37,7 @@ To understand the key metrics displayed on the Overview dashboard, check the fol
| TiDB | CPS By Instance | CPS By Instance: the command statistics on each TiDB instance, which is classified according to the success or failure of command execution results. |
| TiDB | Failed Query OPM | The statistics of error types (such as syntax errors and primary key conflicts) based on the errors occurred when executing SQL statements per second on each TiDB instance. The module in which the error occurs and the error code are included. |
| TiDB | Connection Count | The connection number of each TiDB instance. |
-| TiDB | Memory Usage | The memory usage statistics of each TiDB instance, which is divided into the memory occupied by processes and the memory applied by Golang on the heap. |
+| TiDB | Memory Usage | The memory usage statistics of each TiDB instance, which is divided into the memory occupied by processes and the memory applied by Golang on the heap. |
| TiDB | Transaction OPS | The number of transactions executed per second. |
| TiDB | Transaction Duration | The execution time of a transaction |
| TiDB | KV Cmd OPS | The number of executed KV commands. |
diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md
index b3f45669c78c4..8034d0628bfa5 100644
--- a/grafana-pd-dashboard.md
+++ b/grafana-pd-dashboard.md
@@ -8,7 +8,7 @@ aliases: ['/docs/dev/grafana-pd-dashboard/','/docs/dev/reference/key-monitoring-
If you use TiUP to deploy the TiDB cluster, the monitoring system (Prometheus & Grafana) is deployed at the same time. For more information, see [Overview of the Monitoring Framework](/tidb-monitoring-framework.md).
-The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Disk Performance, Performance\_overview, and so on. A lot of metrics are there to help you diagnose.
+The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Disk Performance, and Performance\_overview. A lot of metrics are there to help you diagnose.
You can get an overview of the component PD status from the PD dashboard, where the key metrics are displayed. This document provides a detailed description of these key metrics.
diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md
index f0b7b57dd13c8..7540a63867f70 100644
--- a/grafana-performance-overview-dashboard.md
+++ b/grafana-performance-overview-dashboard.md
@@ -7,7 +7,7 @@ summary: Learn key metrics displayed on the Performance Overview dashboard.
If you use TiUP to deploy the TiDB cluster, the monitoring system (Prometheus & Grafana) is deployed at the same time. For more information, see [TiDB Monitoring Framework Overview](/tidb-monitoring-framework.md).
-The Grafana dashboard is divided into a series of sub dashboards which include PD, TiDB, TiKV, Node_exporter, Overview, Performance Overview, and so on. A lot of metrics are there to help you diagnose.
+The Grafana dashboard is divided into a series of sub dashboards which include PD, TiDB, TiKV, Node_exporter, Overview, and Performance Overview. A lot of metrics are there to help you diagnose.
The Performance Overview dashboard orchestrates the metrics of TiDB, PD, and TiKV, and presents each of them in the following sections:
diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md
index c749569933e10..b0e921c6cc62e 100644
--- a/grafana-tidb-dashboard.md
+++ b/grafana-tidb-dashboard.md
@@ -8,7 +8,7 @@ aliases: ['/docs/dev/grafana-tidb-dashboard/','/docs/dev/reference/key-monitorin
If you use TiUP to deploy the TiDB cluster, the monitoring system (Prometheus & Grafana) is deployed at the same time. For the monitoring architecture, see [TiDB Monitoring Framework Overview](/tidb-monitoring-framework.md).
-The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Disk Performance, Performance\_overview, and so on. The TiDB dashboard consists of the TiDB panel and the TiDB Summary panel. The differences between the two panels are different in the following aspects:
+The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Disk Performance, and Performance\_overview. The TiDB dashboard consists of the TiDB panel and the TiDB Summary panel. The differences between the two panels are different in the following aspects:
- TiDB panel: provides as comprehensive information as possible for troubleshooting cluster anomalies.
- TiDB Summary Panel: extracts parts of the TiDB panel information with which users are most concerned, with some modifications. It provides data (such as QPS, TPS, response delay) that users care about in the daily database operations, which serves as the monitoring information to be displayed or reported.
@@ -43,7 +43,7 @@ To understand the key metrics displayed on the TiDB dashboard, check the followi
- Connection Count: the number of clients connected to each TiDB instance
- Open FD Count: the statistics of opened file descriptors of each TiDB instance
- Disconnection Count: the number of clients disconnected to each TiDB instance
- - Events OPM: the statistics of key events, such as "start", "close", "graceful-shutdown","kill", "hang", and so on
+ - Events OPM: the statistics of key events, such as "start", "close", "graceful-shutdown","kill", and "hang"
- Goroutine Count: the number of Goroutines on each TiDB instance
- Prepare Statement Count: the number of `Prepare` statements that are executed on each TiDB instance and the total count of them
- Keep Alive OPM: the number of times that the metrics are refreshed every minute on each TiDB instance. It usually needs no attention.
@@ -61,7 +61,7 @@ To understand the key metrics displayed on the TiDB dashboard, check the followi
- Session Retry Error OPS: the number of errors encountered during the transaction retry per second. This metric includes two error types: retry failure and exceeding the maximum number of retries
- Commit Token Wait Duration: the wait duration in the flow control queue during the transaction commit. If the wait duration is long, it means that the transaction to commit is too large and the flow is controlled. If the system still has resources available, you can speed up the commit process by increasing the system variable `tidb_committer_concurrency`.
- KV Transaction OPS: the number of transactions executed per second within each TiDB instance
- - A user transaction might trigger multiple transaction executions in TiDB, including reading internal metadata, atomic retries of the user transaction, and so on
+ - A user transaction might trigger multiple transaction executions in TiDB, including reading internal metadata and atomic retries of the user transaction
- TiDB's internally scheduled tasks also operate on the database through transactions, which are also included in this panel
- KV Transaction Duration: the time spent on executing transactions within each TiDB
- Transaction Regions Num: the number of Regions operated in the transaction
@@ -81,7 +81,7 @@ To understand the key metrics displayed on the TiDB dashboard, check the followi
- Parse Duration: the statistics of the parsing time of SQL statements
- Compile Duration: the statistics of the time of compiling the parsed SQL AST to the execution plan
- Execution Duration: the statistics of the execution time for SQL statements
- - Expensive Executor OPS: the statistics of the operators that consume many system resources per second, including `Merge Join`, `Hash Join`, `Index Look Up Join`, `Hash Agg`, `Stream Agg`, `Sort`, `TopN`, and so on
+ - Expensive Executor OPS: the statistics of the operators that consume many system resources per second, including `Merge Join`, `Hash Join`, `Index Look Up Join`, `Hash Agg`, `Stream Agg`, `Sort`, and `TopN`
- Queries Using Plan Cache OPS: the statistics of queries using the Plan Cache per second
- Plan Cache Miss OPS: the statistics of the number of times that the Plan Cache is missed per second
- Plan Cache Memory Usage: the total memory consumed by the execution plan cached in each TiDB instance
diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md
index e04f31cf7dec3..e2b42fae80b97 100644
--- a/grafana-tikv-dashboard.md
+++ b/grafana-tikv-dashboard.md
@@ -8,7 +8,7 @@ aliases: ['/docs/dev/grafana-tikv-dashboard/','/docs/dev/reference/key-monitorin
If you use TiUP to deploy the TiDB cluster, the monitoring system (Prometheus/Grafana) is deployed at the same time. For more information, see [Overview of the Monitoring Framework](/tidb-monitoring-framework.md).
-The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, Performance\_overview, and so on. A lot of metrics are there to help you diagnose.
+The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, and Performance\_overview. A lot of metrics are there to help you diagnose.
## TiKV-Details dashboard
@@ -36,7 +36,7 @@ This section provides a detailed description of these key metrics on the **TiKV-
### Errors
- Critical error: The number of critical errors
-- Server is busy: Indicates occurrences of events that make the TiKV instance unavailable temporarily, such as Write Stall, Channel Full, and so on. It should be `0` in normal case.
+- Server is busy: Indicates occurrences of events that make the TiKV instance unavailable temporarily, such as Write Stall, and Channel Full. It should be `0` in normal case.
- Server report failures: The number of error messages reported by server. It should be `0` in normal case.
- Raftstore error: The number of Raftstore errors per type on each TiKV instance
- Scheduler error: The number of scheduler errors per type on each TiKV instance
@@ -266,7 +266,7 @@ This section provides a detailed description of these key metrics on the **TiKV-
- Total Requests: The number of requests by type per second
- Handle duration: The histogram of time spent actually processing coprocessor requests per minute
- Total Request Errors: The number of request errors of Coprocessor per second. There should not be a lot of errors in a short time.
-- Total KV Cursor Operations: The total number of the KV cursor operations by type per second, such as `select`, `index`, `analyze_table`, `analyze_index`, `checksum_table`, `checksum_index`, and so on.
+- Total KV Cursor Operations: The total number of the KV cursor operations by type per second, such as `select`, `index`, `analyze_table`, `analyze_index`, `checksum_table`, and `checksum_index`.
- KV Cursor Operations: The histogram of KV cursor operations by type per second
- Total RocksDB Perf Statistics: The statistics of RocksDB performance
- Total Response Size: The total size of coprocessor response
diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md
index 5e046df42f5ae..54d18d47188e4 100644
--- a/hardware-and-software-requirements.md
+++ b/hardware-and-software-requirements.md
@@ -8,26 +8,31 @@ aliases: ['/docs/dev/hardware-and-software-requirements/','/docs/dev/how-to/depl
As an open source distributed NewSQL database with high performance, TiDB can be deployed in the Intel architecture server, ARM architecture server, and major virtualization environments and runs well. TiDB supports most of the major hardware networks and Linux operating systems.
-## Linux OS version requirements
-
-| Linux OS | Version |
-| :-----------------------:| :----------: |
-| Red Hat Enterprise Linux | 7.3 or later 7.x releases |
-| CentOS | 7.3 or later 7.x releases |
-| Oracle Enterprise Linux | 7.3 or later 7.x releases |
-| Amazon Linux | 2 |
-| Ubuntu LTS | 16.04 or later |
+## OS and platform requirements
+
+| Operating systems | Supported CPU architectures |
+| :--- | :--- |
+| Red Hat Enterprise Linux 8.4 or a later 8.x version | |
+| - Red Hat Enterprise Linux 7.3 or a later 7.x version
- CentOS 7.3 or a later 7.x version
| |
+| Amazon Linux 2 | |
+| Kylin Euler V10 SP1/SP2 | |
+| UOS V20 | |
+| macOS Catalina or later | |
+| Oracle Enterprise Linux 7.3 or a later 7.x version | x86_64 |
+| Ubuntu LTS 18.04 or later | x86_64 |
+| CentOS 8 Stream | |
+| Debian 9 (Stretch) or later | x86_64 |
+| Fedora 35 or later | x86_64 |
+| openSUSE Leap later than v15.3 (not including Tumbleweed) | x86_64 |
+| SUSE Linux Enterprise Server 15 | x86_64 |
> **Note:**
>
> - For Oracle Enterprise Linux, TiDB supports the Red Hat Compatible Kernel (RHCK) and does not support the Unbreakable Enterprise Kernel provided by Oracle Enterprise Linux.
-> - A large number of TiDB tests have been run on the CentOS 7.3 system, and in our community there are a lot of best practices in which TiDB is deployed on the Linux operating system. Therefore, it is recommended to deploy TiDB on CentOS 7.3 or later.
-> - The support for the Linux operating systems above includes the deployment and operation in physical servers as well as in major virtualized environments like VMware, KVM and XEN.
-> - Red Hat Enterprise Linux 8.0, CentOS 8 Stream, and Oracle Enterprise Linux 8.0 are not supported yet as the testing of these platforms is in progress.
-> - Support for CentOS 8 Linux is not planned because its upstream support ends on December 31, 2021.
+> - According to [CentOS Linux EOL](https://www.centos.org/centos-linux-eol/), the upstream support for CentOS Linux 8 ended on December 31, 2021. CentOS Stream 8 continues to be supported by the CentOS organization.
> - Support for Ubuntu 16.04 will be removed in future versions of TiDB. Upgrading to Ubuntu 18.04 or later is strongly recommended.
-
-Other Linux OS versions such as Debian Linux and Fedora Linux might work but are not officially supported.
+> - If you are using the 32-bit version of an operating system listed in the preceding table, TiDB **is not guaranteed** to be compilable, buildable or deployable on the 32-bit operating system and the corresponding CPU architecture, or TiDB does not actively adapt to the 32-bit operating system.
+> - Other operating system versions not mentioned above might work but are not officially supported.
## Software recommendations
diff --git a/information-schema/information-schema-tables.md b/information-schema/information-schema-tables.md
index 4c54c32d4e49d..d3d3613f2f25f 100644
--- a/information-schema/information-schema-tables.md
+++ b/information-schema/information-schema-tables.md
@@ -118,7 +118,7 @@ The description of columns in the `TABLES` table is as follows:
Most of the information in the table is the same as MySQL. Only two columns are newly defined by TiDB:
* `TIDB_TABLE_ID`: to indicate the internal ID of a table. This ID is unique in a TiDB cluster.
-* `TIDDB_ROW_ID_SHARDING_INFO`: to indicate the sharding type of a table. The possible values are as follows:
+* `TIDB_ROW_ID_SHARDING_INFO`: to indicate the sharding type of a table. The possible values are as follows:
- `"NOT_SHARDED"`: the table is not sharded.
- `"NOT_SHARDED(PK_IS_HANDLE)"`: the table that defines an integer Primary Key as its row id is not sharded.
- `"PK_AUTO_RANDOM_BITS={bit_number}"`: the table that defines an integer Primary Key as its row id is sharded because the Primary Key is assigned with `AUTO_RANDOM` attribute.
diff --git a/literal-values.md b/literal-values.md
index 6c81663b5a29d..b5e9f444e45cd 100644
--- a/literal-values.md
+++ b/literal-values.md
@@ -98,7 +98,7 @@ TiDB supports the following date formats:
* `'YYYYMMDDHHMMSS'` or `'YYMMDDHHMMSS'`: For example, `'20170824104520'` and `'170824104520'` are regarded as `'2017-08-24 10:45:20'`. However, if you provide a value out of range, such as `'170824304520'`, it is not treated as a valid date. Note that incorrect formats such as `YYYYMMDD HHMMSS`, `YYYYMMDD HH:MM:DD`, or `YYYY-MM-DD HHMMSS` will fail to insert.
* `YYYYMMDDHHMMSS` or `YYMMDDHHMMSS`: Note that these formats have no single or double quotes, but a number. For example, `20170824104520` is interpreted as `'2017-08-24 10:45:20'`.
-DATETIME or TIMESTAMP values can be followed by a fractional part, used to represent microseconds precision (6 digits). The fractional part should always be separated from the rest of the time by a decimal point `.`.
+DATETIME or TIMESTAMP values can be followed by a fractional part, used to represent microseconds precision (6 digits). The fractional part should always be separated from the rest of the time by a decimal point `.`.
The year value containing only two digits is ambiguous. It is recommended to use the four-digit year format. TiDB interprets the two-digit year value according to the following rules:
diff --git a/media/paging-size-impact-on-tpch.png b/media/paging-size-impact-on-tpch.png
new file mode 100644
index 0000000000000..ccaf7d21ead6b
Binary files /dev/null and b/media/paging-size-impact-on-tpch.png differ
diff --git a/media/performance/sql_plan_cache.png b/media/performance/sql_plan_cache.png
new file mode 100644
index 0000000000000..a74ef68fd104a
Binary files /dev/null and b/media/performance/sql_plan_cache.png differ
diff --git a/metadata-lock.md b/metadata-lock.md
index 1e343e0a19525..b442faf0b2b2f 100644
--- a/metadata-lock.md
+++ b/metadata-lock.md
@@ -80,10 +80,10 @@ Metadata lock can ensure that the metadata versions used by all transactions in
| `INSERT INTO t VALUES(1);` | |
| `BEGIN;` | |
| | `ALTER TABLE t ADD COLUMN b INT;` |
- | `SELECT * FROM t;`
(Uses the current metadata version of table `t`. Returns `(a=1，b=NULL)` and locks table `t`.) | |
+ | `SELECT * FROM t;`
(Uses the current metadata version of table `t`. Returns `(a=1, b=NULL)` and locks table `t`.) | |
| | `ALTER TABLE t ADD COLUMN c INT;` (blocked by Session 1) |
- At the repeatable read isolation level, from the transaction start to the timepoint of determining the metadata of a table, if a DDL that requires data changes is performed, such as adding an index, or changing column types, the DDL returns an error as follows:
+ At the repeatable read isolation level, from the transaction start to the timepoint of determining the metadata of a table, if a DDL that requires data changes is performed, such as adding an index, or changing column types, the DDL returns an error as follows:
| Session 1 | Session 2 |
|:---------------------------|:------------------------------------------|
diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md
index b04d1a93663a7..a3527c7989650 100644
--- a/migrate-from-csv-files-to-tidb.md
+++ b/migrate-from-csv-files-to-tidb.md
@@ -93,7 +93,7 @@ For more information on the configuration file, refer to [TiDB Lightning Configu
When you import data from CSV files with a uniform size of about 256 MiB, TiDB Lightning works in the best performance. However, if you import data from a single large CSV file, TiDB Lightning can only use one thread to process the import by default, which might slow down the import speed.
-To speed up the import, you can split a large CSV file into smaller ones. For a CSV file in a common format, before TiDB Lightning reads the entire file, it is hard to quickly locate the beginning and ending positions of each line. Therefore, TiDB Lightning does not automatically split CSV files by default. But if your CSV files to be imported meet certain format requirements, you can enable the `strict-format` mode. In this mode, TiDB Lightning automatically splits a single large CSV file into multiple files, each in about 256 MiB, and processes them in parallel.
+To speed up the import, you can split a large CSV file into smaller ones. For a CSV file in a common format, before TiDB Lightning reads the entire file, it is hard to quickly locate the beginning and ending positions of each line. Therefore, TiDB Lightning does not automatically split CSV files by default. But if your CSV files to be imported meet certain format requirements, you can enable the `strict-format` mode. In this mode, TiDB Lightning automatically splits a single large CSV file into multiple files, each in about 256 MiB, and processes them in parallel.
> **Note:**
>
diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md
index cb299729a0c4e..1744d5bdfc9e6 100644
--- a/migrate-small-mysql-shards-to-tidb.md
+++ b/migrate-small-mysql-shards-to-tidb.md
@@ -162,8 +162,8 @@ routes:
# Filters out some DDL events.
filters:
sale-filter-rule: # Filter name.
- schema-pattern: "store_*" # The binlog events or DDL SQL statements of upstream MySQL instance schemas that match schema-pattern are filtered by the rules below.
- table-pattern: "sale_*" # The binlog events or DDL SQL statements of upstream MySQL instance tables that match table-pattern are filtered by the rules below.
+ schema-pattern: "store_*" # The binlog events or DDL SQL statements of upstream MySQL instance schemas that match schema-pattern are filtered by the rules below.
+ table-pattern: "sale_*" # The binlog events or DDL SQL statements of upstream MySQL instance tables that match table-pattern are filtered by the rules below.
events: ["truncate table", "drop table", "delete"] # The binlog event array.
action: Ignore # The string (`Do`/`Ignore`). `Do` is the allow list. `Ignore` is the block list.
store-filter-rule:
diff --git a/mysql-compatibility.md b/mysql-compatibility.md
index 20ceadd70780c..2d54e54d2d307 100644
--- a/mysql-compatibility.md
+++ b/mysql-compatibility.md
@@ -12,9 +12,10 @@ However, some features of MySQL are not supported. This could be because there i
-- In addition, TiDB does not support the MySQL replication protocol, but provides specific tools to replicate data with MySQL.
- - Replicate data from MySQL: [TiDB Data Migration (DM)](/dm/dm-overview.md) is a tool that supports the full data migration and the incremental data replication from MySQL/MariaDB into TiDB.
- - Replicate data to MySQL: [TiCDC](/ticdc/ticdc-overview.md) is a tool for replicating the incremental data of TiDB by pulling TiKV change logs. TiCDC uses the [MySQL sink](/ticdc/ticdc-overview.md#sink-support) to replicate the incremental data of TiDB to MySQL.
+In addition, TiDB does not support the MySQL replication protocol, but provides specific tools to replicate data with MySQL:
+
+- Replicate data from MySQL: [TiDB Data Migration (DM)](/dm/dm-overview.md) is a tool that supports the full data migration and the incremental data replication from MySQL/MariaDB into TiDB.
+- Replicate data to MySQL: [TiCDC](/ticdc/ticdc-overview.md) is a tool for replicating the incremental data of TiDB by pulling TiKV change logs. TiCDC uses the [MySQL sink](/ticdc/ticdc-overview.md#sink-support) to replicate the incremental data of TiDB to MySQL.
@@ -22,7 +23,7 @@ However, some features of MySQL are not supported. This could be because there i
> **Note:**
>
-> This page refers to general differences between MySQL and TiDB. Refer to the dedicated pages for [Security](/security-compatibility-with-mysql.md) and [Pessimistic Transaction Mode](/pessimistic-transaction.md#difference-with-mysql-innodb) compatibility.
+> This page describes general differences between MySQL and TiDB. See the dedicated pages for [Security](/security-compatibility-with-mysql.md) and [Pessimistic Transaction Mode](/pessimistic-transaction.md#difference-with-mysql-innodb) compatibility.
@@ -150,6 +151,7 @@ In TiDB, all supported DDL changes are performed online. Compared with DDL opera
* Table Partitioning supports `HASH`, `RANGE`, and `LIST` partitioning types. For the unsupported partition type, the `Warning: Unsupported partition type %s, treat as normal table` error might be output, where `%s` is a specific partition type.
* Table Partitioning also supports `ADD`, `DROP`, and `TRUNCATE` operations. Other partition operations are ignored. The following Table Partition syntaxes are not supported:
- `PARTITION BY KEY`
+ - `PARTITION BY LINEAR KEY`
- `SUBPARTITION`
- `{CHECK|TRUNCATE|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD|REORGANIZE|COALESCE} PARTITION`
diff --git a/non-transactional-dml.md b/non-transactional-dml.md
index 9a322213c13f9..1b34115409a0d 100644
--- a/non-transactional-dml.md
+++ b/non-transactional-dml.md
@@ -125,7 +125,9 @@ SHOW PROCESSLIST;
### Terminate a non-transactional DML statement
-To terminate a non-transactional DML statement, you can use `KILL TIDB`. Then TiDB will cancel all batches after the batch that is currently being executed. You can get the execution result from the log.
+To terminate a non-transactional DML statement, you can use `KILL TIDB
`. Then TiDB will cancel all batches after the batch that is currently being executed. You can get the execution result from the log.
+
+For more information about `KILL TIDB`, see the reference [`KILL`](/sql-statements/sql-statement-kill.md).
### Query the batch-dividing statement
diff --git a/optimistic-transaction.md b/optimistic-transaction.md
index b2ab5dd5a1989..147ad9fa41966 100644
--- a/optimistic-transaction.md
+++ b/optimistic-transaction.md
@@ -31,7 +31,7 @@ To support distributed transactions, TiDB adopts two-phase commit (2PC) in optim
3. The client issues a write request.
- TiDB checks whether the written data satisfies constraints (to ensure the data types are correct, the NOT NULL constraint is met, etc.). **Valid data is stored in the private memory of this transaction in TiDB**.
+ TiDB checks whether the written data satisfies constraints (to ensure the data types are correct, the NOT NULL constraint is met). **Valid data is stored in the private memory of this transaction in TiDB**.
4. The client issues a commit request.
diff --git a/optimizer-hints.md b/optimizer-hints.md
index 8cf19d06cfaea..483a01c7a269d 100644
--- a/optimizer-hints.md
+++ b/optimizer-hints.md
@@ -249,20 +249,20 @@ explain select * from t1 where t1.a < (select /*+ NO_DECORRELATE() */ sum(t2.a)
```
```sql
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
-| id | estRows | task | access object | operator info |
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
-| Projection_10 | 10000.00 | root | | test.t1.a, test.t1.b |
-| └─Apply_12 | 10000.00 | root | | CARTESIAN inner join, other cond:lt(cast(test.t1.a, decimal(10,0) BINARY), Column#7) |
-| ├─TableReader_14(Build) | 10000.00 | root | | data:TableFullScan_13 |
-| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
-| └─MaxOneRow_15(Probe) | 1.00 | root | | |
-| └─HashAgg_27 | 1.00 | root | | funcs:sum(Column#10)->Column#7 |
-| └─IndexLookUp_28 | 1.00 | root | | |
-| ├─IndexRangeScan_25(Build) | 10.00 | cop[tikv] | table:t2, index:idx(b) | range: decided by [eq(test.t2.b, test.t1.b)], keep order:false, stats:pseudo |
-| └─HashAgg_17(Probe) | 1.00 | cop[tikv] | | funcs:sum(test.t2.a)->Column#10 |
-| └─TableRowIDScan_26 | 10.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
-+----------------------------------------+----------+-----------+------------------------+--------------------------------------------------------------------------------------+
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
+| Projection_10 | 10000.00 | root | | test.t1.a, test.t1.b |
+| └─Apply_12 | 10000.00 | root | | CARTESIAN inner join, other cond:lt(cast(test.t1.a, decimal(10,0) BINARY), Column#7) |
+| ├─TableReader_14(Build) | 10000.00 | root | | data:TableFullScan_13 |
+| │ └─TableFullScan_13 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+| └─MaxOneRow_15(Probe) | 10000.00 | root | | |
+| └─StreamAgg_20 | 10000.00 | root | | funcs:sum(Column#14)->Column#7 |
+| └─Projection_45 | 100000.00 | root | | cast(test.t2.a, decimal(10,0) BINARY)->Column#14 |
+| └─IndexLookUp_44 | 100000.00 | root | | |
+| ├─IndexRangeScan_42(Build) | 100000.00 | cop[tikv] | table:t2, index:idx(b) | range: decided by [eq(test.t2.b, test.t1.b)], keep order:false, stats:pseudo |
+| └─TableRowIDScan_43(Probe) | 100000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
++------------------------------------------+-----------+-----------+------------------------+--------------------------------------------------------------------------------------+
```
From the preceding execution plan, you can see that the optimizer does not perform decorrelation. The execution plan still contains the Apply operator. The filter condition (`t2.b = t1.b`) with the correlated column is still the filter condition when accessing the `t2` table.
diff --git a/oracle-functions-to-tidb.md b/oracle-functions-to-tidb.md
index 421cf66ef88cd..a065ce85a44cd 100644
--- a/oracle-functions-to-tidb.md
+++ b/oracle-functions-to-tidb.md
@@ -26,7 +26,7 @@ The following table shows the comparisons between some Oracle and TiDB functions
| Get the number of months between two dates | `MONTHS_BETWEEN(ENDDATE,SYSDATE)` | `TIMESTAMPDIFF(MONTH,SYSDATE,ENDDATE)` | The results of `MONTHS_BETWEEN()` in Oracle and `TIMESTAMPDIFF()` in TiDB are different. `TIMESTAMPDIFF()` returns an integer. Note that the parameters in the two functions are swapped. |
| Add `n` days to a date | `DATEVAL + n` | `DATE_ADD(dateVal,INTERVAL n DAY)` | `n` can be a negative value.|
| Add `n` months to a date | `ADD_MONTHS(dateVal,n)`| `DATE_ADD(dateVal,INTERVAL n MONTH)` | `n` can be a negative value. |
-| Get the day of a date | `TRUNC(SYSDATE)` | `CAST(NOW() AS DATE)``DATE_FORMAT(NOW(),'%Y-%m-%d')` | In TiDB, `CAST` and `DATE_FORMAT` return the same result. |
+| Get the day of a date | `TRUNC(SYSDATE)` | `CAST(NOW() AS DATE)``DATE_FORMAT(NOW(),'%Y-%m-%d')` | In TiDB, `CAST` and `DATE_FORMAT` return the same result. |
| Get the month of a date | `TRUNC(SYSDATE,'mm')` | `DATE_ADD(CURDATE(),interval - day(CURDATE()) + 1 day)` | |
| Truncate a value | `TRUNC(2.136) = 2`
`TRUNC(2.136,2) = 2.13` | `TRUNCATE(2.136,0) = 2`
`TRUNCATE(2.136,2) = 2.13` | Data precision is preserved. Truncate the corresponding decimal places without rounding. |
| Get the next value in a sequence | `sequence_name.NEXTVAL` | `NEXTVAL(sequence_name)` | |
@@ -41,7 +41,7 @@ The following table shows the comparisons between some Oracle and TiDB functions
| Get the position of a substring | `INSTR('abcdefg','b',1,1)` | `INSTR('abcdefg','b')` | Search from the first character of `'abcdefg'` and return the position of the first occurrence of `'b'`. |
| Get the position of a substring | `INSTR('stst','s',1,2)` | `LENGTH(SUBSTRING_INDEX('stst','s',2)) + 1` | Search from the first character of `'stst'` and return the position of the second occurrence of `'s'`. |
| Get the position of a substring | `INSTR('abcabc','b',2,1)` | `LOCATE('b','abcabc',2)` | Search from the second character of `abcabc` and return the position of the first occurrence of `b`. |
-| Concatenate values of a column | `LISTAGG(CONCAT(E.dimensionid,'---',E.DIMENSIONNAME),'***') within GROUP(ORDER BY DIMENSIONNAME)` | `GROUP_CONCAT(CONCAT(E.dimensionid,'---',E.DIMENSIONNAME) ORDER BY DIMENSIONNAME SEPARATOR '***')` | Concatenate values of a specified column to one row with the `***` delimiter. |
+| Concatenate values of a column | `LISTAGG(CONCAT(E.dimensionid,'---',E.DIMENSIONNAME),'***') within GROUP(ORDER BY DIMENSIONNAME)` | `GROUP_CONCAT(CONCAT(E.dimensionid,'---',E.DIMENSIONNAME) ORDER BY DIMENSIONNAME SEPARATOR '***')` | Concatenate values of a specified column to one row with the `***` delimiter. |
| Convert an ASCII code to a character | `CHR(n)` | `CHAR(n)` | The Tab (`CHR(9)`), LF (`CHR(10)`), and CR (`CHR(13)`) characters in Oracle correspond to `CHAR(9)`, `CHAR(10)`, and `CHAR(13)` in TiDB. |
## Comparisons of syntax
diff --git a/partitioned-table.md b/partitioned-table.md
index b412bccac7c90..47898b81c862d 100644
--- a/partitioned-table.md
+++ b/partitioned-table.md
@@ -59,7 +59,7 @@ PARTITION BY RANGE (store_id) (
In this partition scheme, all rows corresponding to employees whose `store_id` is 1 through 5 are stored in the `p0` partition while all employees whose `store_id` is 6 through 10 are stored in `p1`. Range partitioning requires the partitions to be ordered, from lowest to highest.
-If you insert a row of data `(72, 'Tom', 'John', '2015-06-25', NULL, NULL, 15)`, it falls in the `p2` partition. But if you insert a record whose `store_id` is larger than 20, an error is reported because TiDB can not know which partition this record should be inserted into. In this case, you can use `MAXVALUE` when creating a table:
+If you insert a row of data `(72, 'Tom', 'John', '2015-06-25', NULL, NULL, 15)`, it falls in the `p2` partition. But if you insert a record whose `store_id` is larger than 20, an error is reported because TiDB cannot know which partition this record should be inserted into. In this case, you can use `MAXVALUE` when creating a table:
{{< copyable "sql" >}}
@@ -560,6 +560,16 @@ MOD(YEAR('2005-09-01'),4)
= 1
```
+#### How TiDB handles Linear Hash partitions
+
+Before v6.4.0, if you execute DDL statements of [MySQL Linear Hash](https://dev.mysql.com/doc/refman/5.7/en/partitioning-linear-hash.html) partitions in TiDB, TiDB can only create non-partitioned tables. In this case, if you still want to use partitioned tables in TiDB, you need to modify the DDL statements.
+
+Since v6.4.0, TiDB supports parsing the MySQL `PARTITION BY LINEAR HASH` syntax but ignores the `LINEAR` keyword in it. If you have some existing DDL and DML statements of MySQL Linear Hash partitions, you can execute them in TiDB without modification:
+
+- For a `CREATE` statement of MySQL Linear Hash partitions, TiDB will create a non-linear Hash partitioned table (note that there is no Linear Hash partitioned table in TiDB). If the number of partitions is a power of 2, the rows in the TiDB Hash partitioned table are distributed the same as that in the MySQL Linear Hash partitioned table. Otherwise, the distribution of these rows in TiDB is different from MySQL. This is because non-linear partitioned tables use a simple "modulus number of partition", while linear partitioned tables use "modulus next power of 2 and fold the values between the number of partitions and the next power of 2". For details, see [#38450](https://github.com/pingcap/tidb/issues/38450).
+
+- For all other statements of MySQL Linear Hash partitions, they work in TiDB the same as that in MySQL, except that the rows are distributed differently if the number of partitions is not a power of 2, which will give different results for [partition selection](#partition-selection), `TRUNCATE PARTITION`, and `EXCHANGE PARTITION`.
+
### How TiDB partitioning handles NULL
It is allowed in TiDB to use `NULL` as the calculation result of a partitioning expression.
@@ -876,7 +886,7 @@ Currently, partition pruning does not work with `LIKE` conditions.
### Some cases for partition pruning to take effect
-1. Partition pruning uses the query conditions on the partitioned table, so if the query conditions can not be pushed down to the partitioned table according to the planner's optimization rules, partition pruning does not apply for this query.
+1. Partition pruning uses the query conditions on the partitioned table, so if the query conditions cannot be pushed down to the partitioned table according to the planner's optimization rules, partition pruning does not apply for this query.
For example:
@@ -901,7 +911,7 @@ Currently, partition pruning does not work with `LIKE` conditions.
explain select * from t1 left join t2 on t1.x = t2.x and t2.x > 5;
```
- In this query, `t2.x > 5` can not be pushed down to the `t1` partitioned table, so partition pruning would not take effect for this query.
+ In this query, `t2.x > 5` cannot be pushed down to the `t1` partitioned table, so partition pruning would not take effect for this query.
2. Since partition pruning is done during the plan optimizing phase, it does not apply for those cases that filter conditions are unknown until the execution phase.
@@ -923,7 +933,7 @@ Currently, partition pruning does not work with `LIKE` conditions.
This query reads a row from `t2` and uses the result for the subquery on `t1`. Theoretically, partition pruning could benefit from `t1.x > val` expression in the subquery, but it does not take effect there as that happens in the execution phase.
-3. As a result of a limitation from current implementation, if a query condition can not be pushed down to TiKV, it can not be used by the partition pruning.
+3. As a result of a limitation from current implementation, if a query condition cannot be pushed down to TiKV, it cannot be used by the partition pruning.
Take the `fn(col)` expression as an example. If the TiKV coprocessor supports this `fn` function, `fn(col)` may be pushed down to the the leaf node (that is, partitioned table) according to the predicate push-down rule during the plan optimizing phase, and partition pruning can use it.
@@ -1245,7 +1255,7 @@ PARTITION BY HASH( YEAR(col2) )
PARTITIONS 4;
```
-In the above examples, the primary key does not include all columns referenced in the partitioning expression. After adding the missing column in the primary key, the `CREATE TABLE` statement becomes valid:
+In the above examples, the primary key does not include all columns referenced in the partitioning expression. After adding the missing column in the primary key, the `CREATE TABLE` statement becomes valid:
{{< copyable "sql" >}}
@@ -1637,10 +1647,10 @@ mysql> explain select /*+ TIDB_INLJ(t1, t2) */ t1.* from t1, t2 where t2.code =
| ├─TableReader_16(Build) | 9.99 | root | | data:Selection_15 |
| │ └─Selection_15 | 9.99 | cop[tikv] | | eq(test.t2.code, 0), not(isnull(test.t2.id)) |
| │ └─TableFullScan_14 | 10000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo |
-| └─IndexLookUp_10(Probe) | 1.25 | root | partition:all | |
-| ├─Selection_9(Build) | 1.25 | cop[tikv] | | not(isnull(test.t1.id)) |
-| │ └─IndexRangeScan_7 | 1.25 | cop[tikv] | table:t1, index:id(id) | range: decided by [eq(test.t1.id, test.t2.id)], keep order:false, stats:pseudo |
-| └─TableRowIDScan_8(Probe) | 1.25 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+| └─IndexLookUp_10(Probe) | 12.49 | root | partition:all | |
+| ├─Selection_9(Build) | 12.49 | cop[tikv] | | not(isnull(test.t1.id)) |
+| │ └─IndexRangeScan_7 | 12.50 | cop[tikv] | table:t1, index:id(id) | range: decided by [eq(test.t1.id, test.t2.id)], keep order:false, stats:pseudo |
+| └─TableRowIDScan_8(Probe) | 12.49 | cop[tikv] | table:t1 | keep order:false, stats:pseudo |
+---------------------------------+----------+-----------+------------------------+---------------------------------------------------------------------------------------------------------------------+
8 rows in set (0.00 sec)
```
diff --git a/pd-configuration-file.md b/pd-configuration-file.md
index cd6bb97283d71..efd3ead77fd64 100644
--- a/pd-configuration-file.md
+++ b/pd-configuration-file.md
@@ -221,7 +221,7 @@ Configuration items related to scheduling
### `max-store-down-time`
-+ The downtime after which PD judges that the disconnected store can not be recovered. When PD fails to receive the heartbeat from a store after the specified period of time, it adds replicas at other nodes.
++ The downtime after which PD judges that the disconnected store cannot be recovered. When PD fails to receive the heartbeat from a store after the specified period of time, it adds replicas at other nodes.
+ Default value: `30m`
### `max-store-preparing-time` New in v6.1.0
@@ -324,7 +324,7 @@ Configuration items related to replicas
### `max-replicas`
-+ The number of replicas, that is, the sum of the number of leaders and followers. The default value `3` means 1 leader and 2 followers. When this configuration is modified online, PD will schedule Regions in the background so that the number of replicas matches this configuration.
++ The number of replicas, that is, the sum of the number of leaders and followers. The default value `3` means 1 leader and 2 followers. When this configuration is modified dynamically, PD will schedule Regions in the background so that the number of replicas matches this configuration.
+ Default value: `3`
### `location-labels`
@@ -357,7 +357,7 @@ Configuration items related to replicas
> **Note:**
>
-> If you have upgraded your cluster from a TiDB 4.0 version to the current version, the behavior of `flow-round-by-digit` after the upgrading and the behavior of `trace-region-flow` before the upgrading are consistent by default. This means that if the value of `trace-region-flow` is false before the upgrading, the value of `flow-round-by-digit` after the upgrading is 127; if the value of `trace-region-flow` is `true` before the upgrading, the value of `flow-round-by-digit` after the upgrading is `3`.
+> If you have upgraded your cluster from a TiDB 4.0 version to the current version, the behavior of `flow-round-by-digit` after the upgrading and the behavior of `trace-region-flow` before the upgrading are consistent by default. This means that if the value of `trace-region-flow` is false before the upgrading, the value of `flow-round-by-digit` after the upgrading is 127; if the value of `trace-region-flow` is `true` before the upgrading, the value of `flow-round-by-digit` after the upgrading is `3`.
## `label-property`
@@ -406,4 +406,4 @@ Configuration items related to the [TiDB Dashboard](/dashboard/dashboard-intro.m
## `replication-mode`
-Configuration items related to the replication mode of all Regions. See [Enable the DR Auto-Sync mode](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode) for details.
\ No newline at end of file
+Configuration items related to the replication mode of all Regions. See [Enable the DR Auto-Sync mode](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode) for details.
diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md
index fef2b061f6a26..9a4770622d38b 100644
--- a/performance-tuning-methods.md
+++ b/performance-tuning-methods.md
@@ -52,7 +52,7 @@ The Performance Overview dashboard orchestrates the metrics of TiDB, PD, and TiK
- Database time and SQL execution time overview: Color-coded SQL types, database time by SQL execution phase, and database time of different requests help you quickly identify database workload characteristics and performance bottlenecks.
- Key metrics and resource utilization: Contains database QPS, connection information, request command types between the applications and the database, database internal TSO and KV request OPS, and TiDB/TiKV resource usage.
-- Top-down latency breakdown: Contains a comparison of query latency and connection idle time, breakdown of query latency, latency of TSO requests and KV requests in SQL execution, and breakdown of TiKV internal write latency, etc.
+- Top-down latency breakdown: Contains a comparison of query latency and connection idle time, breakdown of query latency, latency of TSO requests and KV requests in SQL execution, and breakdown of TiKV internal write latency.
### Database time and SQL execution time overview
@@ -137,7 +137,7 @@ By checking the following three panels in Performance Overview, you can learn th
- No prepared plan cache is hit: The number of plan cache hit per second is 0. The application is using the query interface, or cached plans are cleaned up by calling the StmtClose command after each StmtExecute execution.
- All prepared plan cache is hit: The number of hits per second is equal to the number of StmtExecute commands per second.
- - Some prepared plan cache is hit: The number of hits per second is fewer than the number of StmtExecute commands per second. Prepared plan cache has known limitations, for example, it does not support subqueries, SQL statements with subqueries can not utilize prepared plan cache.
+ - Some prepared plan cache is hit: The number of hits per second is fewer than the number of StmtExecute commands per second. Prepared plan cache has known limitations, for example, it does not support subqueries, SQL statements with subqueries cannot utilize prepared plan cache.
**Example 1: TPC-C workload**
@@ -409,7 +409,7 @@ Common scenarios where `Commit Log Duration` is long:
- `raftstore.store-pool-size` is either excessively small or large (an excessively large value might also cause performance degradation)
- The I/O latency is high, resulting in high `Append Log Duration` latency
- The network latency between TiKV nodes is high
-- The number of the gRPC threads are too small, CPU usage is uneven among the GRPC threads.
+- The number of the gRPC threads are too small, CPU usage is uneven among the GRPC threads.
Common scenarios where `Apply Log Duration` is long:
diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md
index 541b528a2db2a..286073c1e4722 100644
--- a/pessimistic-transaction.md
+++ b/pessimistic-transaction.md
@@ -178,7 +178,7 @@ This feature is enabled by default. To disable it, modify the TiKV configuration
pipelined = false
```
-If the TiKV cluster is v4.0.9 or later, you can also dynamically disable this feature by [modifying TiKV configuration online](/dynamic-config.md#modify-tikv-configuration-online):
+If the TiKV cluster is v4.0.9 or later, you can also dynamically disable this feature by [modifying TiKV configuration dynamically](/dynamic-config.md#modify-tikv-configuration-dynamically):
{{< copyable "sql" >}}
@@ -211,7 +211,7 @@ This feature is enabled by default. To disable it, modify the TiKV configuration
in-memory = false
```
-To dynamically disable this feature, modify the TiKV configuration online:
+To dynamically disable this feature, modify the TiKV configuration dynamically:
{{< copyable "sql" >}}
diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md
index ce3f70bef0eca..317037e7c8a29 100644
--- a/production-deployment-using-tiup.md
+++ b/production-deployment-using-tiup.md
@@ -71,7 +71,7 @@ Log in to the control machine using a regular user account (take the `tidb` user
tiup update --self && tiup update cluster
```
- If `“Update successfully!”` is displayed, the TiUP cluster is updated successfully.
+ If `Update successfully!` is displayed, the TiUP cluster is updated successfully.
5. Verify the current version of your TiUP cluster:
@@ -137,7 +137,7 @@ To prepare the TiUP offline component package, you can manually pack an offline
`tidb-community-server-${version}-linux-amd64.tar.gz` is an independent offline environment package.
-3. Customize the offline mirror, or adjust the contents of an existing offline mirror.
+3. Customize the offline mirror, or adjust the contents of an existing offline mirror.
If you want to adjust an existing offline mirror (such as adding a new version of a component), take the following steps:
@@ -149,7 +149,7 @@ To prepare the TiUP offline component package, you can manually pack an offline
tiup mirror clone tiup-custom-mirror-v1.11.0 --tiup v1.11.0 --cluster v1.11.0
```
- If you only need the components for a particular platform, you can specify them using the `--os` or `--arch` parameters.
+ If you only need the components for a particular platform, you can specify them using the `--os` or `--arch` parameters.
2. Refer to the step 2 of "Pull the mirror using TiUP", and send this incomplete offline mirror to the control machine in the isolated environment.
@@ -266,7 +266,7 @@ The following examples cover seven common scenarios. You need to modify the conf
| HTAP | [Deploy the TiFlash topology](/tiflash-deployment-topology.md) | [Simple TiFlash configuration template](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml)
[Full TiFlash configuration template](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) | This is to deploy TiFlash along with the minimal cluster topology. TiFlash is a columnar storage engine, and gradually becomes a standard cluster topology. |
| Replicate incremental data using [TiCDC](/ticdc/ticdc-overview.md) | [Deploy the TiCDC topology](/ticdc-deployment-topology.md) | [Simple TiCDC configuration template](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml)
[Full TiCDC configuration template](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) | This is to deploy TiCDC along with the minimal cluster topology. TiCDC supports multiple downstream platforms, such as TiDB, MySQL, and MQ. |
| Replicate incremental data using [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) | [Deploy the TiDB Binlog topology](/tidb-binlog-deployment-topology.md) | [Simple TiDB Binlog configuration template (MySQL as downstream)](https://github.com/pingcap/docs/blob/master/config-templates/simple-tidb-binlog.yaml)
[Simple TiDB Binlog configuration template (Files as downstream)](https://github.com/pingcap/docs/blob/master/config-templates/simple-file-binlog.yaml)
[Full TiDB Binlog configuration template](https://github.com/pingcap/docs/blob/master/config-templates/complex-tidb-binlog.yaml) | This is to deploy TiDB Binlog along with the minimal cluster topology. |
-| Use OLAP on Spark | [Deploy the TiSpark topology](/tispark-deployment-topology.md) | [Simple TiSpark configuration template](https://github.com/pingcap/docs/blob/master/config-templates/simple-tispark.yaml)
[Full TiSpark configuration template](https://github.com/pingcap/docs/blob/master/config-templates/complex-tispark.yaml) | This is to deploy TiSpark along with the minimal cluster topology. TiSpark is a component built for running Apache Spark on top of TiDB/TiKV to answer the OLAP queries. Currently, TiUP cluster's support for TiSpark is still **experimental**. |
+| Use OLAP on Spark | [Deploy the TiSpark topology](/tispark-deployment-topology.md) | [Simple TiSpark configuration template](https://github.com/pingcap/docs/blob/master/config-templates/simple-tispark.yaml)
[Full TiSpark configuration template](https://github.com/pingcap/docs/blob/master/config-templates/complex-tispark.yaml) | This is to deploy TiSpark along with the minimal cluster topology. TiSpark is a component built for running Apache Spark on top of TiDB/TiKV to answer the OLAP queries. Currently, TiUP cluster's support for TiSpark is still **experimental**. |
| Deploy multiple instances on a single machine | [Deploy a hybrid topology](/hybrid-deployment-topology.md) | [Simple configuration template for hybrid deployment](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml)
[Full configuration template for hybrid deployment](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) | The deployment topologies also apply when you need to add extra configurations for the directory, port, resource ratio, and label. |
| Deploy TiDB clusters across data centers | [Deploy a geo-distributed deployment topology](/geo-distributed-deployment-topology.md) | [Configuration template for geo-distributed deployment](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | This topology takes the typical architecture of three data centers in two cities as an example. It introduces the geo-distributed deployment architecture and the key configuration that requires attention. |
diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md
index b41738239acca..d5c29d26d0da7 100644
--- a/quick-start-with-tidb.md
+++ b/quick-start-with-tidb.md
@@ -18,7 +18,7 @@ This guide walks you through the quickest way to get started with TiDB. For non-
> - The deployment method provided in this guide is **ONLY FOR** quick start, **NOT FOR** production.
>
> - To deploy an on-premises production cluster, see [production installation guide](/production-deployment-using-tiup.md).
-> - To deploy TiDB in Kubernetes, see [Get Started with TiDB in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/get-started).
+> - To deploy TiDB on Kubernetes, see [Get Started with TiDB on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/get-started).
> - To manage TiDB in the cloud, see [TiDB Cloud Quick Start](https://docs.pingcap.com/tidbcloud/tidb-cloud-quickstart).
## Deploy a local test cluster
@@ -322,7 +322,7 @@ Other requirements for the target machine:
> **Note:**
>
- > After the installation, TiUP displays the absolute path of the corresponding Shell profile file. You need to modify `${your_shell_profile}` in the following `source` command according to the path.
+ > After the installation, TiUP displays the absolute path of the corresponding Shell profile file. You need to modify `${your_shell_profile}` in the following `source` command according to the path.
{{< copyable "shell-regular" >}}
diff --git a/read-historical-data.md b/read-historical-data.md
index ca2547753ff9b..839bea1dd8d78 100644
--- a/read-historical-data.md
+++ b/read-historical-data.md
@@ -136,7 +136,7 @@ Pay special attention to the following:
3 rows in set (0.00 sec)
```
-7. Set the `tidb_snapshot` variable to be "" (empty string) and you can read the data from the latest version:
+7. Set the `tidb_snapshot` variable to be "" (empty string) and you can read the data from the latest version:
```sql
mysql> set @@tidb_snapshot="";
diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md
index 9898db92814da..441e93866302e 100644
--- a/releases/release-2.1-rc.1.md
+++ b/releases/release-2.1-rc.1.md
@@ -69,7 +69,7 @@ On August 24, 2018, TiDB 2.1 RC1 is released! Compared with TiDB 2.1 Beta, this
- Add the verification of the number of `PlaceHolder`s in the `Prepare` statement [#7162](https://github.com/pingcap/tidb/pull/7162)
- Support `set character_set_results = null` [#7353](https://github.com/pingcap/tidb/pull/7353)
- Support the `flush status` syntax [#7369](https://github.com/pingcap/tidb/pull/7369)
- - Fix the column size of `SET` and `ENUM` types in `information_schema` [#7347](https://github.com/pingcap/tidb/pull/7347)
+ - Fix the column size of `SET` and `ENUM` types in `information_schema` [#7347](https://github.com/pingcap/tidb/pull/7347)
- Support the `NATIONAL CHARACTER` syntax of statements for creating a table [#7378](https://github.com/pingcap/tidb/pull/7378)
- Support the `CHARACTER SET` syntax in the `LOAD DATA` statement [#7391](https://github.com/pingcap/tidb/pull/7391)
- Fix the column information of the `SET` and `ENUM` types [#7417](https://github.com/pingcap/tidb/pull/7417)
@@ -91,7 +91,7 @@ On August 24, 2018, TiDB 2.1 RC1 is released! Compared with TiDB 2.1 Beta, this
- Fix the `ADD INDEX` issue in some cases [#7142](https://github.com/pingcap/tidb/pull/7142)
- Increase the speed of adding `UNIQUE-KEY` index operation largely [#7132](https://github.com/pingcap/tidb/pull/7132)
- Fix the truncating issue of the prefix index in UTF-8 character set [#7109](https://github.com/pingcap/tidb/pull/7109)
- - Add the environment variable `tidb_ddl_reorg_priority` to control the priority of the `add-index` operation [#7116](https://github.com/pingcap/tidb/pull/7116)
+ - Add the environment variable `tidb_ddl_reorg_priority` to control the priority of the `add-index` operation [#7116](https://github.com/pingcap/tidb/pull/7116)
- Fix the display issue of `AUTO-INCREMENT` in `information_schema.tables` [#7037](https://github.com/pingcap/tidb/pull/7037)
- Support the `admin show ddl jobs ` command and support output specified number of DDL jobs [#7028](https://github.com/pingcap/tidb/pull/7028)
- Support parallel DDL job execution [#6955](https://github.com/pingcap/tidb/pull/6955)
diff --git a/releases/release-2.1.10.md b/releases/release-2.1.10.md
index e62f7eb42f623..6c4a611915bf4 100644
--- a/releases/release-2.1.10.md
+++ b/releases/release-2.1.10.md
@@ -31,7 +31,7 @@ TiDB Ansible version: 2.1.10
- Check the parameter validity of `PERIOD_ADD` [#10430](https://github.com/pingcap/tidb/pull/10430)
- Fix the issue that the behavior of the invalid `YEAR` string in TiDB is incompatible with that in MySQL [#10493](https://github.com/pingcap/tidb/pull/10493)
- Support the `ALTER DATABASE` syntax [#10503](https://github.com/pingcap/tidb/pull/10503)
-- Fix the issue that the `SLOW_QUERY` memory engine reports an error when no `;` exists in the slow query statement [#10536](https://github.com/pingcap/tidb/pull/10536)
+- Fix the issue that the `SLOW_QUERY` memory engine reports an error when no `;` exists in the slow query statement [#10536](https://github.com/pingcap/tidb/pull/10536)
- Fix the issue that the `Add index` operation in partitioned tables cannot be canceled in some cases [#10533](https://github.com/pingcap/tidb/pull/10533)
- Fix the issue that the OOM panic cannot be recovered in some cases [#10545](https://github.com/pingcap/tidb/pull/10545)
- Improve the security of the DDL operation rewriting the table metadata [#10547](https://github.com/pingcap/tidb/pull/10547)
diff --git a/releases/release-2.1.11.md b/releases/release-2.1.11.md
index 3cc7e566edeba..a94cb39cd44d5 100644
--- a/releases/release-2.1.11.md
+++ b/releases/release-2.1.11.md
@@ -13,10 +13,10 @@ TiDB Ansible version: 2.1.11
## TiDB
-- Fix the issue that incorrect schema is used for `delete from join` [#10595](https://github.com/pingcap/tidb/pull/10595)
+- Fix the issue that incorrect schema is used for `delete from join` [#10595](https://github.com/pingcap/tidb/pull/10595)
- Fix the issue that the built-in `CONVERT()` may return incorrect field type [#10263](https://github.com/pingcap/tidb/pull/10263)
- Merge non-overlapped feedback when updating bucket count [#10569](https://github.com/pingcap/tidb/pull/10569)
-- Fix calculation errors of `unix_timestamp()-unix_timestamp(now())` [#10491](https://github.com/pingcap/tidb/pull/10491)
+- Fix calculation errors of `unix_timestamp()-unix_timestamp(now())` [#10491](https://github.com/pingcap/tidb/pull/10491)
- Fix the incompatibility issue of `period_diff` with MySQL 8.0 [#10501](https://github.com/pingcap/tidb/pull/10501)
- Skip `Virtual Column` when collecting statistics to avoid exceptions [#10628](https://github.com/pingcap/tidb/pull/10628)
- Support the `SHOW OPEN TABLES` statement [#10374](https://github.com/pingcap/tidb/pull/10374)
diff --git a/releases/release-2.1.14.md b/releases/release-2.1.14.md
index 42dc069d15fbd..77cd5d851ea5e 100644
--- a/releases/release-2.1.14.md
+++ b/releases/release-2.1.14.md
@@ -43,7 +43,7 @@ TiDB Binlog
- Reparo
- Add the `safe-mode` configuration item, and support importing duplicated data after this item is enabled [#662](https://github.com/pingcap/tidb-binlog/pull/662)
- Pump
- - Add the `stop-write-at-available-space` configuration item to limit the available binlog space [#659](https://github.com/pingcap/tidb-binlog/pull/659)
+ - Add the `stop-write-at-available-space` configuration item to limit the available binlog space [#659](https://github.com/pingcap/tidb-binlog/pull/659)
- Fix the issue that Garbage Collector does not work sometimes when the number of LevelDB L0 files is 0 [#648](https://github.com/pingcap/tidb-binlog/pull/648)
- Optimize the algorithm of deleting log files to speed up releasing the space [#648](https://github.com/pingcap/tidb-binlog/pull/648)
- Drainer
diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md
index ff75486cd0153..d8dd5b8850e0f 100644
--- a/releases/release-2.1.17.md
+++ b/releases/release-2.1.17.md
@@ -12,7 +12,7 @@ TiDB version: 2.1.17
TiDB Ansible version: 2.1.17
+ New features
- - Add the `WHERE` clause in TiDB’s `SHOW TABLE REGIONS` syntax
+ - Add the `WHERE` clause in TiDB’s `SHOW TABLE REGIONS` syntax
- Add the `config-check` feature in TiKV and PD to check the configuration items
- Add the `remove-tombstone` command in pd-ctl to clear tombstone store records
- Add the `worker-count` and `txn-batch` configuration items in Reparo to control the recovery speed
@@ -33,7 +33,7 @@ TiDB Ansible version: 2.1.17
- Fix the issue that the query result might be incorrect when the number of rows in the outer table is greater than that in a single batch in Index Lookup Join; expand the functional scope of Index Lookup Join; `UnionScan` can be used as a subnode of `IndexJoin` [#11843](https://github.com/pingcap/tidb/pull/11843)
- Add the display of invalid keys (like `invalid encoded key flag 252` ) in the `SHOW STAT_BUCKETS` syntax, for the situation where invalid keys might occur during the statistics feedback process [#12098](https://github.com/pingcap/tidb/pull/12098)
+ SQL Execution Engine
- - Fix some incorrect results (like `select cast(13835058000000000000 as double)`) caused by the number value that is first converted to `UINT` when the `CAST` function is converting the number value type [#11712](https://github.com/pingcap/tidb/pull/11712)
+ - Fix some incorrect results (like `select cast(13835058000000000000 as double)`) caused by the number value that is first converted to `UINT` when the `CAST` function is converting the number value type [#11712](https://github.com/pingcap/tidb/pull/11712)
- Fix the issue that the calculation result might be incorrect when the dividend of the `DIV` calculation is a decimal and this calculation contains a negative number [#11812](https://github.com/pingcap/tidb/pull/11812)
- Add the `ConvertStrToIntStrict` function to fix the MySQL incompatibility issue caused by some strings being converted to the `INT` type when executing the `SELECT`/`EXPLAIN` statement [#11892](https://github.com/pingcap/tidb/pull/11892)
- Fix the issue that the `Explain` result might be incorrect caused by wrong configuration of `stmtCtx` when `EXPLAIN ... FOR CONNECTION` is used [#11978](https://github.com/pingcap/tidb/pull/11978)
@@ -79,7 +79,7 @@ TiDB Ansible version: 2.1.17
## Tools
+ TiDB Binlog
- - Add `worker-count` and `txn-batch` configuration items in Reparo to control the recovery speed [#746](https://github.com/pingcap/tidb-binlog/pull/746)
+ - Add `worker-count` and `txn-batch` configuration items in Reparo to control the recovery speed [#746](https://github.com/pingcap/tidb-binlog/pull/746)
- Optimize the memory usage of Drainer to improve the parallel execution efficiency [#735](https://github.com/pingcap/tidb-binlog/pull/735)
- Fix the bug that Pump cannot quit normally in some cases [#739](https://github.com/pingcap/tidb-binlog/pull/739)
- Optimize the processing logic of `LevelDB` in Pump to improve the execution efficiency of GC [#720](https://github.com/pingcap/tidb-binlog/pull/720)
diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md
index e5b26e8a4f639..4006ebc2341f7 100644
--- a/releases/release-2.1.18.md
+++ b/releases/release-2.1.18.md
@@ -17,7 +17,7 @@ TiDB Ansible version: 2.1.18
- Fix the issue that invalid query ranges might appear when split by feedback [#12172](https://github.com/pingcap/tidb/pull/12172)
- Fix the issue that the privilege check is incorrect in point get plan [#12341](https://github.com/pingcap/tidb/pull/12341)
- Optimize execution performance of the `select ... limit ... offset …` statement by pushing the Limit operator down to the `IndexLookUpReader` execution logic [#12380](https://github.com/pingcap/tidb/pull/12380)
- - Support using parameters in `ORDER BY`, `GROUP BY` and `LIMIT OFFSET` [#12514](https://github.com/pingcap/tidb/pull/12514)
+ - Support using parameters in `ORDER BY`, `GROUP BY` and `LIMIT OFFSET` [#12514](https://github.com/pingcap/tidb/pull/12514)
- Fix the issue that `IndexJoin` on the partition table returns incorrect results [#12713](https://github.com/pingcap/tidb/pull/12713)
- Fix the issue that the `str_to_date` function in TiDB returns a different result from MySQL when the date string and the format string do not match [#12757](https://github.com/pingcap/tidb/pull/12757)
- Fix the issue that outer join is incorrectly converted to inner join when the `cast` function is included in the query conditions [#12791](https://github.com/pingcap/tidb/pull/12791)
@@ -37,8 +37,8 @@ TiDB Ansible version: 2.1.18
- Adjust the number of times that TiDB caches schema changes and corresponding changed table information from 100 to 1024, and support modification by using the `tidb_max_delta_schema_count` system variable [#12515](https://github.com/pingcap/tidb/pull/12515)
- Change the query start time from the point of "starting to execute" to “starting to compile” to make SQL statistics more accurate [#12638](https://github.com/pingcap/tidb/pull/12638)
- Add the record of `set session autocommit` in TiDB logs [#12568](https://github.com/pingcap/tidb/pull/12568)
- - Record SQL query start time in `SessionVars` to prevent it from being reset during plan execution [#12676](https://github.com/pingcap/tidb/pull/12676)
- - Support `?` placeholder in `ORDER BY`, `GROUP BY` and `LIMIT OFFSET` [#12514](https://github.com/pingcap/tidb/pull/12514)
+ - Record SQL query start time in `SessionVars` to prevent it from being reset during plan execution [#12676](https://github.com/pingcap/tidb/pull/12676)
+ - Support `?` placeholder in `ORDER BY`, `GROUP BY` and `LIMIT OFFSET` [#12514](https://github.com/pingcap/tidb/pull/12514)
- Add the `Prev_stmt` field in slow query logs to output the previous statement when the last statement is `COMMIT` [#12724](https://github.com/pingcap/tidb/pull/12724)
- Record the last statement before `COMMIT` into the log when the `COMMIT` fails in an explicitly committed transaction [#12747](https://github.com/pingcap/tidb/pull/12747)
- Optimize the saving method of the previous statement when the TiDB server executes a SQL statement to improve performance [#12751](https://github.com/pingcap/tidb/pull/12751)
diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md
index f1063c5e6410b..e1858c4d2bedf 100644
--- a/releases/release-2.1.19.md
+++ b/releases/release-2.1.19.md
@@ -60,7 +60,7 @@ TiDB Ansible version: 2.1.19
+ DDL
- Use the table’s `COLLATE` instead of the system’s default charset in the column when a table is created and the table contains `COLLATE` [#13190](https://github.com/pingcap/tidb/pull/13190)
- Limit the length of the index name when creating a table [#13311](https://github.com/pingcap/tidb/pull/13311)
- - Fix the issue that the length of the table name is not checked when renaming a table [#13345](https://github.com/pingcap/tidb/pull/13345)
+ - Fix the issue that the length of the table name is not checked when renaming a table [#13345](https://github.com/pingcap/tidb/pull/13345)
- Check the width range of the `BIT` column [#13511](https://github.com/pingcap/tidb/pull/13511)
- Make the error information output from `change/modify column` more understandable [#13798](https://github.com/pingcap/tidb/pull/13798)
- Fix the issue that when executing the `drop column` operation that has not yet been handled by the downstream Drainer, the downstream might receive DML operations without the affected column [#13974](https://github.com/pingcap/tidb/pull/13974)
diff --git a/releases/release-2.1.5.md b/releases/release-2.1.5.md
index cff7b4ec7fb89..df051fb25b197 100644
--- a/releases/release-2.1.5.md
+++ b/releases/release-2.1.5.md
@@ -19,7 +19,7 @@ On February 28, 2019, TiDB 2.1.5 is released. The corresponding TiDB Ansible 2.1
- Optimize the index selection of TiDB using skyline pruning to improve the stability of simple queries [#9356](https://github.com/pingcap/tidb/pull/9356)
- Support computing the selectivity of the `DNF` expression [#9405](https://github.com/pingcap/tidb/pull/9405)
- Fix the wrong SQL query result of `!=ANY()` and `=ALL()` in some cases [#9403](https://github.com/pingcap/tidb/pull/9403)
- - Fix the panic or the wrong result when the Join Key types of two tables on which the `Merge Join` operation is performed are different [#9438](https://github.com/pingcap/tidb/pull/9438)
+ - Fix the panic or the wrong result when the Join Key types of two tables on which the `Merge Join` operation is performed are different [#9438](https://github.com/pingcap/tidb/pull/9438)
- Fix the issue that the result of the `RAND()` function is not compatible with MySQL [#9446](https://github.com/pingcap/tidb/pull/9446)
- Refactor the logic of `Semi Join` processing `NULL` and the empty result set to get the correct result and improve the compatibility with MySQL [#9449](https://github.com/pingcap/tidb/pull/9449)
+ Server
diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md
index cc210001af32b..54edd52772eed 100644
--- a/releases/release-3.0-ga.md
+++ b/releases/release-3.0-ga.md
@@ -83,11 +83,11 @@ On June 28, 2019, TiDB 3.0 GA is released. The corresponding TiDB Ansible versio
- Optimize transaction processing logics to adapt to more scenarios:
- Change the default value `tidb_disable_txn_auto_retry` to `on`, which means non-auto committed transactions will not be retried
- Add the `tidb_batch_commit` system variable to split a transaction into multiple ones to be executed concurrently
- - Add the `tidb_low_resolution_tso` system variable to control the number of TSOs to obtain in batches and reduce the number of times that transactions request for TSOs, to improve performance in scenarios with relatively low requirement of consistency
+ - Add the `tidb_low_resolution_tso` system variable to control the number of TSOs to obtain in batches and reduce the number of times that transactions request for TSOs, to improve performance in scenarios with relatively low requirement of consistency
- Add the `tidb_skip_isolation_level_check` variable to control whether to report errors when the isolation level is set to SERIALIZABLE
- Modify the `tidb_disable_txn_auto_retry` system variable to make it work on all retryable errors
+ Permission Management
- - Perform permission check on the `ANALYZE`, `USE`, `SET GLOBAL`, and `SHOW PROCESSLIST` statements
+ - Perform permission check on the `ANALYZE`, `USE`, `SET GLOBAL`, and `SHOW PROCESSLIST` statements
- Support Role Based Access Control (RBAC) (**Experimental**)
+ Server
- Optimize slow query logs:
@@ -143,7 +143,7 @@ On June 28, 2019, TiDB 3.0 GA is released. The corresponding TiDB Ansible versio
+ Others
- Upgrade etcd to solve the issues of inconsistent log output formats, Leader selection failure in prevote, and lease deadlocking
- Develop a unified log format specification with restructured log system to facilitate collection and analysis by tools
- - Add monitoring metrics including scheduling parameters, cluster label information, time consumed by PD to process TSO requests, Store ID and address information, etc.
+ - Add monitoring metrics including scheduling parameters, cluster label information, and time consumed by PD to process TSO requests, Store ID, and address information.
## TiKV
diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md
index fb0f23e4ee7a6..281a5e982d7f5 100644
--- a/releases/release-3.0.0-rc.1.md
+++ b/releases/release-3.0.0-rc.1.md
@@ -44,7 +44,7 @@ On May 10, 2019, TiDB 3.0.0-rc.1 is released. The corresponding TiDB Ansible ver
- Support `GRANT ROLE` [#9721](https://github.com/pingcap/tidb/pull/9721)
- Fix the `ConnectionEvent` error from the `whitelist` plugin that makes TiDB exit [#9889](https://github.com/pingcap/tidb/pull/9889)
- Fix the issue of mistakenly adding read-only statements to the transaction history [#9723](https://github.com/pingcap/tidb/pull/9723)
- - Improve `kill` statements to stop SQL execution and release resources more quickly [#9844](https://github.com/pingcap/tidb/pull/9844)
+ - Improve `kill` statements to stop SQL execution and release resources more quickly [#9844](https://github.com/pingcap/tidb/pull/9844)
- Add a startup option `config-check` to check the validity of the configuration file [#9855](https://github.com/pingcap/tidb/pull/9855)
- Fix the validity check of inserting NULL fields when the strict SQL mode is disabled [#10161](https://github.com/pingcap/tidb/pull/10161)
@@ -86,7 +86,7 @@ On May 10, 2019, TiDB 3.0.0-rc.1 is released. The corresponding TiDB Ansible ver
- Support `block cache` sharing among different `column families` [#4612](https://github.com/tikv/tikv/pull/4612)
+ Server
- - Reduce context switch overhead of `batch commands` [#4473](https://github.com/tikv/tikv/pull/4473)
+ - Reduce context switch overhead of `batch commands` [#4473](https://github.com/tikv/tikv/pull/4473)
- Check the validity of seek iterator status [#4470](https://github.com/tikv/tikv/pull/4470)
+ RaftStore
diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md
index b77dc3a8caa5f..d8aa5737cebc4 100644
--- a/releases/release-3.0.0-rc.2.md
+++ b/releases/release-3.0.0-rc.2.md
@@ -50,7 +50,7 @@ On May 28, 2019, TiDB 3.0.0-rc.2 is released. The corresponding TiDB Ansible ver
- Support `preSplit` of table partition, which pre-allocates table Regions when creating a table to avoid write hotspots after the table is created [#10221](https://github.com/pingcap/tidb/pull/10221)
- Fix the issue that TiDB incorrectly updates the version information in PD in some cases [#10324](https://github.com/pingcap/tidb/pull/10324)
- Support modifying the charset and collation using the `ALTER DATABASE` statement [#10393](https://github.com/pingcap/tidb/pull/10393)
- - Support splitting Regions based on the index and range of the specified table to relieve hotspot issues [#10203](https://github.com/pingcap/tidb/pull/10203)
+ - Support splitting Regions based on the index and range of the specified table to relieve hotspot issues [#10203](https://github.com/pingcap/tidb/pull/10203)
- Prohibit modifying the precision of the decimal column using the `alter table` statement [#10433](https://github.com/pingcap/tidb/pull/10433)
- Fix the restriction for expressions and functions in hash partition [#10273](https://github.com/pingcap/tidb/pull/10273)
- Fix the issue that adding indexes in a table that contains partitions will in some cases cause TiDB panic [#10475](https://github.com/pingcap/tidb/pull/10475)
diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md
index dff4e6f45976d..790b6f4895859 100644
--- a/releases/release-3.0.1.md
+++ b/releases/release-3.0.1.md
@@ -76,7 +76,7 @@ TiDB Ansible version: 3.0.1
TiDB Binlog
-- Optimize the Pump GC strategy and remove the restriction that the unconsumed binlog cannot be cleaned to make sure that the resources are not occupied for a long time [#646](https://github.com/pingcap/tidb-binlog/pull/646)
+- Optimize the Pump GC strategy and remove the restriction that the unconsumed binlog cannot be cleaned to make sure that the resources are not occupied for a long time [#646](https://github.com/pingcap/tidb-binlog/pull/646)
TiDB Lightning
diff --git a/releases/release-3.0.11.md b/releases/release-3.0.11.md
index 6cf5ba941d5c0..cbe6a80803e34 100644
--- a/releases/release-3.0.11.md
+++ b/releases/release-3.0.11.md
@@ -40,7 +40,7 @@ TiDB Ansible version: 3.0.11
+ Fix the issue of Goroutine leaks when retrying an optimistic transaction because queries using `Union` are not marked read-only [#15076](https://github.com/pingcap/tidb/pull/15076)
+ Fix the issue that `SHOW TABLE STATUS` fails to correctly output the table status at the snapshot time because the value of the `tidb_snapshot` parameter is not correctly used when executing the `SET SESSION tidb_snapshot = 'xxx';` statement [#14391](https://github.com/pingcap/tidb/pull/14391)
+ Fix the incorrect result caused by a SQL statement that contains `Sort Merge Join` and `ORDER BY DESC` at the same time [#14664](https://github.com/pingcap/tidb/pull/14664)
- + Fix the panic of TiDB server when creating partition tables using the unsupported expression. The error information `This partition function is not allowed` is returned after fixing this panic. [#14769](https://github.com/pingcap/tidb/pull/14769)
+ + Fix the panic of TiDB server when creating partition tables using the unsupported expression. The error information `This partition function is not allowed` is returned after fixing this panic. [#14769](https://github.com/pingcap/tidb/pull/14769)
+ Fix the incorrect result occurred when executing the `select max() from subquery` statement with the subquery containing `Union` [#14944](https://github.com/pingcap/tidb/pull/14944)
+ Fix the issue that an error message is returned when executing the `SHOW BINDINGS` statement after executing `DROP BINDING` that drops the execution binding [#14865](https://github.com/pingcap/tidb/pull/14865)
+ Fix the issue that the connection is broken because the maximum length of an alias in a query is 256 characters in the MySQL protocol, but TiDB does not [cut the alias](https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html) in the query results according to this protocol [#14940](https://github.com/pingcap/tidb/pull/14940)
diff --git a/releases/release-3.0.15.md b/releases/release-3.0.15.md
index f82b48ddde541..87501606431cf 100644
--- a/releases/release-3.0.15.md
+++ b/releases/release-3.0.15.md
@@ -14,7 +14,7 @@ TiDB version: 3.0.15
+ TiDB
- Forbid the query in partitioned tables to use the plan cache feature [#16759](https://github.com/pingcap/tidb/pull/16759)
- - Support the `admin recover index` and `admin check index` statements on partitioned tables [#17315](https://github.com/pingcap/tidb/pull/17315) [#17390](https://github.com/pingcap/tidb/pull/17390)
+ - Support the `admin recover index` and `admin check index` statements on partitioned tables [#17315](https://github.com/pingcap/tidb/pull/17315) [#17390](https://github.com/pingcap/tidb/pull/17390)
- Support partition pruning of the `in` condition for Range partitioned tables [#17318](https://github.com/pingcap/tidb/pull/17318)
- Optimize the output of `SHOW CREATE TABLE`, and add quotation marks to the partition name [#16315](https://github.com/pingcap/tidb/pull/16315)
- Support the `ORDER BY` clause in the `GROUP_CONCAT` function [#16988](https://github.com/pingcap/tidb/pull/16988)
diff --git a/releases/release-3.0.16.md b/releases/release-3.0.16.md
index 1d479ffd6d671..0f5586e6fffe3 100644
--- a/releases/release-3.0.16.md
+++ b/releases/release-3.0.16.md
@@ -48,7 +48,7 @@ TiDB version: 3.0.16
+ TiKV
- Fix the potential wrong result read from ingested files [#8039](https://github.com/tikv/tikv/pull/8039)
- - Fix the issue that a peer can not be removed when its store is isolated during multiple merge processes [#8005](https://github.com/tikv/tikv/pull/8005)
+ - Fix the issue that a peer cannot be removed when its store is isolated during multiple merge processes [#8005](https://github.com/tikv/tikv/pull/8005)
+ PD
diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md
index 3613e2d91e571..17ffa6685150a 100644
--- a/releases/release-3.0.2.md
+++ b/releases/release-3.0.2.md
@@ -27,7 +27,7 @@ TiDB Ansible version: 3.0.2
- Support updating the Top-N statistics based on the feedback information [#11507](https://github.com/pingcap/tidb/pull/11507)
+ SQL Execution Engine
- Fix the issue that the returned value is not `NULL` when the `INSERT` function contains `NULL` in parameters [#11248](https://github.com/pingcap/tidb/pull/11248)
- - Fix the issue that the computing result might be wrong when the partitioned table is checked by the `ADMIN CHECKSUM` operation [#11266](https://github.com/pingcap/tidb/pull/11266)
+ - Fix the issue that the computing result might be wrong when the partitioned table is checked by the `ADMIN CHECKSUM` operation [#11266](https://github.com/pingcap/tidb/pull/11266)
- Fix the issue that the result might be wrong when INDEX JOIN uses the prefix index [#11246](https://github.com/pingcap/tidb/pull/11246)
- Fix the issue that result might be wrong caused by incorrectly aligning fractions when the `DATE_ADD` function does subtraction on date numbers involving microseconds [#11288](https://github.com/pingcap/tidb/pull/11288)
- Fix the wrong result caused by the `DATE_ADD` function incorrectly processing the negative numbers in `INTERVAL` [#11325](https://github.com/pingcap/tidb/pull/11325)
diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md
index 2c0298d52c18b..0837d4a7eaa80 100644
--- a/releases/release-3.0.4.md
+++ b/releases/release-3.0.4.md
@@ -75,7 +75,7 @@ TiDB Ansible version: 3.0.4
- Add the `Backoff` field in the slow query logs to record the Backoff information in the commit phase of 2PC [#12335](https://github.com/pingcap/tidb/pull/12335)
- Fix the issue that the slow query logs are incorrect when getting the result of `PREPARE` + `EXECUTE` by using the cursor (for example, `PREPARE stmt1FROM SELECT * FROM t WHERE a > ?; EXECUTE stmt1 USING @variable`) [#12392](https://github.com/pingcap/tidb/pull/12392)
- Support `tidb_enable_stmt_summary`. When this feature is enabled, TiDB counts the SQL statements and the result can be queried by using the system table `performance_schema.events_statements_summary_by_digest` [#12308](https://github.com/pingcap/tidb/pull/12308)
- - Adjust the level of some logs in tikv-client (for example, change the log level of `batchRecvLoop fails` from `ERROR` to `INFO`) [#12383](https://github.com/pingcap/tidb/pull/12383)
+ - Adjust the level of some logs in tikv-client (for example, change the log level of `batchRecvLoop fails` from `ERROR` to `INFO`) [#12383](https://github.com/pingcap/tidb/pull/12383)
- DDL
- Add the `tidb_allow_remove_auto_inc` variable. Dropping the `AUTO INCREMENT` attribute of the column is disabled by default [#12145](https://github.com/pingcap/tidb/pull/12145)
- Fix the issue that the uncommented TiDB-specific syntax `PRE_SPLIT_REGIONS` might cause errors in the downstream database during data replication [#12120](https://github.com/pingcap/tidb/pull/12120)
diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md
index 3c5db5c74356c..f38ce5cddfda8 100644
--- a/releases/release-3.0.6.md
+++ b/releases/release-3.0.6.md
@@ -92,7 +92,7 @@ TiDB Ansible version: 3.0.6
+ TiDB Binlog
- Obtain the initial replication timestamp from PD when `initial-commit-ts` is set to “-1” in Drainer [#788](https://github.com/pingcap/tidb-binlog/pull/788)
- - Decouple Drainer’s `Checkpoint` storage from the downstream and support saving `Checkpoint` in MySQL or local files [#790](https://github.com/pingcap/tidb-binlog/pull/790)
+ - Decouple Drainer’s `Checkpoint` storage from the downstream and support saving `Checkpoint` in MySQL or local files [#790](https://github.com/pingcap/tidb-binlog/pull/790)
- Fix the Drainer panic issue caused by using empty values when configuring replication database/table filtering [#801](https://github.com/pingcap/tidb-binlog/pull/801)
- Fix the issue that processes get into the deadlock status instead of exiting after a panic occurs because Drainer fails to apply binlog files to the downstream [#807](https://github.com/pingcap/tidb-binlog/pull/807)
- Fix the issue that Pump blocks when it exits because of gRPC’s `GracefulStop` [#817](https://github.com/pingcap/tidb-binlog/pull/817)
diff --git a/releases/release-3.0.9.md b/releases/release-3.0.9.md
index b7ddfea912e0d..4ce2fafe0e7a0 100644
--- a/releases/release-3.0.9.md
+++ b/releases/release-3.0.9.md
@@ -28,7 +28,7 @@ TiDB Ansible version: 3.0.9
- Add the `plan_digest` field in the slow query table to record the `plan` signature [#14292](https://github.com/pingcap/tidb/pull/14292)
+ DDL
- Fix the issue that the results of anonymous indexes created using `alter table ... add index` on the `primary` column is inconsistent with MySQL [#14310](https://github.com/pingcap/tidb/pull/14310)
- - Fix the issue that `VIEW`s are mistakenly dropped by the `drop table` syntax [#14052](https://github.com/pingcap/tidb/pull/14052)
+ - Fix the issue that `VIEW`s are mistakenly dropped by the `drop table` syntax [#14052](https://github.com/pingcap/tidb/pull/14052)
+ Planner
- Optimize the performance of statements such as `select max(a), min(a) from t`. If an index exists in the `a` column, the statement is optimized to `select * from (select a from t order by a desc limit 1) as t1, (select a from t order by a limit 1) as t2` to avoid full table scan [#14410](https://github.com/pingcap/tidb/pull/14410)
@@ -37,7 +37,7 @@ TiDB Ansible version: 3.0.9
+ Raftstore
- Speed up the configuration change to speed up the Region scattering [#6421](https://github.com/tikv/tikv/pull/6421)
+ Transaction
- - Add the `tikv_lock_manager_waiter_lifetime_duration`, `tikv_lock_manager_detect_duration`, and `tikv_lock_manager_detect_duration` monitoring metrics to monitor `waiter`s’ lifetime, the time cost of detecting deadlocks, and the status of `Wait` table [#6392](https://github.com/tikv/tikv/pull/6392)
+ - Add the `tikv_lock_manager_waiter_lifetime_duration`, `tikv_lock_manager_detect_duration`, and `tikv_lock_manager_detect_duration` monitoring metrics to monitor `waiter`s’ lifetime, the time cost of detecting deadlocks, and the status of `Wait` table [#6392](https://github.com/tikv/tikv/pull/6392)
- Optimize the following configuration items to reduce transaction execution latency caused by changing Region leader or the leader of deadlock detector in extreme situations [#6429](https://github.com/tikv/tikv/pull/6429)
- Change the default value of `wait-for-lock-time` from `3s` to `1s`
- Change the default value of `wake-up-delay-duration` from `100ms` to `20ms`
diff --git a/releases/release-3.1.0-rc.md b/releases/release-3.1.0-rc.md
index f4d9e78870390..8ec5073bf458f 100644
--- a/releases/release-3.1.0-rc.md
+++ b/releases/release-3.1.0-rc.md
@@ -73,7 +73,7 @@ TiDB Ansible version: 3.1.0-rc
- Fix the information schema error caused by frequently updating the TiFlash replica [#14884](https://github.com/pingcap/tidb/pull/14884)
- Fix the issue that `last_insert_id` is incorrectly generated when applying `AUTO_RANDOM` [#15149](https://github.com/pingcap/tidb/pull/15149)
- Fix the issue that updating the status of TiFlash replica might cause the DDL operation to get stuck [#15161](https://github.com/pingcap/tidb/pull/15161)
- - Forbid `Aggregation` pushdown and `TopN` pushdown when there are predicates that can not be pushed down [#15141](https://github.com/pingcap/tidb/pull/15141)
+ - Forbid `Aggregation` pushdown and `TopN` pushdown when there are predicates that cannot be pushed down [#15141](https://github.com/pingcap/tidb/pull/15141)
- Forbid the nested `view` creation [#15440](https://github.com/pingcap/tidb/pull/15440)
- Fix the error occurred when executing `SELECT CURRENT_ROLE()` after `SET ROLE ALL` [#15570](https://github.com/pingcap/tidb/pull/15570)
- Fix the failure to identify the `view` name when executing the `select view_name.col_name from view_name` statement [#15573](https://github.com/pingcap/tidb/pull/15573)
diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md
index 502c6e28321c4..db2f4b6f073e0 100644
--- a/releases/release-4.0-ga.md
+++ b/releases/release-4.0-ga.md
@@ -85,7 +85,7 @@ TiDB version: 4.0.0
* TiFlash
- - Fix the issue that the matching behavior of regular expressions in the search log feature is inconsistent with other components
+ - Fix the issue that the matching behavior of regular expressions in the search log feature is inconsistent with other components
- Fix the issue of excessive restart time when nodes write large amounts of data by disabling the delay processing optimization of `Raft Compact Log Command` by default
- Fix the issue that the system fails to start because TiDB incorrectly processes the `DROP DATABASE` statement in some scenarios
- Fix the issue that the method of collecting CPU information in `Server_info` is different from that in other components
diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md
index 2ce4c61d47120..faa45cc7ec4bc 100644
--- a/releases/release-4.0.0-beta.md
+++ b/releases/release-4.0.0-beta.md
@@ -93,7 +93,7 @@ TiDB Ansible version: 4.0.0-beta
+ Support optimizing hotspot scheduling according to the load information of storage nodes
- [#1870](https://github.com/pingcap/pd/pull/1870) [#1982](https://github.com/pingcap/pd/pull/1982) [#1998](https://github.com/pingcap/pd/pull/1998) [#1843](https://github.com/pingcap/pd/pull/1843) [#1750](https://github.com/pingcap/pd/pull/1750)
-+ Add the Placement Rules feature that supports controlling the number of replicas of any data range, the storage location, the storage host type and roles by combining different scheduling rules
++ Add the Placement Rules feature that supports controlling the number of replicas of any data range, the storage location, the storage host type and roles by combining different scheduling rules
- [#2051](https://github.com/pingcap/pd/pull/2051) [#1999](https://github.com/pingcap/pd/pull/1999) [#2042](https://github.com/pingcap/pd/pull/2042) [#1917](https://github.com/pingcap/pd/pull/1917) [#1904](https://github.com/pingcap/pd/pull/1904)
- [#1897](https://github.com/pingcap/pd/pull/1897) [#1894](https://github.com/pingcap/pd/pull/1894) [#1865](https://github.com/pingcap/pd/pull/1865) [#1855](https://github.com/pingcap/pd/pull/1855) [#1834](https://github.com/pingcap/pd/pull/1834)
+ Support using plugins (experimental) [#1799](https://github.com/pingcap/pd/pull/1799)
diff --git a/releases/release-4.0.0-rc.2.md b/releases/release-4.0.0-rc.2.md
index 1a1d59ee04d5e..7daa263e87642 100644
--- a/releases/release-4.0.0-rc.2.md
+++ b/releases/release-4.0.0-rc.2.md
@@ -131,7 +131,7 @@ TiDB version: 4.0.0-rc.2
- Fix the wrong information of the `WAIT_TIME` field in the expensive log [#16907](https://github.com/pingcap/tidb/pull/16907)
- Fix the issue that the `SELECT FOR UPDATE` statement cannot be recorded in the slow log in the pessimistic transaction mode [#16897](https://github.com/pingcap/tidb/pull/16897)
- Fix the wrong result that occurs when executing `SELECT DISTINCT` on a column of the `Enum` or `Set` type [#16892](https://github.com/pingcap/tidb/pull/16892)
- - Fix the display error of `auto_random_base` in the `SHOW CREATE TABLE` statement [#16864](https://github.com/pingcap/tidb/pull/16864)
+ - Fix the display error of `auto_random_base` in the `SHOW CREATE TABLE` statement [#16864](https://github.com/pingcap/tidb/pull/16864)
- Fix the incorrect value of `string_value` in the `WHERE` clause [#16559](https://github.com/pingcap/tidb/pull/16559)
- Fix the issue that the error message of the `GROUP BY` window function is inconsistent with that of MySQL [#16165](https://github.com/pingcap/tidb/pull/16165)
- Fix the issue that the `FLASH TABLE` statement fails to execute when the database name contains the uppercase letter [#17167](https://github.com/pingcap/tidb/pull/17167)
diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md
index 4658b8138c5be..fff905897f804 100644
--- a/releases/release-4.0.5.md
+++ b/releases/release-4.0.5.md
@@ -150,7 +150,7 @@ TiDB version: 4.0.5
+ TiFlash
- Fix the issue that TiFlash cannot start normally after upgrading from an earlier version if the name of the database or table contains special characters
- - Fix the issue that the TiFlash process can not exit if any exceptions are thrown during initialization
+ - Fix the issue that the TiFlash process cannot exit if any exceptions are thrown during initialization
+ Tools
diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md
index 5b10551fe9702..03c185b560291 100644
--- a/releases/release-5.0.6.md
+++ b/releases/release-5.0.6.md
@@ -70,7 +70,7 @@ TiDB version: 5.0.6
- Fix wrong results of the `microsecond` function in vectorized expressions [#29244](https://github.com/pingcap/tidb/issues/29244)
- Fix the issue of incomplete log information from the `auto analyze` result [#29188](https://github.com/pingcap/tidb/issues/29188)
- Fix wrong results of the `hour` function in vectorized expression [#28643](https://github.com/pingcap/tidb/issues/28643)
- - Fix the unexpected error like `tidb_cast to Int32 is not supported` when the unsupported `cast` is pushed down to TiFlash [#23907](https://github.com/pingcap/tidb/issues/23907)
+ - Fix the unexpected error like `tidb_cast to Int32 is not supported` when the unsupported `cast` is pushed down to TiFlash [#23907](https://github.com/pingcap/tidb/issues/23907)
- Fix a bug that the availability detection of MPP node does not work in some corner cases [#3118](https://github.com/pingcap/tics/issues/3118)
- Fix the `DATA RACE` issue when assigning `MPP task ID` [#27952](https://github.com/pingcap/tidb/issues/27952)
- Fix the `INDEX OUT OF RANGE` error for a MPP query after deleting an empty `dual table` [#28250](https://github.com/pingcap/tidb/issues/28250)
diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md
index b4be4c2203183..ac386cac21f75 100644
--- a/releases/release-5.1.0.md
+++ b/releases/release-5.1.0.md
@@ -153,7 +153,7 @@ In v5.1, the key new features or improvements are as follows:
- Improve TiCDC memory usage to avoid OOM in the following scenarios
- If large amounts of data is accumulated during the replication interruption, exceeding 1TB, the re-replication causes OOM problems.
- Large amounts of data writes cause OOM problems in TiCDC.
- - Reduce the possibility of TiCDC replication interruption in the following scenarios:
+ - Reduce the possibility of TiCDC replication interruption in the following scenarios:
[project#11](https://github.com/pingcap/tiflow/projects/11)
@@ -174,7 +174,7 @@ In v5.1, the key new features or improvements are as follows:
### Telemetry
-TiDB adds the running status of TiDB cluster requests in telemetry, including execution status, failure status, etc.
+TiDB adds the running status of TiDB cluster requests in telemetry, including execution status and failure status.
To learn more about the information and how to disable this behavior, refer to [Telemetry](/telemetry.md).
diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md
index f5501920a6246..1794ec951e1c4 100644
--- a/releases/release-5.1.1.md
+++ b/releases/release-5.1.1.md
@@ -107,7 +107,7 @@ TiDB version: 5.1.1
- Fix the issue that the duration calculation might panic on certain platforms [#10569](https://github.com/tikv/tikv/pull/10569)
- Fix the issue that Load Base Split mistakenly uses the unencoded keys of `batch_get_command` [#10542](https://github.com/tikv/tikv/issues/10542)
- - Fix the issue that changing the `resolved-ts.advance-ts-interval` configuration online cannot take effect immediately [#10426](https://github.com/tikv/tikv/issues/10426)
+ - Fix the issue that changing the `resolved-ts.advance-ts-interval` configuration dynamically cannot take effect immediately [#10426](https://github.com/tikv/tikv/issues/10426)
- Fix the issue of follower metadata corruption in rare cases with more than 4 replicas [#10225](https://github.com/tikv/tikv/issues/10225)
- Fix the panic issue that occurs when building a snapshot twice if encryption is enabled [#9786](https://github.com/tikv/tikv/issues/9786) [#10407](https://github.com/tikv/tikv/issues/10407)
- Fix the wrong `tikv_raftstore_hibernated_peer_state` metric [#10330](https://github.com/tikv/tikv/issues/10330)
diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md
index 69615013e2cb4..47d5fe449246a 100644
--- a/releases/release-5.2.2.md
+++ b/releases/release-5.2.2.md
@@ -55,7 +55,7 @@ TiDB version: 5.2.2
- Fix the issue that auto analyze might be triggered out of the specified time when a new index is added [#28698](https://github.com/pingcap/tidb/issues/28698)
- Fix a bug that setting any session variable invalidates `tidb_snapshot` [#28683](https://github.com/pingcap/tidb/pull/28683)
- Fix a bug that BR is not working for clusters with many missing-peer regions [#27534](https://github.com/pingcap/tidb/issues/27534)
- - Fix the unexpected error like `tidb_cast to Int32 is not supported` when the unsupported `cast` is pushed down to TiFlash [#23907](https://github.com/pingcap/tidb/issues/23907)
+ - Fix the unexpected error like `tidb_cast to Int32 is not supported` when the unsupported `cast` is pushed down to TiFlash [#23907](https://github.com/pingcap/tidb/issues/23907)
- Fix the issue that `DECIMAL overflow` is missing in the `%s value is out of range in '%s'`error message [#27964](https://github.com/pingcap/tidb/issues/27964)
- Fix a bug that the availability detection of MPP node does not work in some corner cases [#3118](https://github.com/pingcap/tics/issues/3118)
- Fix the `DATA RACE` issue when assigning `MPP task ID` [#27952](https://github.com/pingcap/tidb/issues/27952)
@@ -115,4 +115,4 @@ TiDB version: 5.2.2
+ TiDB Binlog
- - Fix the issue that when most tables are filtered out, checkpoint can not be updated under some special load [#1075](https://github.com/pingcap/tidb-binlog/pull/1075)
+ - Fix the issue that when most tables are filtered out, checkpoint cannot be updated under some special load [#1075](https://github.com/pingcap/tidb-binlog/pull/1075)
diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md
index d8d77147bf68f..3221d0681aa4b 100644
--- a/releases/release-5.3.0.md
+++ b/releases/release-5.3.0.md
@@ -330,7 +330,7 @@ Starting from TiCDC v5.3.0, the cyclic replication feature between TiDB clusters
- Fix the issue that auto analyze might be triggered out of the specified time when a new index is added [#28698](https://github.com/pingcap/tidb/issues/28698)
- Fix a bug that setting any session variable invalidates `tidb_snapshot` [#28683](https://github.com/pingcap/tidb/pull/28683)
- Fix a bug that BR is not working for clusters with many missing-peer Regions [#27534](https://github.com/pingcap/tidb/issues/27534)
- - Fix the unexpected error like `tidb_cast to Int32 is not supported` when the unsupported `cast` is pushed down to TiFlash [#23907](https://github.com/pingcap/tidb/issues/23907)
+ - Fix the unexpected error like `tidb_cast to Int32 is not supported` when the unsupported `cast` is pushed down to TiFlash [#23907](https://github.com/pingcap/tidb/issues/23907)
- Fix the issue that `DECIMAL overflow` is missing in the `%s value is out of range in '%s'`error message [#27964](https://github.com/pingcap/tidb/issues/27964)
- Fix a bug that the availability detection of MPP node does not work in some corner cases [#3118](https://github.com/pingcap/tics/issues/3118)
- Fix the `DATA RACE` issue when assigning `MPP task ID` [#27952](https://github.com/pingcap/tidb/issues/27952)
@@ -407,4 +407,4 @@ Starting from TiCDC v5.3.0, the cyclic replication feature between TiDB clusters
+ TiDB Binlog
- - Fix the issue that when most tables are filtered out, checkpoint can not be updated under some special load [#1075](https://github.com/pingcap/tidb-binlog/pull/1075)
+ - Fix the issue that when most tables are filtered out, checkpoint cannot be updated under some special load [#1075](https://github.com/pingcap/tidb-binlog/pull/1075)
diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md
index 524a6bff3543c..98c5747ba6664 100644
--- a/releases/release-5.4.0.md
+++ b/releases/release-5.4.0.md
@@ -57,7 +57,7 @@ In v5.4, the key new features or improvements are as follows:
| TiKV | `log-level`, `log-format`, `log-file`, `log-rotation-size` | Modified | The names of TiKV log parameters are replaced with the names that are consistent with TiDB log parameters, which are `log.level`, `log.format`, `log.file.filename`, and `log.enable-timestamp`. If you only set the old parameters, and their values are set to non-default values, the old parameters remain compatible with the new parameters. If both old and new parameters are set, the new parameters take effect. For details, see [TiKV Configuration File - log](/tikv-configuration-file.md#log-new-in-v540). |
| TiKV | `log-rotation-timespan` | Deleted | The timespan between log rotations. After this timespan passes, a log file is rotated, which means a timestamp is appended to the file name of the current log file, and a new log file is created. |
| TiKV | `allow-remove-leader` | Deleted | Determines whether to allow deleting the main switch. |
-| TiKV | `raft-msg-flush-interval` | Deleted | Determines the interval at which Raft messages are sent in batches. The Raft messages are sent in batches at every interval specified by this configuration item. |
+| TiKV | `raft-msg-flush-interval` | Deleted | Determines the interval at which Raft messages are sent in batches. The Raft messages are sent in batches at every interval specified by this configuration item. |
| PD | [`log.level`](/pd-configuration-file.md#level) | Modified | The default value is changed from "INFO" to "info", guaranteed to be case-insensitive. |
| TiFlash | [`profile.default.enable_elastic_threadpool`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | Newly added | Determines whether to enable or disable the elastic thread pool function. Enabling this configuration item can significantly improve TiFlash CPU utilization in high concurrency scenarios. The default value is `false`. |
| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | Newly added | Specifies the version of DTFile. The default value is `2`, under which hashes are embedded in the data file. You can also set the value to `3`. When it is `3`, the data file contains metadata and token data checksum, and supports multiple hash algorithms. |
@@ -226,7 +226,7 @@ In v5.4, the key new features or improvements are as follows:
- **TiDB Lightning introduces the schema name that stores the meta information for parallel import**
- TiDB Lightning introduces the `meta-schema-name` configuration item. In parallel import mode, this parameter specifies the schema name that stores the meta information for each TiDB Lightning instance in the target cluster. By default, the value is "lightning_metadata". The value set for this parameter must be the same for each TiDB Lightning instance that participates in the same parallel import; otherwise, the correctness of the imported data can not be ensured.
+ TiDB Lightning introduces the `meta-schema-name` configuration item. In parallel import mode, this parameter specifies the schema name that stores the meta information for each TiDB Lightning instance in the target cluster. By default, the value is "lightning_metadata". The value set for this parameter must be the same for each TiDB Lightning instance that participates in the same parallel import; otherwise, the correctness of the imported data cannot be ensured.
[User document](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)
diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md
index 14752ec08d1f5..6934d99a98c72 100644
--- a/releases/release-6.0.0-dmr.md
+++ b/releases/release-6.0.0-dmr.md
@@ -402,7 +402,7 @@ TiDB v6.0.0 is a DMR, and its version is 6.0.0-DMR.
- Support dynamically modifying `raftstore.apply_max_batch_size` and `raftstore.store_max_batch_size` [#11982](https://github.com/tikv/tikv/issues/11982)
- RawKV V2 returns the latest version upon receiving the `raw_get` or `raw_scan` request [#11965](https://github.com/tikv/tikv/issues/11965)
- Support the RCCheckTS consistency reads [#12097](https://github.com/tikv/tikv/issues/12097)
- - Support dynamically modifying `storage.scheduler-worker-pool-size`(the thread count of the Scheduler pool) [#12067](https://github.com/tikv/tikv/issues/12067)
+ - Support dynamically modifying `storage.scheduler-worker-pool-size`(the thread count of the Scheduler pool) [#12067](https://github.com/tikv/tikv/issues/12067)
- Control the use of CPU and bandwidth by using the global foreground flow controller to improve the performance stability of TiKV [#11855](https://github.com/tikv/tikv/issues/11855)
- Support dynamically modifying `readpool.unified.max-thread-count` (the thread count of the UnifyReadPool) [#11781](https://github.com/tikv/tikv/issues/11781)
- Use the TiKV internal pipeline to replace the RocksDB pipeline and deprecate the `rocksdb.enable-multibatch-write` parameter [#12059](https://github.com/tikv/tikv/issues/12059)
@@ -453,7 +453,7 @@ TiDB v6.0.0 is a DMR, and its version is 6.0.0-DMR.
+ TiDB
- - Fix a bug that TiDB fails to create tables with placement rules when `SCHEDULE = majority_in_primary`, and `PrimaryRegion` and `Regions` are of the same value [#31271](https://github.com/pingcap/tidb/issues/31271)
+ - Fix a bug that TiDB fails to create tables with placement rules when `SCHEDULE = majority_in_primary`, and `PrimaryRegion` and `Regions` are of the same value [#31271](https://github.com/pingcap/tidb/issues/31271)
- Fix the `invalid transaction` error when executing a query using index lookup join [#30468](https://github.com/pingcap/tidb/issues/30468)
- Fix a bug that `show grants` returns incorrect results when two or more privileges are granted [#30855](https://github.com/pingcap/tidb/issues/30855)
- Fix a bug that `INSERT INTO t1 SET timestamp_col = DEFAULT` would set the timestamp to the zero timestamp for the field defaulted to `CURRENT_TIMESTAMP` [#29926](https://github.com/pingcap/tidb/issues/29926)
diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md
index ea79c065e1889..beefb3b0877ca 100644
--- a/releases/release-6.1.0.md
+++ b/releases/release-6.1.0.md
@@ -136,20 +136,20 @@ In 6.1.0, the key new features or improvements are as follows:
[User document](/sql-statements/sql-statement-show-analyze-status.md)
-* Support modifying TiDB, TiKV, and TiFlash configurations online
+* Support modifying TiDB, TiKV, and TiFlash configurations dynamically
- In earlier TiDB versions, after modifying a configuration item, you must restart the cluster to make the modification effective. This might interrupt online services. To address this issue, TiDB v6.1.0 introduces the online configuration feature, which allows you to validate a parameter change without restarting the cluster. The specific optimizations are as follows:
+ In earlier TiDB versions, after modifying a configuration item, you must restart the cluster to make the modification effective. This might interrupt online services. To address this issue, TiDB v6.1.0 introduces the dynamic configuration feature, which allows you to validate a parameter change without restarting the cluster. The specific optimizations are as follows:
- * Transform some TiDB configuration items to system variables, so that they can be modified online and persisted. Note that the original configuration items are deprecated after transformation. For a detailed list of the transformed configuration items, see [Configuration file parameters](#configuration-file-parameters).
+ * Transform some TiDB configuration items to system variables, so that they can be modified dynamically and persisted. Note that the original configuration items are deprecated after transformation. For a detailed list of the transformed configuration items, see [Configuration file parameters](#configuration-file-parameters).
* Support configuring some TiKV parameters online. For a detailed list of the parameters, see [Others](#others).
- * Transform the TiFlash configuration item `max_threads` to a system variable `tidb_max_tiflash_threads`, so that the configuration can be modified online and persisted. Note that the original configuration item remains after transformation.
+ * Transform the TiFlash configuration item `max_threads` to a system variable `tidb_max_tiflash_threads`, so that the configuration can be modified dynamically and persisted. Note that the original configuration item remains after transformation.
For v6.1.0 clusters upgraded (including online and offline upgrades) from earlier versions, note that:
* If the configuration items specified in the configuration file before the upgrade already exist, TiDB will automatically update the values of the configured items to those of the corresponding system variables during the upgrade process. In this way, after the upgrade, the system behavior is not affected by parameter optimization.
* The automatic update mentioned above occurs only once during the upgrade. After the upgrade, the deprecated configuration items are no longer effective.
- This feature allows you to modify parameters online, and validate and persist them, instead of restarting the system and interrupting services. This makes your daily maintenance easier.
+ This feature allows you to modify parameters dynamically, and validate and persist them, instead of restarting the system and interrupting services. This makes your daily maintenance easier.
[User document](/dynamic-config.md)
@@ -292,7 +292,7 @@ In 6.1.0, the key new features or improvements are as follows:
* Damaged SST files in TiKV might cause the TiKV process to panic. Before TiDB v6.1.0, damaged SST files caused TiKV to panic immediately. Since TiDB v6.1.0, the TiKV process will panic 1 hour after SST files are damaged.
-* The following TiKV configuration items support [modifying values online](/dynamic-config.md#modify-tikv-configuration-online):
+* The following TiKV configuration items support [modifying values dynamically](/dynamic-config.md#modify-tikv-configuration-dynamically):
* `raftstore.raft-entry-max-size`
* `quota.foreground-cpu-time`
diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md
index efc061779641b..49927379a4f16 100644
--- a/releases/release-6.1.1.md
+++ b/releases/release-6.1.1.md
@@ -160,7 +160,7 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v6.1/quick-start-with-
- Fix the TiCDC panic issue when you set `enable-old-value = false` [#6198](https://github.com/pingcap/tiflow/issues/6198) @[hi-rustin](https://github.com/hi-rustin)
- Fix the data consistency issue when the redo log feature is enabled [#6189](https://github.com/pingcap/tiflow/issues/6189) [#6368](https://github.com/pingcap/tiflow/issues/6368) [#6277](https://github.com/pingcap/tiflow/issues/6277) [#6456](https://github.com/pingcap/tiflow/issues/6456) [#6695](https://github.com/pingcap/tiflow/issues/6695) [#6764](https://github.com/pingcap/tiflow/issues/6764) [#6859](https://github.com/pingcap/tiflow/issues/6859) @[asddongmen](https://github.com/asddongmen)
- Fix poor redo log performance by writing redo events asynchronously [#6011](https://github.com/pingcap/tiflow/issues/6011) @[CharlesCheung96](https://github.com/CharlesCheung96)
- - Fix the issue that the MySQL sink can not connect to IPv6 addresses [#6135](https://github.com/pingcap/tiflow/issues/6135) @[hi-rustin](https://github.com/hi-rustin)
+ - Fix the issue that the MySQL sink cannot connect to IPv6 addresses [#6135](https://github.com/pingcap/tiflow/issues/6135) @[hi-rustin](https://github.com/hi-rustin)
+ Backup & Restore (BR)
diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md
index d6bc5d7cd1c5e..68a2836263d41 100644
--- a/releases/release-6.2.0.md
+++ b/releases/release-6.2.0.md
@@ -167,7 +167,7 @@ In v6.2.0-DMR, the key new features and improvements are as follows:
* Support setting savepoints in transactions
- A transaction is a logical collection of a series of consecutive operations with which the database guarantees ACID properties. In some complex application scenarios, you might need to manage many operations in a transaction, and sometimes you might need to roll back some operations in the transaction. “Savepoint” is a nameable mechanism for the internal implementation of transactions. With this mechanism, you can flexibly control the rollback points within a transaction, thereby managing the more complex transactions and having more freedom in designing diverse applications.
+ A transaction is a logical collection of a series of consecutive operations with which the database guarantees ACID properties. In some complex application scenarios, you might need to manage many operations in a transaction, and sometimes you might need to roll back some operations in the transaction. "Savepoint" is a nameable mechanism for the internal implementation of transactions. With this mechanism, you can flexibly control the rollback points within a transaction, thereby managing the more complex transactions and having more freedom in designing diverse applications.
[User document](/sql-statements/sql-statement-savepoint.md) [#6840](https://github.com/pingcap/tidb/issues/6840) @[crazycs520](https://github.com/crazycs520)
@@ -221,10 +221,10 @@ In v6.2.0-DMR, the key new features and improvements are as follows:
[User document](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#import-data-into-a-cluster-in-production) [#35148](https://github.com/pingcap/tidb/issues/35148) @[gozssky](https://github.com/gozssky)
-* Refactor the [user documentation of TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) to make its structure more reasonable and clear. The terms for “backend” is also modified to lower the understanding barrier for new users:
+* Refactor the [user documentation of TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) to make its structure more reasonable and clear. The terms for "backend" is also modified to lower the understanding barrier for new users:
- - Replace “local backend” with “physical import mode”.
- - Replace “tidb backend” with “logical import mode”.
+ - Replace "local backend" with "physical import mode".
+ - Replace "tidb backend" with "logical import mode".
### TiDB data share subscription
@@ -302,7 +302,7 @@ In v6.2.0-DMR, the key new features and improvements are as follows:
- Since TiDB v6.2.0, you can restore table in `mysql` schema by specifying the parameter `--with-sys-table=true` when restoring data.
- When you execute the `ALTER TABLE` statement to add, drop, or modify multiple columns or indexes, TiDB checks table consistency by comparing the table before and after statement execution, regardless of the change in the same DDL statement. The execution order of the DDLs is not fully compatible with MySQL in some scenarios.
- If the TiDB component is v6.2.0 or later, the TiKV component should not be earlier than v6.2.0.
-- TiKV adds a configuration item `split.region-cpu-overload-threshold-ratio` that supports [online configuration](/dynamic-config.md#modify-tikv-configuration-online).
+- TiKV adds a configuration item `split.region-cpu-overload-threshold-ratio` that supports [dynamic configuration](/dynamic-config.md#modify-tikv-configuration-dynamically).
- Slow query logs, `information_schema.statements_summary`, and `information_schema.slow_query`can export `binary_plan`, or execution plans encoded in the binary format.
- Two columns are added to the `SHOW TABLE ... REGIONS` statement: `SCHEDULING_CONSTRAINTS` and `SCHEDULING_STATE`, which respectively indicate Region scheduling constraints in Placement in SQL and the current scheduling state.
- Since TiDB v6.2.0, you can capture data changes of RawKV via [TiKV-CDC](https://github.com/tikv/migration/tree/main/cdc).
@@ -321,7 +321,7 @@ Since TiDB v6.2.0, backing up and restoring RawKV using BR is deprecated.
+ TiDB
- - Support the `SHOW COUNT(*) WARNINGS` and `SHOW COUNT(*) ERRORS` statements [#25068](https://github.com/pingcap/tidb/issues/25068) @[likzn](https://github.com/likzn)
+ - Support the `SHOW COUNT(*) WARNINGS` and `SHOW COUNT(*) ERRORS` statements [#25068](https://github.com/pingcap/tidb/issues/25068) @[likzn](https://github.com/likzn)
- Add validation check for some system variables [#35048](https://github.com/pingcap/tidb/issues/35048) @[morgo](https://github.com/morgo)
- Optimize the error messages for some type conversions [#32447](https://github.com/pingcap/tidb/issues/32744) @[fanrenhoo](https://github.com/fanrenhoo)
- The `KILL` command now supports DDL operations [#24144](https://github.com/pingcap/tidb/issues/24144) @[morgo](https://github.com/morgo)
@@ -370,7 +370,7 @@ Since TiDB v6.2.0, backing up and restoring RawKV using BR is deprecated.
- TiUP
- - When a new cluster is deployed using TiUP, node-exporter will use the [1.3.1](https://github.com/prometheus/node_exporter/releases/tag/v1.3.1) version, and blackbox-exporter will use the [0.21.1](https://github.com/prometheus/blackbox_exporter/releases/tag/v0.21.1) version, which ensures successful deployment in different systems and environments
+ - When a new cluster is deployed using TiUP, node-exporter will use the [1.3.1](https://github.com/prometheus/node_exporter/releases/tag/v1.3.1) version, and blackbox-exporter will use the [0.21.1](https://github.com/prometheus/blackbox_exporter/releases/tag/v0.21.1) version, which ensures successful deployment in different systems and environments
## Bug fixes
diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md
index dd821f8033889..6295e0fd7a857 100644
--- a/scale-tidb-using-tiup.md
+++ b/scale-tidb-using-tiup.md
@@ -337,17 +337,19 @@ This section exemplifies how to remove a TiFlash node from the `10.0.1.4` host.
### 1. Adjust the number of replicas of the tables according to the number of remaining TiFlash nodes
-Before the node goes down, make sure that the number of remaining nodes in the TiFlash cluster is no smaller than the maximum number of replicas of all tables. Otherwise, modify the number of TiFlash replicas of the related tables.
+1. Query whether any table has TiFlash replicas more than the number of TiFlash nodes after scale-in. `tobe_left_nodes` means the number of TiFlash nodes after scale-in. If the query result is empty, you can start scaling in TiFlash. If the query result is not empty, you need to modify the number of TiFlash replicas of the related table(s).
-1. For all tables whose replicas are greater than the number of remaining TiFlash nodes in the cluster, run the following command in the TiDB client:
+ ```sql
+ SELECT * FROM information_schema.tiflash_replica WHERE REPLICA_COUNT > 'tobe_left_nodes';
+ ```
- {{< copyable "sql" >}}
+2. Execute the following statement for all tables with TiFlash replicas more than the number of TiFlash nodes after scale-in. `new_replica_num` must be less than or equal to `tobe_left_nodes`:
```sql
- ALTER TABLE . SET tiflash replica 0;
+ ALTER TABLE . SET tiflash replica 'new_replica_num';
```
-2. Wait for the TiFlash replicas of the related tables to be deleted. [Check the table replication progress](/tiflash/create-tiflash-replicas.md#check-replication-progress) and the replicas are deleted if the replication information of the related tables is not found.
+3. Perform step 1 again and make sure that there is no table with TiFlash replicas more than the number of TiFlash nodes after scale-in.
### 2. Perform the scale-in operation
diff --git a/schema-object-names.md b/schema-object-names.md
index 36c458ad42e4f..a237ab74597b5 100644
--- a/schema-object-names.md
+++ b/schema-object-names.md
@@ -10,7 +10,7 @@ aliases: ['/docs/dev/schema-object-names/','/docs/dev/reference/sql/language-str
This document introduces schema object names in TiDB SQL statements.
-Schema object names are used to name all schema objects in TiDB, including database, table, index, column, alias, and so on. You can quote these objects using identifiers in SQL statements.
+Schema object names are used to name all schema objects in TiDB, including database, table, index, column, and alias. You can quote these objects using identifiers in SQL statements.
You can use backticks to enclose the identifier. For example, `SELECT * FROM t` can also be written as `` SELECT * FROM `t` ``. But if the identifier includes one or more special characters or is a reserved keyword, it must be enclosed in backticks to quote the schema object it represents.
diff --git a/scripts/check-tags.py b/scripts/check-tags.py
index 1b1f8f84fd7e2..30d0df6336e54 100644
--- a/scripts/check-tags.py
+++ b/scripts/check-tags.py
@@ -124,7 +124,7 @@ def filter_backticks(content, filename):
# print(len(content_findall))
# print(backticks)
# print(backticks[0][0], backticks[0][1])
- print(filename, ": Some of your code blocks ``` ``` are not closed. Please close them.")
+ print(filename, ": Some of your code blocks ``` ``` are not closed. Please close them.")
exit(1)
elif len(backticks) != 0:
backticks_start = backticks[0][0]
diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md
index 0c3e4cca76832..2831a4e24f994 100644
--- a/sql-prepared-plan-cache.md
+++ b/sql-prepared-plan-cache.md
@@ -285,4 +285,14 @@ mysql> select @@last_plan_from_cache; -- Reuse the last plan
| 1 |
+------------------------+
1 row in set (0.00 sec)
-```
\ No newline at end of file
+```
+
+
+
+### Monitoring
+
+In [the Grafana dashboard](/grafana-tidb-dashboard.md) on the TiDB page in the **Executor** section, there are the "Queries Using Plan Cache OPS" and "Plan Cache Miss OPS" graphs. These graphs can be used to check if both TiDB and the application are configured correctly to allow the SQL Plan Cache to work correctly. The **Server** section on the same page provides the "Prepared Statement Count" graph. This graph shows a non-zero value if the application uses prepared statements, which is required for the SQL Plan Cache to function correctly.
+
+
+
+
diff --git a/sql-statements/sql-statement-alter-instance.md b/sql-statements/sql-statement-alter-instance.md
index a71c46ef53b77..e5a1f56744b5e 100644
--- a/sql-statements/sql-statement-alter-instance.md
+++ b/sql-statements/sql-statement-alter-instance.md
@@ -14,7 +14,7 @@ You can execute the `ALTER INSTANCE RELOAD TLS` statement to reload the certific
The newly loaded certificate, key, and CA take effect on the connection that is established after the statement is successfully executed. The connection established before this statement execution is not affected.
-When an error occurs during reloading, by default, this error message is returned and the previous key and certificate continue to be used. However, if you have added the optional `NO ROLLBACK ON ERROR`, when an error occurs during reloading, the error is not returned, and the subsequent requests are handled with the TLS security connection disabled.
+When an error occurs during reloading, by default, this error message is returned and the previous key and certificate continue to be used. However, if you have added the optional `NO ROLLBACK ON ERROR`, when an error occurs during reloading, the error is not returned, and the subsequent requests are handled with the TLS security connection disabled.
## Syntax diagram
diff --git a/sql-statements/sql-statement-create-binding.md b/sql-statements/sql-statement-create-binding.md
index c265daea2b594..b21348269bd2c 100644
--- a/sql-statements/sql-statement-create-binding.md
+++ b/sql-statements/sql-statement-create-binding.md
@@ -95,7 +95,7 @@ mysql> CREATE SESSION BINDING FOR
-> SELECT * FROM t1 IGNORE INDEX (b) WHERE b = 123;
Query OK, 0 rows affected (0.00 sec)
-mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+-------------------------+-----------+---------+-----------+---------------+--------------------------------------------------------------------------------+--------------------+---------------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+-------------------------+-----------+---------+-----------+---------------+--------------------------------------------------------------------------------+--------------------+---------------+------+
@@ -120,7 +120,7 @@ Original_sql: select * from t1 where b = ?
mysql> DROP SESSION BINDING FOR SELECT * FROM t1 WHERE b = 123;
Query OK, 0 rows affected (0.00 sec)
-mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+-------------------------------+---------+---------+-----------+----------------------+-------------------------------------------------------------------------+-----------------------------------+----------------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+-------------------------------+---------+---------+-----------+----------------------+-------------------------------------------------------------------------+-----------------------------------+----------------+------+
diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md
index 28ddd1965bca4..3834ce918b555 100644
--- a/sql-statements/sql-statement-create-index.md
+++ b/sql-statements/sql-statement-create-index.md
@@ -253,7 +253,7 @@ The system variables associated with the `CREATE INDEX` statement are `tidb_ddl_
* Descending indexes are not supported (similar to MySQL 5.7).
* Adding the primary key of the `CLUSTERED` type to a table is not supported. For more details about the primary key of the `CLUSTERED` type, refer to [clustered index](/clustered-indexes.md).
* Expression indexes are incompatible with views. When a query is executed using a view, the expression index cannot be used at the same time.
-* Expression indexes have compatibility issues with bindings. When the expression of an expression index has a constant, the binding created for the corresponding query expands its scope. For example, suppose that the expression in the expression index is `a+1`, and the corresponding query condition is `a+1 > 2`. In this case, the created binding is `a+? > ?`, which means that the query with the condition such as `a+2 > 2` is also forced to use the expression index and results in a poor execution plan. In addition, this also affects the baseline capturing and baseline evolution in SQL Plan Management (SPM).
+* Expression indexes have compatibility issues with bindings. When the expression of an expression index has a constant, the binding created for the corresponding query expands its scope. For example, suppose that the expression in the expression index is `a+1`, and the corresponding query condition is `a+1 > 2`. In this case, the created binding is `a+? > ?`, which means that the query with the condition such as `a+2 > 2` is also forced to use the expression index and results in a poor execution plan. In addition, this also affects the baseline capturing and baseline evolution in SQL Plan Management (SPM).
## See also
diff --git a/sql-statements/sql-statement-drop-binding.md b/sql-statements/sql-statement-drop-binding.md
index 22e031cb7a0de..3ea8c1b1e498c 100644
--- a/sql-statements/sql-statement-drop-binding.md
+++ b/sql-statements/sql-statement-drop-binding.md
@@ -91,7 +91,7 @@ mysql> CREATE SESSION BINDING FOR
-> SELECT * FROM t1 IGNORE INDEX (b) WHERE b = 123;
Query OK, 0 rows affected (0.00 sec)
-mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+-------------------------+-----------+---------+-----------+---------------+--------------------------------------------------------------------------------+--------------------+---------------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+-------------------------+-----------+---------+-----------+---------------+--------------------------------------------------------------------------------+--------------------+---------------+------+
@@ -116,7 +116,7 @@ Original_sql: select * from t1 where b = ?
mysql> DROP SESSION BINDING FOR SELECT * FROM t1 WHERE b = 123;
Query OK, 0 rows affected (0.00 sec)
-mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+-------------------------------+---------+---------+-----------+----------------------+-------------------------------------------------------------------------+-----------------------------------+----------------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+-------------------------------+---------+---------+-----------+----------------------+-------------------------------------------------------------------------+-----------------------------------+----------------+------+
diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md
index c1acd8ffd26fe..f4f2567da603f 100644
--- a/sql-statements/sql-statement-explain-analyze.md
+++ b/sql-statements/sql-statement-explain-analyze.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/sql-statements/sql-statement-explain-analyze/','/docs/dev/r
# EXPLAIN ANALYZE
-The `EXPLAIN ANALYZE` statement works similar to `EXPLAIN`, with the major difference being that it will actually execute the statement. This allows you to compare the estimates used as part of query planning to actual values encountered during execution. If the estimates differ significantly from the actual values, you should consider running `ANALYZE TABLE` on the affected tables.
+The `EXPLAIN ANALYZE` statement works similar to `EXPLAIN`, with the major difference being that it will actually execute the statement. This allows you to compare the estimates used as part of query planning to actual values encountered during execution. If the estimates differ significantly from the actual values, you should consider running `ANALYZE TABLE` on the affected tables.
> **Note:**
>
@@ -155,7 +155,7 @@ The `IndexJoin` operator has 1 outer worker and N inner workers for concurrent e
1. The outer worker reads N outer rows, then wraps it into a task, and sends it to the result channel and the inner worker channel.
2. The inner worker receives the task, build key ranges from the task, and fetches inner rows according to the key ranges. It then builds the inner row hash table.
-3. The main `IndexJoin` thread receives the task from the result channel and waits for the inner worker to finish handling the task.
+3. The main `IndexJoin` thread receives the task from the result channel and waits for the inner worker to finish handling the task.
4. The main `IndexJoin` thread joins each outer row by looking up to the inner rows' hash table.
The `IndexJoin` operator contains the following execution information:
diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md
index ec1b72d93d66d..ffa984683fce8 100644
--- a/sql-statements/sql-statement-explain.md
+++ b/sql-statements/sql-statement-explain.md
@@ -38,6 +38,10 @@ ExplainableStmt ::=
>
> When you use the MySQL client to connect to TiDB, to read the output result in a clearer way without line wrapping, you can use the `pager less -S` command. Then, after the `EXPLAIN` result is output, you can press the right arrow → button on your keyboard to horizontally scroll through the output.
+> **Note:**
+>
+> In the returned execution plan, for all probe-side child nodes of `IndexJoin` and `Apply` operators, the meaning of `estRows` since v6.4.0 is different from that before v6.4.0. You can find details in [TiDB Query Execution Plan Overview](/explain-overview.md#understand-explain-output).
+
Currently, `EXPLAIN` in TiDB outputs 5 columns: `id`, `estRows`, `task`, `access object`, `operator info`. Each operator in the execution plan is described by these attributes, with each row in the `EXPLAIN` output describing an operator. The description of each attribute is as follows:
| Attribute name | Description |
@@ -271,7 +275,7 @@ If your computer has no `dot` program, copy the result to [this website](http://
## MySQL compatibility
* Both the format of `EXPLAIN` and the potential execution plans in TiDB differ substaintially from MySQL.
-* TiDB does not support the `FORMAT=JSON` or `FORMAT=TREE` options.
+* TiDB does not support the `FORMAT=JSON` or `FORMAT=TREE` options.
### `EXPLAIN FOR CONNECTION`
diff --git a/sql-statements/sql-statement-flashback-database.md b/sql-statements/sql-statement-flashback-database.md
new file mode 100644
index 0000000000000..485a97dfcabcb
--- /dev/null
+++ b/sql-statements/sql-statement-flashback-database.md
@@ -0,0 +1,69 @@
+---
+title: FLASHBACK DATABASE
+summary: Learn the usage of FLASHBACK DATABASE in TiDB databases.
+---
+
+# FLASHBACK DATABASE
+
+TiDB v6.4.0 introduces the `FLASHBACK DATABASE` syntax. You can use `FLASHBACK DATABASE` to restore a database and its data that are deleted by the `DROP` statement within the Garbage Collection (GC) life time.
+
+You can set the retention time of historical data by configuring the [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) system variable. The default value is `10m0s`. You can query the current `safePoint`, that is, the time point GC has been performed up to, using the following SQL statement:
+
+```sql
+SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point';
+```
+
+As long as a database is deleted by `DROP` after the `tikv_gc_safe_point` time, you can use `FLASHBACK DATABASE` to restore the database.
+
+## Syntax
+
+```sql
+FLASHBACK DATABASE DBName [TO newDBName]
+```
+
+### Synopsis
+
+```ebnf+diagram
+FlashbackDatabaseStmt ::=
+ 'FLASHBACK' DatabaseSym DBName FlashbackToNewName
+FlashbackToNewName ::=
+ ( 'TO' Identifier )?
+```
+
+## Notes
+
+* If the database is deleted before the `tikv_gc_safe_point` time, you cannot restore the data using the `FLASHBACK DATABASE` statement. The `FLASHBACK DATABASE` statement returns an error similar to `ERROR 1105 (HY000): Can't find dropped database 'test' in GC safe point 2022-11-06 16:10:10 +0800 CST`.
+
+* You cannot restore the same database multiple times using the `FLASHBACK DATABASE` statement. Because the database restored by `FLASHBACK DATABASE` has the same schema ID as the original database, restoring the same database multiple times leads to duplicate schema IDs. In TiDB, the database schema ID must be globally unique.
+
+* When TiDB Binlog is enabled, note the following when you use `FLASHBACK DATABASE`:
+
+ * The downstream secondary database must support `FLASHBACK DATABASE`.
+ * The GC life time of the secondary database must be longer than that of the primary database. Otherwise, the latency between the upstream and the downstream might lead to data restoration failure in the downstream.
+ * If TiDB Binlog replication encounters an error, you need to filter out the database in TiDB Binlog and then manually import full data for this database.
+
+## Example
+
+- Restore the `test` database that is deleted by `DROP`:
+
+ ```sql
+ DROP DATABASE test;
+ ```
+
+ ```sql
+ FLASHBACK DATABASE test;
+ ```
+
+- Restore the `test` database that is deleted by `DROP` and rename it to `test1`:
+
+ ```sql
+ DROP DATABASE test;
+ ```
+
+ ```sql
+ FLASHBACK DATABASE test TO test1;
+ ```
+
+## MySQL compatibility
+
+This statement is a TiDB extension to MySQL syntax.
diff --git a/sql-statements/sql-statement-rollback.md b/sql-statements/sql-statement-rollback.md
index 0a0497a05d1cb..9a8090c92fc4c 100644
--- a/sql-statements/sql-statement-rollback.md
+++ b/sql-statements/sql-statement-rollback.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/sql-statements/sql-statement-rollback/','/docs/dev/referenc
# ROLLBACK
-This statement reverts all changes in the current transaction inside of TIDB. It is the opposite of a `COMMIT` statement.
+This statement reverts all changes in the current transaction inside of TIDB. It is the opposite of a `COMMIT` statement.
## Synopsis
diff --git a/sql-statements/sql-statement-show-bindings.md b/sql-statements/sql-statement-show-bindings.md
index c64d53e5cf0a7..4fe2548dd6d77 100644
--- a/sql-statements/sql-statement-show-bindings.md
+++ b/sql-statements/sql-statement-show-bindings.md
@@ -116,7 +116,7 @@ mysql> CREATE SESSION BINDING FOR
-> SELECT * FROM t1 IGNORE INDEX (b) WHERE b = 123;
Query OK, 0 rows affected (0.00 sec)
-mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
+-------------------------+-----------+---------+-----------+---------------+--------------------------------------------------------------------------------+--------------------+---------------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+-------------------------+-----------+---------+-----------+---------------+--------------------------------------------------------------------------------+--------------------+---------------+------+
diff --git a/sql-statements/sql-statement-show-create-user.md b/sql-statements/sql-statement-show-create-user.md
index aa42295cf139b..d43ffbce8cad7 100644
--- a/sql-statements/sql-statement-show-create-user.md
+++ b/sql-statements/sql-statement-show-create-user.md
@@ -40,7 +40,7 @@ mysql> SHOW GRANTS FOR 'root';
## MySQL compatibility
-* The output of `SHOW CREATE USER` is designed to match MySQL, but several of the `CREATE` options are not yet supported by TiDB. Not yet supported options will be parsed but ignored. See [security compatibility] for more details.
+* The output of `SHOW CREATE USER` is designed to match MySQL, but several of the `CREATE` options are not yet supported by TiDB. Not yet supported options will be parsed but ignored. See [security compatibility] for more details.
## See also
diff --git a/sql-statements/sql-statement-show-errors.md b/sql-statements/sql-statement-show-errors.md
index 280066ac98d9e..0d7875b9ab460 100644
--- a/sql-statements/sql-statement-show-errors.md
+++ b/sql-statements/sql-statement-show-errors.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/sql-statements/sql-statement-show-errors/','/docs/dev/refer
# SHOW ERRORS
-This statement shows error(s) from previously executed statements. The error buffer is cleared as soon as a statement executes successfully. In which case, `SHOW ERRORS` will return an empty set.
+This statement shows errors from previously executed statements. The error buffer is cleared as soon as a statement executes successfully. In which case, `SHOW ERRORS` will return an empty set.
The behavior of which statements generate errors vs. warnings is highly influenced by the current `sql_mode`.
diff --git a/sql-statements/sql-statement-show-indexes.md b/sql-statements/sql-statement-show-indexes.md
index bcfc007d2aecb..8c99a9b0c5f16 100644
--- a/sql-statements/sql-statement-show-indexes.md
+++ b/sql-statements/sql-statement-show-indexes.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/sql-statements/sql-statement-show-indexes/','/docs/dev/refe
# SHOW INDEXES [FROM|IN]
-The statement `SHOW INDEXES [FROM|IN]` lists the indexes on a specified table. The statements `SHOW INDEX [FROM|IN]`, `SHOW KEYS [FROM|IN]` are aliases of this statement, and included for compatibility with MySQL.
+The statement `SHOW INDEXES [FROM|IN]` lists the indexes on a specified table. The statements `SHOW INDEX [FROM|IN]`, `SHOW KEYS [FROM|IN]` are aliases of this statement, and included for compatibility with MySQL.
## Synopsis
diff --git a/sql-statements/sql-statement-show-placement.md b/sql-statements/sql-statement-show-placement.md
index 042c607a03553..d137ec9bee7ed 100644
--- a/sql-statements/sql-statement-show-placement.md
+++ b/sql-statements/sql-statement-show-placement.md
@@ -9,7 +9,7 @@ summary: The usage of SHOW PLACEMENT in TiDB.
The statement returns a result set in which the `Scheduling_State` field indicates the current progress that the Placement Driver (PD) has made in scheduling the placement:
-* `PENDING`: The PD has not yet started scheduling the placement. This might indicate that that the placement rules are semantically correct, but can not currently be satisfied by the cluster. For example, if `FOLLOWERS=4` but there are only 3 TiKV stores which are candidates for followers.
+* `PENDING`: The PD has not yet started scheduling the placement. This might indicate that that the placement rules are semantically correct, but cannot currently be satisfied by the cluster. For example, if `FOLLOWERS=4` but there are only 3 TiKV stores which are candidates for followers.
* `INPROGRESS`: The PD is currently scheduling the placement.
* `SCHEDULED`: The PD has successfully scheduled the placement.
diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md
index 5e59e509bd6d5..9a4ba56dc6928 100644
--- a/sql-statements/sql-statement-split-region.md
+++ b/sql-statements/sql-statement-split-region.md
@@ -172,7 +172,7 @@ If the column of index idx1 is of varchar type, and you want to split index data
SPLIT TABLE t INDEX idx1 BETWEEN ("a") AND ("z") REGIONS 25;
```
-This statement splits index idx1 into 25 Regions from a~z. The range of Region 1 is `[minIndexValue, b)`; the range of Region 2 is `[b, c)`; … the range of Region 25 is `[y, minIndexValue]`. For the `idx` index, data with the `a` prefix is written into Region 1, and data with the `b` prefix is written into Region 2, and so on.
+This statement splits index idx1 into 25 Regions from a~z. The range of Region 1 is `[minIndexValue, b)`; the range of Region 2 is `[b, c)`; … the range of Region 25 is `[y, minIndexValue]`. For the `idx` index, data with the `a` prefix is written into Region 1, and data with the `b` prefix is written into Region 2.
In the split method above, both data with the `y` and `z` prefixes are written into Region 25, because the upper bound is not `z`, but `{` (the character next to `z` in ASCII). Therefore, a more accurate split method is as follows:
@@ -192,7 +192,7 @@ If the column of index `idx2` is of time type like timestamp/datetime, and you w
SPLIT TABLE t INDEX idx2 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00:00") REGIONS 10;
```
-This statement splits the Region of index `idx2` in table `t` into 10 Regions from `2010-01-01 00:00:00` to `2020-01-01 00:00:00`. The range of Region 1 is `[minIndexValue, 2011-01-01 00:00:00)`; the range of Region 2 is `[2011-01-01 00:00:00, 2012-01-01 00:00:00)` and so on.
+This statement splits the Region of index `idx2` in table `t` into 10 Regions from `2010-01-01 00:00:00` to `2020-01-01 00:00:00`. The range of Region 1 is `[minIndexValue, 2011-01-01 00:00:00)`; the range of Region 2 is `[2011-01-01 00:00:00, 2012-01-01 00:00:00)`.
If you want to split the index Region by day, see the following example:
diff --git a/statement-summary-tables.md b/statement-summary-tables.md
index 3a3bc2f257d11..d5c22a8a72cb6 100644
--- a/statement-summary-tables.md
+++ b/statement-summary-tables.md
@@ -333,7 +333,7 @@ Transaction-related fields:
- `SUM_BACKOFF_TIMES`: The sum of retries when SQL statements of this category encounter errors that require a retry.
- `BACKOFF_TYPES`: All types of errors that require retries and the number of retries for each type. The format of the field is `type:number`. If there is more than one error type, each is separated by a comma, like `txnLock:2,pdRPC:1`.
- `AVG_AFFECTED_ROWS`: The average number of rows affected.
-- `PREV_SAMPLE_TEXT`: When the current SQL statement is `COMMIT`, `PREV_SAMPLE_TEXT` is the previous statement to `COMMIT`. In this case, SQL statements are grouped by the digest and `prev_sample_text`. This means that `COMMIT` statements with different `prev_sample_text` are grouped to different rows. When the current SQL statement is not `COMMIT`, the `PREV_SAMPLE_TEXT` field is an empty string.
+- `PREV_SAMPLE_TEXT`: When the current SQL statement is `COMMIT`, `PREV_SAMPLE_TEXT` is the previous statement to `COMMIT`. In this case, SQL statements are grouped by the digest and `prev_sample_text`. This means that `COMMIT` statements with different `prev_sample_text` are grouped to different rows. When the current SQL statement is not `COMMIT`, the `PREV_SAMPLE_TEXT` field is an empty string.
### `statements_summary_evicted` fields description
diff --git a/statistics.md b/statistics.md
index 3f5d3fbbc583f..d9e53670f17d5 100644
--- a/statistics.md
+++ b/statistics.md
@@ -715,17 +715,13 @@ By default, depending on the size of column statistics, TiDB loads statistics di
Since v5.4.0, TiDB introduces the synchronously loading statistics feature. This feature allows TiDB to synchronously load large-sized statistics (such as histograms, TopN, and Count-Min Sketch statistics) into memory when you execute SQL statements, which improves the completeness of statistics for SQL optimization.
-> **Warning:**
->
-> Currently, synchronously loading statistics is an experimental feature. It is not recommended that you use it in production environments.
-
-The synchronously loading statistics feature is disabled by default. To enable this feature, set the value of the [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540) system variable to a timeout (in milliseconds) that SQL optimization can wait for at most to synchronously load complete column statistics. The default value of this variable is `0`, indicating that the feature is disabled.
+To enable this feature, set the value of the [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540) system variable to a timeout (in milliseconds) that SQL optimization can wait for at most to synchronously load complete column statistics. The default value of this variable is `100`, indicating that the feature is enabled.
After enabling the synchronously loading statistics feature, you can further configure the feature as follows:
-- To control how TiDB behaves when the waiting time of SQL optimization reaches the timeout, modify the value of the [`tidb_stats_load_pseudo_timeout`](/system-variables.md#tidb_stats_load_pseudo_timeout-new-in-v540) system variable. The default value of this variable is `OFF`, indicating that the SQL execution fails after the timeout. If you set this variable to `ON`, after the timeout, the SQL optimization process does not use any histogram, TopN, or CMSketch statistics on any columns, but gets back to using pseudo statistics.
+- To control how TiDB behaves when the waiting time of SQL optimization reaches the timeout, modify the value of the [`tidb_stats_load_pseudo_timeout`](/system-variables.md#tidb_stats_load_pseudo_timeout-new-in-v540) system variable. The default value of this variable is `ON`, indicating that after the timeout, the SQL optimization process does not use any histogram, TopN, or CMSketch statistics on any columns. If this variable is set to `OFF`, after the timeout, SQL execution fails.
- To specify the maximum number of columns that the synchronously loading statistics feature can process concurrently, modify the value of the [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-new-in-v540) option in the TiDB configuration file. The default value is `5`.
- To specify the maximum number of column requests that the synchronously loading statistics feature can cache, modify the value of the [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-new-in-v540) option in the TiDB configuration file. The default value is `1000`.
diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md
index 3a6814ef05fb2..b5bb12431c3cd 100644
--- a/storage-engine/titan-configuration.md
+++ b/storage-engine/titan-configuration.md
@@ -20,7 +20,7 @@ Titan is compatible with RocksDB, so you can directly enable Titan on the existi
rocksdb.titan.enabled: true
```
- Reload the configuration and TiKV will be rolling restarted online:
+ Reload the configuration and TiKV will be rolling restarted dynamically:
{{< copyable "shell-regular" >}}
diff --git a/styles/PingCAP/Latin.yml b/styles/PingCAP/Latin.yml
index 883f2f0783606..2dfd31602da21 100644
--- a/styles/PingCAP/Latin.yml
+++ b/styles/PingCAP/Latin.yml
@@ -9,4 +9,4 @@ action:
swap:
'\b(?:eg|e\.g\.)[\s,]': for example
'\b(?:ie|i\.e\.)[\s,]': that is
- '\b(?:etc|e\.t\.c\.)[\s,\.]': and so on
+ '\b(?:etc|and so on|e\.t\.c\.)[\s,\.]': such as
diff --git a/subquery-optimization.md b/subquery-optimization.md
index 6391c832eeb80..bb7bb633f94cc 100644
--- a/subquery-optimization.md
+++ b/subquery-optimization.md
@@ -58,8 +58,8 @@ explain select * from t1 where t1.a in (select t2.a from t2);
| ├─HashAgg_21(Build) | 7992.00 | root | | group by:test.t2.a, funcs:firstrow(test.t2.a)->test.t2.a |
| │ └─IndexReader_28 | 9990.00 | root | | index:IndexFullScan_27 |
| │ └─IndexFullScan_27 | 9990.00 | cop[tikv] | table:t2, index:idx(a) | keep order:false, stats:pseudo |
-| └─TableReader_11(Probe) | 1.00 | root | | data:TableRangeScan_10 |
-| └─TableRangeScan_10 | 1.00 | cop[tikv] | table:t1 | range: decided by [test.t2.a], keep order:false, stats:pseudo |
+| └─TableReader_11(Probe) | 7992.00 | root | | data:TableRangeScan_10 |
+| └─TableRangeScan_10 | 7992.00 | cop[tikv] | table:t1 | range: decided by [test.t2.a], keep order:false, stats:pseudo |
+------------------------------+---------+-----------+------------------------+----------------------------------------------------------------------------+
```
diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md
index 9aadc3b802cf2..950238a7c4f9c 100644
--- a/sync-diff-inspector/sync-diff-inspector-overview.md
+++ b/sync-diff-inspector/sync-diff-inspector-overview.md
@@ -286,5 +286,5 @@ REPLACE INTO `sbtest`.`sbtest99`(`id`,`k`,`c`,`pad`) VALUES (3700000,2501808,'he
- sync-diff-inspector consumes a certain amount of server resources when checking data. Avoid using sync-diff-inspector to check data during peak business hours.
- Before comparing the data in MySQL with that in TiDB, pay attention to the collation configuration of the tables. If the primary key or unique key is the `varchar` type and the collation configuration in MySQL differs from that in TiDB, the final check result might be incorrect because of the collation issue. You need to add collation to the sync-diff-inspector configuration file.
- sync-diff-inspector divides data into chunks first according to TiDB statistics and you need to guarantee the accuracy of the statistics. You can manually run the `analyze table {table_name}` command when the TiDB server's *workload is light*.
-- Pay special attention to `table-rules`. If you configure `schema-pattern="test1"`, `table-pattern = "t_1"`, `target-schema="test2"` and `target-table = "t_2"`, the `test1`.`t_1` schema in the source database and the `test2`.`t_2` schema in the target database are compared. Sharding is enabled by default in sync-diff-inspector, so if the source database has a `test2`.`t_2` table, the `test1`.`t_1` table and `test2`.`t_2` table in the source database serving as sharding are compared with the `test2`.`t_2` table in the target database.
+- Pay special attention to `table-rules`. If you configure `schema-pattern="test1"`, `table-pattern = "t_1"`, `target-schema="test2"` and `target-table = "t_2"`, the `test1`.`t_1` schema in the source database and the `test2`.`t_2` schema in the target database are compared. Sharding is enabled by default in sync-diff-inspector, so if the source database has a `test2`.`t_2` table, the `test1`.`t_1` table and `test2`.`t_2` table in the source database serving as sharding are compared with the `test2`.`t_2` table in the target database.
- The generated SQL file is only used as a reference for repairing data, and you need to confirm it before executing these SQL statements to repair data.
diff --git a/system-variables.md b/system-variables.md
index 9f95d3de35f73..9d34d1fa3c864 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -19,7 +19,7 @@ SET SESSION tidb_distsql_scan_concurrency = 10;
# These two identical statements change a global variable
SET @@global.tidb_distsql_scan_concurrency = 10;
-SET GLOBAL tidb_distsql_scan_concurrency = 10;
+SET GLOBAL tidb_distsql_scan_concurrency = 10;
```
> **Note:**
@@ -198,7 +198,9 @@ mysql> SELECT * FROM t1;
- Scope: GLOBAL
- Persists to cluster: No, only applicable to the current TiDB instance that you are connecting to.
+- Type: Integer
- Default value: `300`
+- Range: `[0, 2147483647]`
- Unit: Milliseconds
- Log DDL operations whose execution time exceeds the threshold value.
@@ -255,12 +257,14 @@ For more possible values of this variable, see [Authentication plugin status](/s
### have_openssl
- Scope: NONE
+- Type: Boolean
- Default value: `DISABLED`
- A read-only variable for MySQL compatibility. Set to `YES` by the server when the server has TLS enabled.
### have_ssl
- Scope: NONE
+- Type: Boolean
- Default value: `DISABLED`
- A read-only variable for MySQL compatibility. Set to `YES` by the server when the server has TLS enabled.
@@ -304,7 +308,9 @@ This variable is an alias for [`last_insert_id`](#last_insert_id).
### last_insert_id
- Scope: SESSION
+- Type: Integer
- Default value: `0`
+- Range: `[0, 9223372036854775807]`
- This variable returns the last `AUTO_INCREMENT` or `AUTO_RANDOM` value generated by an insert statement.
- The value of `last_insert_id` is the same as the value returned by the function `LAST_INSERT_ID()`.
@@ -346,8 +352,9 @@ This variable is an alias for [`last_insert_id`](#last_insert_id).
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Default value: `67108864`
-- Range: `[1024, 1073741824]`. The value should be an integer multiple of 1024. If the value is not divisible by 1024, a warning will be prompted and the value will be rounded down. For example, when the value is set to 1025, the actual value in TiDB is 1024.
-- The maximum packet size allowed by the server and the client in one transmission of packets, in bytes.
+- Range: `[1024, 1073741824]`
+- The value should be an integer multiple of 1024. If the value is not divisible by 1024, a warning will be prompted and the value will be rounded down. For example, when the value is set to 1025, the actual value in TiDB is 1024.
+- The maximum packet size allowed by the server and the client in one transmission of packets.
- This variable is compatible with MySQL.
### max_connections
@@ -597,6 +604,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count';
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Default value: `4096`
+- Range: `[0, 9223372036854775807]`
- This variable is used to control the threshold at which the TiDB server prefers to send read requests to the replica in the same region as the TiDB server when [`tidb_replica_read`](#tidb_replica_read-new-in-v40) is set to `closest-adaptive`. If the estimated result is higher than or equal to this threshold, TiDB prefers to send read requests to the replica in the same region. Otherwise, TiDB sends read requests to the leader replica.
### tidb_allow_batch_cop New in v4.0
@@ -652,6 +660,17 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Default value: `OFF`
- 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_analyze_partition_concurrency
+
+> **Warning:**
+>
+> The feature controlled by this variable is not fully functional in the current TiDB version. Do not change the default value.
+
+- Scope: SESSION | GLOBAL
+- Persists to cluster: Yes
+- Default value: `1`
+- This variable specifies the concurrency of reading and writing statistics for a partitioned table when TiDB analyzes the partitioned table.
+
### tidb_analyze_version New in v5.1.0
- Scope: SESSION | GLOBAL
@@ -685,22 +704,6 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
-### tidb_auth_signing_cert
-
-- Scope: GLOBAL
-- Persists to cluster: Yes
-- Type: String
-- Default value: ""
-- This variable is associated with an unreleased feature. **DO NOT** set this variable.
-
-### tidb_auth_signing_key
-
-- Scope: GLOBAL
-- Persists to cluster: Yes
-- Type: String
-- Default value: ""
-- This variable is associated with an unreleased feature. **DO NOT** set this variable.
-
### tidb_auto_analyze_end_time
- Scope: GLOBAL
@@ -799,8 +802,9 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `4000`
-- Range: `[0, 2147483647]`
+- Range: `[0, 4294967295]`
- Specifies the maximum number of permitted unavailable tables when you use `ALTER DATABASE SET TIFLASH REPLICA` to add TiFlash replicas. If the number of unavailable tables exceeds this limit, the operation will be stopped or setting TiFlash replicas for the remaining tables will be very slow.
### tidb_broadcast_join_threshold_count New in v5.0
@@ -827,7 +831,9 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `4`
+- 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.
@@ -861,7 +867,9 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
### tidb_checksum_table_concurrency
- Scope: SESSION
+- Type: Integer
- Default value: `4`
+- Range: `[1, 256]`
- Unit: Threads
- This variable is used to set the scan index concurrency of executing the [`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) statement.
- When the variable is set to a larger value, the execution performance of other queries is affected.
@@ -924,9 +932,21 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
### `tidb_constraint_check_in_place_pessimistic` New in v6.3.0
-- Scope: SESSION | GLOBAL
-- Persists to cluster: Yes
+- Scope: SESSION
+- Type: Boolean
+
+
+
+- Default value: By default, the [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640) configuration item is `true` so the default value of this variable is `ON`. When [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640) is set to `false`, the default value of this variable is `OFF`.
+
+
+
+
+
- Default value: `ON`
+
+
+
- This variable only applies to pessimistic transactions. For optimistic transactions, use [`tidb_constraint_check_in_place`](#tidb_constraint_check_in_place) instead.
- When this variable is set to `OFF`, TiDB defers the unique constraint check of a unique index (to the next time when executing a statement that requires a lock to the index or to the time when committing the transaction). This helps improve performance but might be an unexpected behavior for some applications. See [Constraints](/constraints.md#pessimistic-transactions) for details.
- Disabling this variable might cause TiDB to return a `LazyUniquenessCheckFailure` error in pessimistic transactions. When this error occurs, TiDB rolls back the current transaction.
@@ -984,8 +1004,9 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `1`
-- Value options: `1`, `2`
+- Range: `[1, 2]`
- TiDB v6.2.0 introduces the [Cost Model Version 2](/cost-model.md#cost-model-version-2), which is more accurate than the previous version in internal tests.
- To enable the Cost Model Version 2, you can set the `tidb_cost_model_version` to `2`. If you set this variable to `1`, the Cost Model Version 1 will be used.
- The version of cost model affects the plan decision of optimizer. For more details, see [Cost Model](/cost-model.md).
@@ -993,7 +1014,9 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
### tidb_current_ts
- Scope: SESSION
+- Type: Integer
- Default value: `0`
+- Range: `[0, 9223372036854775807]`
- This variable is read-only. It is used to obtain the timestamp of the current transaction.
### tidb_ddl_disk_quota New in v6.3.0
@@ -1041,6 +1064,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `64`
- Range: `[1, 256]`
@@ -1065,7 +1089,9 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
### tidb_ddl_reorg_priority
- Scope: SESSION
+- Type: Enumeration
- Default value: `PRIORITY_LOW`
+- Value options: `PRIORITY_LOW`, `PRIORITY_NORMAL`, `PRIORITY_HIGH`
- 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`.
@@ -1083,6 +1109,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Float
- Default value: `0.8`
- Range: `[0, 1]`
- This variable is used to set the default selectivity of `like`, `rlike`, and `regexp` functions in the filter condition when estimating the number of rows. This variable also controls whether to enable TopN to help estimate these functions.
@@ -1256,7 +1283,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Type: Enumeration
-- Default value: `INT_ONLY`
+- Default value: `ON`
- Possible values: `OFF`, `ON`, `INT_ONLY`
- This variable is used to control whether to create the primary key as a [clustered index](/clustered-indexes.md) by default. "By default" here means that the statement does not explicitly specify the keyword `CLUSTERED`/`NONCLUSTERED`. Supported values are `OFF`, `ON`, and `INT_ONLY`:
- `OFF` indicates that primary keys are created as non-clustered indexes by default.
@@ -1307,6 +1334,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `ON`
- This variable controls whether to allow TiDB to use concurrent DDL statements. When concurrent DDL statements are used, the DDL execution flow is changed, and DDL statements are not easily blocked by other DDL statements. In addition, multiple indexes can be added at the same time.
@@ -1401,6 +1429,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
- This variable controls whether to enable the `FOREIGN KEY` feature.
@@ -1424,9 +1453,18 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
- This variable controls whether to enable the General Plan Cache feature.
+### tidb_enable_gogc_tuner New in v6.4.0
+
+- Scope: GLOBAL
+- Persists to cluster: No, only applicable to the current TiDB instance that you are connecting to.
+- Type: Boolean
+- Default value: `ON`
+- This variable controls whether to enable GOGC Tuner.
+
### tidb_enable_historical_stats
- Scope: GLOBAL
@@ -1517,7 +1555,6 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Persists to cluster: Yes
- Type: Boolean
- Default value: `ON`
-- Value options: `OFF` and `ON`
- TiDB v6.2.0 refactors the implementation of previous cost model. This variable controls whether to enable the refactored Cost Model implementation.
- This variable is enabled by default because the refactored Cost Model uses the same cost formula as before, which does not change the plan decision.
- If your cluster is upgraded from v6.1 to v6.2, this variable remains `OFF`, and it is recommended to enable it manually. If your cluster is upgraded from a version earlier than v6.1, this variable sets to `ON` by default.
@@ -1526,8 +1563,8 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
-- Value options: `OFF` and `ON`
- This variable controls the behavior when TiDB performs the `ONLY_FULL_GOUP_BY` check. For detailed information about `ONLY_FULL_GROUP_BY`, see the [MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_only_full_group_by). In v6.1.0, TiDB handles this check more strictly and correctly.
- To avoid potential compatibility issues caused by version upgrades, the default value of this variable is `OFF` in v6.1.0.
@@ -1563,15 +1600,17 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
### `tidb_enable_null_aware_anti_join` New in v6.3.0
-- Scope: SESSION ｜GLOBAL
+- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Default value: `OFF`
+- Type: Boolean
- This variable controls whether TiDB applies Null Aware Hash Join when ANTI JOIN is generated by subqueries led by special set operators `NOT IN` and `!= ALL`.
### tidb_enable_outer_join_reorder New in v6.1.0
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: In v6.1.0, the default value is `ON`. After v6.1.0, the default value is `OFF`.
- Since v6.1.0, the [Join Reorder](/join-reorder.md) algorithm of TiDB supports Outer Join. This variable controls the support behavior. The default value is `OFF`, which means the Join Reorder's support for Outer Join is disabled by default.
- For a cluster upgraded from a version earlier than v6.1.0, the default value is `OFF`. For a cluster upgraded from v6.1.0, the default value is `ON`.
@@ -1580,6 +1619,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
- Specifies whether to sort the final output result automatically.
- For example, with this variable enabled, TiDB processes `SELECT a, MAX(b) FROM t GROUP BY a` as `SELECT a, MAX(b) FROM t GROUP BY a ORDER BY a, MAX(b)`.
@@ -1589,10 +1629,17 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Type: Boolean
-- Default value: `OFF`
-- This variable controls whether to use the method of paging to send coprocessor requests in `IndexLookUp` operator.
-- User scenarios: For read queries that use `IndexLookup` and `Limit` and that `Limit` cannot be pushed down to `IndexScan`, there might be high latency for the read queries and high CPU usage for TiKV's `unified read pool`. In such cases, because the `Limit` operator only requires a small set of data, if you set `tidb_enable_paging` to `ON`, TiDB processes less data, which reduces query latency and resource consumption.
-- When `tidb_enable_paging` is enabled, for the `IndexLookUp` requests with `Limit` that cannot be pushed down and are fewer than `960`, TiDB uses the method of paging to send coprocessor requests. The fewer `Limit`, the more obvious the optimization.
+- Default value: `ON`
+- This variable controls whether to use the method of paging to send coprocessor requests. For TiDB versions in [v5.4.0, v6.2.0), this variable only takes effect on the `IndexLookup` operator; for v6.2.0 and later, this variable takes effect globally. Starting from v6.4.0, the default value of this variable is changed from `OFF` to `ON`.
+- User scenarios:
+
+ - In all OLTP scenarios, it is recommended to use the method of paging.
+ - For read queries that use `IndexLookup` and `Limit` and that `Limit` cannot be pushed down to `IndexScan`, there might be high latency for the read queries and high usage for TiKV `Unified read pool CPU`. In such cases, because the `Limit` operator only requires a small set of data, if you set `tidb_enable_paging` to `ON`, TiDB processes less data, which reduces query latency and resource consumption.
+ - In scenarios such as data export using [Dumpling](/dumpling-overview.md) and full table scan, enabling paging can effectively reduce the memory consumption of TiDB processes.
+
+> **Note:**
+>
+> In OLAP scenarios where TiKV is used as the storage engine instead of TiFlash, enabling paging might cause performance regression in some cases. If the regression occurs, consider using this variable to disable paging, or using the [`tidb_min_paging_size`](/system-variables.md#tidb_min_paging_size-new-in-v620) and [`tidb_max_paging_size`](/system-variables.md#tidb_max_paging_size-new-in-v630) variables to adjust the range of rows for paging size.
### tidb_enable_parallel_apply New in v5.0
@@ -1623,7 +1670,7 @@ MPP is a distributed computing framework provided by the TiFlash engine, which a
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
-- Default value： `ON`
+- Default value: `ON`
- This variable controls whether to count the memory consumed by the execution plans cached in the Prepared Plan Cache. For details, see [Memory management of Prepared Plan Cache](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache).
### tidb_enable_pseudo_for_outdated_stats New in v5.3.0
@@ -1784,6 +1831,7 @@ Query OK, 0 rows affected (0.09 sec)
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
- This variable controls whether read requests in SQL write statements can be pushed down to TiFlash.
@@ -1976,9 +2024,11 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: GLOBAL
- Persists to cluster: No, only applicable to the current TiDB instance that you are connecting to.
+- Type: Enumeration
- Default value: `NO_PRIORITY`
+- Possible values: `NO_PRIORITY`, `LOW_PRIORITY`, `HIGH_PRIORITY`, `DELAYED`
- 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.
-- The default value `NO_PRIORITY` means that the priority for statements is not forced to change. Other options are `LOW_PRIORITY`, `DELAYED`, and `HIGH_PRIORITY` in ascending order.
+- The default value `NO_PRIORITY` means that the priority for statements is not forced to change.
### tidb_gc_concurrency New in v5.0
@@ -2018,10 +2068,11 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `86400`
- Range: `[600, 31536000]`
- Unit: Seconds
-- This variable is used to set the maximum time that active transactions block the GC safe point. During each time of GC, the safe point does not exceed the start time of the ongoing transactions by default. If the runtime of active transactions does not exceed this variable value, the GC safe point will be blocked until the runtime exceeds this value. This variable value is an integer type.
+- This variable is used to set the maximum time that active transactions block the GC safe point. During each time of GC, the safe point does not exceed the start time of the ongoing transactions by default. If the runtime of active transactions does not exceed this variable value, the GC safe point will be blocked until the runtime exceeds this value.
### tidb_gc_run_interval New in v5.0
@@ -2083,7 +2134,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- This variable is used to set whether to record all SQL statements in the [log](/tidb-configuration-file.md#logfile). This feature is disabled by default. If maintenance personnel needs to trace all SQL statements when locating issues, they can enable this feature.
-- To see all records of this feature in the log, query the `"GENERAL_LOG"` string. The following information is recorded:
+- To see all records of this feature in the log, you need to set the TiDB configuration item [`log.level`](/tidb-configuration-file.md#level) to `"info"` or `"debug"` and then query the `"GENERAL_LOG"` string. The following information is recorded:
- `conn`: The ID of the current session.
- `user`: The current session user.
- `schemaVersion`: The current schema version.
@@ -2104,6 +2155,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `100`
- Range: `[1, 100000]`
- This variable controls the maximum number of execution plans that can be cached by General Plan Cache.
@@ -2112,20 +2164,29 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `ON`
- This variable controls whether to generate binary-encoded execution plans in slow logs and statement summaries.
- When this variable is set to `ON`, you can view visual execution plans in TiDB Dashboard. Note that TiDB Dashboard only provides visual display for execution plans generated after this variable is enabled.
- You can execute the `SELECT tidb_decode_binary_plan('xxx...')` statement to parse the specific plan from a binary plan.
+### tidb_gogc_tuner_threshold New in v6.4.0
+
+- Scope: GLOBAL
+- Persists to cluster: No, only applicable to the current TiDB instance that you are connecting to.
+- Default value: `0.6`
+- Range: `[0, 0.9)`
+- This variable specifies the maximum memory threshold for tuning GOGC. When the memory exceeds this threshold, GOGC Tuner stops working.
+
### tidb_guarantee_linearizability New in v5.0
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Type: Boolean
- Default value: `ON`
-- This variable controls the way commit TS is calculated for async commit. By default (with the `OFF` value), the two-phase commit requests a new TS from the PD server and uses the TS to calculate the final commit TS. In this situation, linearizability is guaranteed for all the concurrent transactions.
-- If you set this variable to `ON`, the process of fetching TS from the PD server is skipped, with the cost that only causal consistency is guaranteed but not linearizability. For more details, see the blog post [Async Commit, the Accelerator for Transaction Commit in TiDB 5.0](https://en.pingcap.com/blog/async-commit-the-accelerator-for-transaction-commit-in-tidb-5-0/).
-- For scenarios that require only causal consistency, you can set this variable to `ON` to improve performance.
+- This variable controls the way commit TS is calculated for async commit. By default (with the `ON` value), the two-phase commit requests a new TS from the PD server and uses the TS to calculate the final commit TS. In this situation, linearizability is guaranteed for all the concurrent transactions.
+- If you set this variable to `OFF`, the process of fetching TS from the PD server is skipped, with the cost that only causal consistency is guaranteed but not linearizability. For more details, see the blog post [Async Commit, the Accelerator for Transaction Commit in TiDB 5.0](https://en.pingcap.com/blog/async-commit-the-accelerator-for-transaction-commit-in-tidb-5-0/).
+- For scenarios that require only causal consistency, you can set this variable to `OFF` to improve performance.
### tidb_hash_exchange_with_new_collation
@@ -2340,9 +2401,10 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `43200`
- Range: `[0, 2147483647]`
-- Unit: seconds
+- Unit: Seconds
- This variable is used to specify the maximum execution time of automatic `ANALYZE` tasks. When the execution time of an automatic `ANALYZE` task exceeds the specified time, the task will be terminated. When the value of this variable is `0`, there is no limit to the maximum execution time of automatic `ANALYZE` tasks.
### tidb_max_chunk_size
@@ -2372,14 +2434,16 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Default value: `50000`
- Range: `[1, 9223372036854775807]`
- Unit: Rows
-- This variable is used to set the maximum number of rows during the coprocessor paging request process. Setting it to too small a value increases the RPC count between TiDB and TiKV, while setting it to too large a value results in excessive memory usage in some cases, such as loading data and full table scan.
+- This variable is used to set the maximum number of rows during the coprocessor paging request process. Setting it to too small a value increases the RPC count between TiDB and TiKV, while setting it to too large a value results in excessive memory usage in some cases, such as loading data and full table scan. The default value of this variable brings better performance in OLTP scenarios than in OLAP scenarios. If the application only uses TiKV as the storage engine, consider increasing the value of this variable when executing OLAP workload queries, which might bring you better performance.
### tidb_max_tiflash_threads New in v6.1.0
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `-1`
- Range: `[-1, 256]`
+- Unit: Threads
- This variable is used to set the maximum concurrency for TiFlash to execute a request. The default value is `-1`, indicating that this system variable is invalid. When the value is `0`, the maximum number of threads is automatically configured by TiFlash.
### tidb_mem_oom_action New in v6.1.0
@@ -2413,7 +2477,9 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `-1`
+- Range: `[-1, 9223372036854775807]`
- Unit: Bytes
- This variable controls the maximum memory usage of TiDB updating statistics. Such a memory usage occurs when you manually execute [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) and when TiDB automatically analyzes tasks in the background. When the total memory usage exceeds this threshold, user-executed `ANALYZE` will exit, and an error message is reported that reminds you to try a lower sampling rate or retry later. If the automatic task in the TiDB background exits because the memory threshold is exceeded, and the sampling rate used is higher than the default value, TiDB will retry the update using the default sampling rate. When this variable value is negative or zero, TiDB does not limit the memory usage of both the manual and automatic update tasks.
@@ -2477,7 +2543,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
### tidb_memory_debug_mode_min_heap_inuse
- Scope: SESSION
-- Type: INT64
+- Type: Integer
- Default value: `0`
- This variable is used for the internal testing of TiDB. It is **NOT recommended** to set this variable. Enabling this variable will affect the performance of TiDB.
- After configuring this parameter, TiDB will enter the memory debug mode to analyze the accuracy of memory tracking. TiDB will frequently trigger GC during the execution of subsequent SQL statements, and compare the actual memory usage and memory statistics. If the current memory usage is greater than `tidb_memory_debug_mode_min_heap_inuse` and the memory statistics error exceeds `tidb_memory_debug_mode_alarm_ratio`, TiDB will output the relevant memory information to the log and file.
@@ -2538,10 +2604,23 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
+- Range: `[1, 256]`
- Default value: `1`
- This variable sets the concurrency of the `MergeJoin` operator when a query is executed.
- It is **NOT recommended** to set this variable. Modifying the value of this variable might cause data correctness issues.
+### tidb_merge_partition_stats_concurrency
+
+> **Warning:**
+>
+> The feature controlled by this variable is not fully functional in the current TiDB version. Do not change the default value.
+
+- Scope: SESSION | GLOBAL
+- Persists to cluster: Yes
+- Default value: `1`
+- This variable specifies the concurrency of merging statistics for a partitioned table when TiDB analyzes the partitioned table.
+
### tidb_metric_query_range_duration New in v4.0
@@ -2584,7 +2663,11 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Default value: `128`
- Range: `[1, 9223372036854775807]`
- Unit: Rows
-- This variable is used to set the minimum number of rows during the coprocessor paging request process. Setting it to too small a value increases the RPC request count between TiDB and TiKV, while setting it to too large a value might cause performance decrease when executing queries using IndexLookup with Limit.
+- This variable is used to set the minimum number of rows during the coprocessor paging request process. Setting it to a too small value increases the RPC request count between TiDB and TiKV, while setting it to a too large value might cause a performance decrease when executing queries using IndexLookup with Limit. The default value of this variable brings better performance in OLTP scenarios than in OLAP scenarios. If the application only uses TiKV as the storage engine, consider increasing the value of this variable when executing OLAP workload queries, which might bring you better performance.
+
+
+
+As shown in this diagram, when [`tidb_enable_paging`](/system-variables.md#tidb_max_paging_size-new-in-v630) is enabled, the performance of TPCH is affected by the settings of `tidb_min_paging_size` and [`tidb_max_paging_size`](/system-variables.md#tidb_max_paging_size-new-in-v630). The vertical axis is the execution time, and it is the smaller the better.
### tidb_mpp_store_fail_ttl
@@ -2625,6 +2708,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
- This variable specifies whether to return an error immediately when the error occurs in a non-transactional DML statement.
- When the value is set to `OFF`, the non-transactional DML statement stops immediately at the first error and returns the error. All the following batches are canceled.
@@ -2798,6 +2882,7 @@ mysql> desc select count(distinct a) from test.t;
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `0`
- Range: `[0, 2147483647]`
- This variable is used to control the selection of the TiDB Join Reorder algorithm. When the number of nodes participating in Join Reorder is greater than this threshold, TiDB selects the greedy algorithm, and when it is less than this threshold, TiDB selects the dynamic programming algorithm.
@@ -2912,7 +2997,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
6 rows in set (0.00 sec)
```
-Enable `tidb_opt_prefix_index_single_scan`：
+Enable `tidb_opt_prefix_index_single_scan`:
```sql
SET tidb_opt_prefix_index_single_scan = 'ON';
@@ -2942,6 +3027,136 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
- Default value: `OFF`
- Specifies whether to allow the optimizer to push `Projection` down to the TiKV or TiFlash coprocessor.
+### tidb_opt_range_max_size New in v6.4.0
+
+- Scope: SESSION | GLOBAL
+- Persists to cluster: Yes
+- Default value: `67108864` (64 MiB)
+- Scope: `[0, 9223372036854775807]`
+- Unit: Bytes
+- This variable is used to set the upper limit of memory usage for the optimizer to build scan ranges. When the variable value is `0`, there is no memory limit for building scan ranges. If building exact scan ranges consumes memory that exceeds the limit, the optimizer uses more relaxed scan ranges (such as `[[NULL,+inf]]`). If the execution plan does not use exact scan ranges, you can increase the value of this variable to let the optimizer build exact scan ranges.
+
+The usage example of this variable is as follows:
+
+
+tidb_opt_range_max_size usage examples
+
+View the default value of this variable. From the result, you can see that the optimizer uses up to 64 MiB of memory to build scan ranges.
+
+```sql
+SELECT @@tidb_opt_range_max_size;
+```
+
+```sql
++----------------------------+
+| @@tidb_opt_range_max_size |
++----------------------------+
+| 67108864 |
++----------------------------+
+1 row in set (0.01 sec)
+```
+
+```sql
+EXPLAIN SELECT * FROM t use index (idx) WHERE a IN (10,20,30) AND b IN (40,50,60);
+```
+
+In the 64 MiB memory upper limit, the optimizer builds the following exact scan ranges `[10 40,10 40], [10 50,10 50], [10 60,10 60], [20 40,20 40], [20 50,20 50], [20 60,20 60], [30 40,30 40], [30 50,30 50], [30 60,30 60]`, as shown in the following execution plan result.
+
+```sql
++-------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++-------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| IndexLookUp_7 | 0.90 | root | | |
+| ├─IndexRangeScan_5(Build) | 0.90 | cop[tikv] | table:t, index:idx(a, b) | range:[10 40,10 40], [10 50,10 50], [10 60,10 60], [20 40,20 40], [20 50,20 50], [20 60,20 60], [30 40,30 40], [30 50,30 50], [30 60,30 60], keep order:false, stats:pseudo |
+| └─TableRowIDScan_6(Probe) | 0.90 | cop[tikv] | table:t | keep order:false, stats:pseudo |
++-------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+3 rows in set (0.00 sec)
+```
+
+Now set the upper limit of memory usage for the optimizer to build scan ranges to 1500 bytes.
+
+```sql
+SET @@tidb_opt_range_max_size = 1500;
+```
+
+```sql
+Query OK, 0 rows affected (0.00 sec)
+```
+
+```sql
+EXPLAIN SELECT * FROM t USE INDEX (idx) WHERE a IN (10,20,30) AND b IN (40,50,60);
+```
+
+In the 1500-byte memory limit, the optimizer builds more relaxed scan ranges `[10,10], [20,20], [30,30]`, and uses a warning to inform the user that the memory usage required to build exact scan ranges exceeds the limit of `tidb_opt_range_max_size`.
+
+```sql
++-------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------+
+| id | estRows | task | access object | operator info |
++-------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------+
+| IndexLookUp_8 | 0.09 | root | | |
+| ├─Selection_7(Build) | 0.09 | cop[tikv] | | in(test.t.b, 40, 50, 60) |
+| │ └─IndexRangeScan_5 | 30.00 | cop[tikv] | table:t, index:idx(a, b) | range:[10,10], [20,20], [30,30], keep order:false, stats:pseudo |
+| └─TableRowIDScan_6(Probe) | 0.09 | cop[tikv] | table:t | keep order:false, stats:pseudo |
++-------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------+
+4 rows in set, 1 warning (0.00 sec)
+```
+
+```sql
+SHOW WARNINGS;
+```
+
+```sql
++---------+------+---------------------------------------------------------------------------------------------------------------------------------------------+
+| Level | Code | Message |
++---------+------+---------------------------------------------------------------------------------------------------------------------------------------------+
+| Warning | 1105 | Memory capacity of 1500 bytes for 'tidb_opt_range_max_size' exceeded when building ranges. Less accurate ranges such as full range are chosen |
++---------+------+---------------------------------------------------------------------------------------------------------------------------------------------+
+1 row in set (0.00 sec)
+```
+
+Then set the upper limit of memory usage to 100 bytes:
+
+```sql
+set @@tidb_opt_range_max_size = 100;
+```
+
+```sql
+Query OK, 0 rows affected (0.00 sec)
+```
+
+```sql
+EXPLAIN SELECT * FROM t USE INDEX (idx) WHERE a IN (10,20,30) AND b IN (40,50,60);
+```
+
+In the 100-byte memory limit, the optimizer chooses `IndexFullScan`, and uses a warning to inform the user that the memory required to build exact scan ranges exceeds the limit of `tidb_opt_range_max_size`.
+
+```sql
++-------------------------------+----------+-----------+--------------------------+----------------------------------------------------+
+| id | estRows | task | access object | operator info |
++-------------------------------+----------+-----------+--------------------------+----------------------------------------------------+
+| IndexLookUp_8 | 8000.00 | root | | |
+| ├─Selection_7(Build) | 8000.00 | cop[tikv] | | in(test.t.a, 10, 20, 30), in(test.t.b, 40, 50, 60) |
+| │ └─IndexFullScan_5 | 10000.00 | cop[tikv] | table:t, index:idx(a, b) | keep order:false, stats:pseudo |
+| └─TableRowIDScan_6(Probe) | 8000.00 | cop[tikv] | table:t | keep order:false, stats:pseudo |
++-------------------------------+----------+-----------+--------------------------+----------------------------------------------------+
+4 rows in set, 1 warning (0.00 sec)
+```
+
+```sql
+SHOW WARNINGS;
+```
+
+```sql
++---------+------+---------------------------------------------------------------------------------------------------------------------------------------------+
+| Level | Code | Message |
++---------+------+---------------------------------------------------------------------------------------------------------------------------------------------+
+| Warning | 1105 | Memory capacity of 100 bytes for 'tidb_opt_range_max_size' exceeded when building ranges. Less accurate ranges such as full range are chosen |
++---------+------+---------------------------------------------------------------------------------------------------------------------------------------------+
+1 row in set (0.00 sec)
+```
+
+
+
### tidb_opt_scan_factor
- Scope: SESSION | GLOBAL
@@ -3001,13 +3216,14 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
- Scope: SESSION
+- Type: Boolean
- Default value: `OFF`
- This variable is used to control whether to allow `INSERT`, `REPLACE`, and `UPDATE` statements to operate on the `_tidb_rowid` column. This variable can be used only when you import data using TiDB tools.
### tidb_optimizer_selectivity_level
- Scope: SESSION
-- Persists to cluster: Yes
+- Type: Integer
- Default value: `0`
- Range: `[0, 2147483647]`
- This variable controls the iteration of the optimizer's estimation logic. After changing the value of this variable, the estimation logic of the optimizer will change greatly. Currently, `0` is the only valid value. It is not recommended to set it to other values.
@@ -3016,7 +3232,9 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Enumeration
- Default value: `dynamic`
+- Possible values: `static`, `dynamic`, `static-only`, `dynamic-only`
- Specifies whether to use `dynamic` or `static` mode for partitioned tables. Note that dynamic partitioning is effective only after full table-level statistics, or GlobalStats, are collected. Before GlobalStats are collected, TiDB will use the `static` mode instead. For detailed information about GlobalStats, see [Collect statistics of partitioned tables in dynamic pruning mode](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode). For details about the dynamic pruning mode, see [Dynamic Pruning Mode for Partitioned Tables](/partitioned-table.md#dynamic-pruning-mode).
### tidb_persist_analyze_options New in v5.4.0
@@ -3127,7 +3345,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
> - This feature is incompatible with [`replica-read`](#tidb_replica_read-new-in-v40). Do not enable `tidb_rc_read_check_ts` and `replica-read` at the same time.
> - If your client uses a cursor, it is not recommended to enable `tidb_rc_read_check_ts` in case that the previous batch of returned data has already been used by the client and the statement eventually fails.
-- Scope: INSTANCE. Since v6.3.0, the scope changes from GLOBAL or SESSION to INSTANCE.
+- Scope: GLOBAL
- Persists to cluster: No, only applicable to the current TiDB instance that you are connecting to.
- Type: Boolean
- Default value: `OFF`
@@ -3142,6 +3360,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Boolean
- Default value: `OFF`
- This variable is used to optimize the acquisition of timestamps and is suitable for scenarios with few point-write conflicts in `READ-COMMITTED` isolation level of pessimistic transactions. Enabling this variable can avoid the latency and overhead brought by obtaining the global timestamps during the execution of point-write statements. Currently, this variable is applicable to three types of point-write statements: `UPDATE`, `DELETE`, and `SELECT ...... FOR UPDATE`. A point-write statement refers to a write statement that uses the primary key or unique key as a filter condition and the final execution operator contains `POINT-GET`.
- If the point-write conflicts are severe, enabling this variable will increase extra overhead and latency, resulting in performance regression. For details, see [Read Committed isolation level](/transaction-isolation-levels.md#read-committed-isolation-level).
@@ -3334,6 +3553,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL;
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `9223372036854775807`
- Range: `[1, 9223372036854775807]`
- This variable controls the maximum number of continuous IDs to be allocated for the [`AUTO_RANDOM`](/auto-random.md) or [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md) attribute. Generally, `AUTO_RANDOM` IDs or the `SHARD_ROW_ID_BITS` annotated row IDs are incremental and continuous in one transaction. You can use this variable to solve the hotspot issue in large transaction scenarios.
@@ -3453,17 +3673,13 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
### tidb_stats_load_sync_wait New in v5.4.0
-> **Warning:**
->
-> Currently, synchronously loading statistics is an experimental feature. It is not recommended that you use it in production environments.
-
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Type: Integer
-- Default value: `0`
+- Default value: `100`
- Range: `[0, 2147483647]`
- Unit: Milliseconds
-- This variable controls whether to enable the synchronously loading statistics feature. The default value `0` means that the feature is disabled. To enable the feature, you can set this variable to a timeout (in milliseconds) that SQL optimization can wait for at most to synchronously load complete column statistics. For details, see [Load statistics](/statistics.md#load-statistics).
+- This variable controls whether to enable the synchronously loading statistics feature. The value `0` means that the feature is disabled. To enable the feature, you can set this variable to a timeout (in milliseconds) that SQL optimization can wait for at most to synchronously load complete column statistics. For details, see [Load statistics](/statistics.md#load-statistics).
### tidb_stmt_summary_history_size New in v4.0
@@ -3523,6 +3739,7 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `1`
- This variable sets the concurrency of the `StreamAgg` operator when queries are executed.
- It is **NOT recommended** to set this variable. Modifying the variable value might cause data correctness issues.
@@ -3635,7 +3852,7 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
### tidb_track_aggregate_memory_usage
-- Scope: SESSION ｜ GLOBAL
+- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Type: Boolean
- Default value: `ON`
@@ -3685,6 +3902,7 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
- Scope: GLOBAL
- Persists to cluster: Yes
+- Type: Integer
- Default value: `16384`
- Range: `[1, 1073741824]`
- Unit: Bytes
@@ -3758,7 +3976,7 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
- Scope: SESSION | GLOBAL
- Default value: `OFF`
-- Range: `ON | OFF`
+- Type: Boolean
@@ -3770,13 +3988,15 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
- Scope: SESSION | GLOBAL
- Default value: `8192`
-- Range: `[1, 18446744073709551616]`
-- When Fine Grained Shuffle is enabled, the window function pushed down to TiFlash can be executed in parallel. This variable controls the batch size of the data sent by the sender. The sender will send data once the cumulative number of rows exceeds this value.
-- Impact on performance: set a reasonable size according to your business requirements. Improper setting affects the performance. If the value is set too small, for example `1`, it causes one network transfer per Block. If the value is set too large, for example, the total number of rows of the table, it causes the receiving end to spend most of the time waiting for data, and the piplelined computation can not work. To set a proper value, you can observe the distribution of the number of rows received by the TiFlash receiver. If most threads receive only a few rows, for example a few hundred, you can increase this value to reduce the network overhead.
+- Range: `[1, 18446744073709551615]`
+- When Fine Grained Shuffle is enabled, the window function pushed down to TiFlash can be executed in parallel. This variable controls the batch size of the data sent by the sender.
+- Impact on performance: set a reasonable size according to your business requirements. Improper setting affects the performance. If the value is set too small, for example `1`, it causes one network transfer per Block. If the value is set too large, for example, the total number of rows of the table, it causes the receiving end to spend most of the time waiting for data, and the piplelined computation cannot work. To set a proper value, you can observe the distribution of the number of rows received by the TiFlash receiver. If most threads receive only a few rows, for example a few hundred, you can increase this value to reduce the network overhead.
### `tiflash_fine_grained_shuffle_stream_count` New in v6.2.0
- Scope: SESSION | GLOBAL
+- Persists to cluster: Yes
+- Type: Integer
- Default value: `0`
- Range: `[-1, 1024]`
- When the window function is pushed down to TiFlash for execution, you can use this variable to control the concurrency level of the window function execution. The possible values are as follows:
@@ -3826,7 +4046,7 @@ Internally, the TiDB parser transforms the `SET TRANSACTION ISOLATION LEVEL [REA
### tx_read_ts
- Scope: SESSION
-- Default value: `0`
+- Default value: ""
- In the Stale Read scenarios, this session variable is used to help record the Stable Read timestamp value.
- This variable is used for the internal operation of TiDB. It is **NOT recommended** to set this variable.
diff --git a/telemetry.md b/telemetry.md
index 3637d6cb31385..c112c1711a0ab 100644
--- a/telemetry.md
+++ b/telemetry.md
@@ -124,11 +124,11 @@ server_configs:
- Deployment in Kubernetes via TiDB Operator
+ Deployment on Kubernetes via TiDB Operator
Configure `spec.tidb.config.enable-telemetry: false` in `tidb-cluster.yaml` or TidbCluster Custom Resource.
-See [Deploy TiDB Operator in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tidb-operator) for details.
+See [Deploy TiDB Operator on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tidb-operator) for details.
> **Note:**
>
@@ -214,11 +214,11 @@ server_configs:
- Deployment in Kubernetes via TiDB Operator
+ Deployment on Kubernetes via TiDB Operator
Configure `spec.pd.config.dashboard.enable-telemetry: false` in `tidb-cluster.yaml` or TidbCluster Custom Resource.
-See [Deploy TiDB Operator in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tidb-operator) for details.
+See [Deploy TiDB Operator on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tidb-operator) for details.
> **Note:**
>
diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md
index 37d6fd7147abe..74f002550cf41 100644
--- a/ticdc/ticdc-avro-protocol.md
+++ b/ticdc/ticdc-avro-protocol.md
@@ -9,7 +9,7 @@ Avro is a data exchange format protocol defined by [Apache Avro™](https://avro
## Use Avro
-When using Message Queue (MQ) as a downstream sink, you can specify Avro in `sink-uri`. TiCDC captures TiDB DML events, creates Avro messages from these events, and sends the messages downstream. When Avro detects a schema change, it registers the latest schema with Schema Registry.
+When using Message Queue (MQ) as a downstream sink, you can specify Avro in `sink-uri`. TiCDC captures TiDB DML events, creates Avro messages from these events, and sends the messages downstream. When Avro detects a schema change, it registers the latest schema with Schema Registry.
The following is a configuration example using Avro:
diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md
index 9ca334f7a8568..741a023c5af8b 100644
--- a/ticdc/ticdc-overview.md
+++ b/ticdc/ticdc-overview.md
@@ -1,12 +1,12 @@
---
title: TiCDC Overview
-summary: Learn what TiCDC is, what features TiCDC provides, etc.
+summary: Learn what TiCDC is, what features TiCDC provides, and how to install and deploy TiCDC.
aliases: ['/docs/dev/ticdc/ticdc-overview/','/docs/dev/reference/tools/ticdc/overview/']
---
# TiCDC Overview
-[TiCDC](https://github.com/pingcap/tiflow/tree/master/cdc) is a tool used for replicating incremental data of TiDB. Specifically, TiCDC pulls TiKV change logs, sorts captured data, and exports row-based incremental data to downstream databases.
+[TiCDC](https://github.com/pingcap/tiflow/tree/master/cdc) is a tool used for replicating incremental data of TiDB. Specifically, TiCDC pulls TiKV change logs, sorts captured data, and exports row-based incremental data to downstream databases.
## Usage scenarios
diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md
index 30da8f4ac3f6e..f242a6ed070a7 100644
--- a/tidb-cloud/backup-and-restore.md
+++ b/tidb-cloud/backup-and-restore.md
@@ -32,7 +32,7 @@ By the automatic backup, you can back up the cluster data every day at the backu
If you do not specify a preferred backup time, TiDB Cloud assigns a default backup time, which is 2:00 AM in the time zone of the region where the cluster is located.
-Note that you can not disable automatic backup.
+Note that you cannot disable automatic backup.
### Manual backup
diff --git a/tidb-cloud/built-in-monitoring.md b/tidb-cloud/built-in-monitoring.md
index b48224344343c..8ae7221d6109f 100644
--- a/tidb-cloud/built-in-monitoring.md
+++ b/tidb-cloud/built-in-monitoring.md
@@ -29,7 +29,7 @@ The following sections illustrate the metrics on the Monitoring page.
| :------------| :------| :-------------------------------------------- |
| Database Time by SQL types | database time, {SQL type} | database time: total database time per second.
{SQL type}: database time consumed by SQL statements per second, which are collected by SQL types, such as `SELECT`, `INSERT`, and `UPDATE`. |
| Database Time by SQL Phase | database time, get token, parse, compile, execute | Database time consumed in four SQL processing phases: get token, parse, compile, and execute. The SQL execution phase is in green and other phases are in red on general. If non-green areas take a large proportion, it means most database time is consumed by other phases than the execution phase and further cause analysis is required. |
-| SQL Execute Time Overview | tso_wait, Get, Cop, Commit, etc. | Green metrics stand for common KV write requests (such as prewrite and commit), blue metrics stand for common read requests, and metrics in other colors stand for unexpected situations which you need to pay attention to. For example, pessimistic lock KV requests are marked red and TSO waiting is marked dark brown. If non-blue or non-green areas take a large proportion, it means there is a bottleneck during SQL execution. For example, if serious lock conflicts occur, the red area will take a large proportion. If excessive time is consumed in waiting TSO, the dark brown area will take a large proportion. |
+| SQL Execute Time Overview | tso_wait, Get, Cop, and Commit | Green metrics stand for common KV write requests (such as prewrite and commit), blue metrics stand for common read requests, and metrics in other colors stand for unexpected situations which you need to pay attention to. For example, pessimistic lock KV requests are marked red and TSO waiting is marked dark brown. If non-blue or non-green areas take a large proportion, it means there is a bottleneck during SQL execution. For example, if serious lock conflicts occur, the red area will take a large proportion. If excessive time is consumed in waiting TSO, the dark brown area will take a large proportion. |
### Application Connection
@@ -44,7 +44,7 @@ The following sections illustrate the metrics on the Monitoring page.
| :------------| :------| :-------------------------------------------- |
| Query Per Second | {SQL type} | The number of SQL statements executed per second in all TiDB instances, which are collected by SQL types, such as `SELECT`, `INSERT`, and `UPDATE`. |
| Failed Queries | Error types | The statistics of error types (such as syntax errors and primary key conflicts) according to the SQL statement execution errors per minute on each TiDB instance. It contains the module in which an error occurs and the error code. |
-| Command Per Second | Query, StmtExecute, StmtPrepare, etc. | The number of commands processed by all TiDB instances per second based on command types. |
+| Command Per Second | Query, StmtExecute, and StmtPrepare | The number of commands processed by all TiDB instances per second based on command types. |
| Queries Using Plan Cache OPS | hit, miss | hit: the number of queries using plan cache per second in all TiDB instances.
miss: the number of queries missing plan cache per second in all TiDB instances. |
### Latency Break Down
@@ -69,8 +69,8 @@ The following sections illustrate the metrics on the Monitoring page.
| Metric name | Labels | Description |
| :------------| :------| :-------------------------------------------- |
-| Avg TiDB KV Request Duration | Get, Prewirite, Commit, PessimisticLock, etc. | The average time consumed in executing KV requests in all TiDB instances based on request types, including `Get`, `Prewrite`, and `Commit`. |
-| Avg TiKV GRPC Duration | kv_get, kv_prewirite, kv_commit, kv_pessimisticLock, etc. | The average time consumed in executing gRPC requests in all TiKV instances based request types, including `kv_get`, `kv_prewrite`, and `kv_commit`. |
+| Avg TiDB KV Request Duration | Get, Prewirite, Commit, and PessimisticLock | The average time consumed in executing KV requests in all TiDB instances based on request types, including `Get`, `Prewrite`, and `Commit`. |
+| Avg TiKV GRPC Duration | kv_get, kv_prewirite, kv_commit, and kv_pessimisticLock | The average time consumed in executing gRPC requests in all TiKV instances based request types, including `kv_get`, `kv_prewrite`, and `kv_commit`. |
| Average / P99 PD TSO Wait/RPC Duration | wait-avg/99, rpc-avg/99 | Wait: the average time or P99 duration in waiting for PD to return TSO in all TiDB instances.
RPC: the average time or P99 duration from sending TSO requests to PD to receiving TSO in all TiDB instances. |
| Average / P99 Storage Async Write Duration | avg, 99 | The average time or P99 duration consumed in asynchronous writing. Average storage async write duration = Average store duration + Average apply duration. |
| Average / P99 Store Duration | avg, 99 | The average time or P99 duration consumed in storing loop during asynchronously writing. |
diff --git a/tidb-cloud/changefeed-replication.md b/tidb-cloud/changefeed-replication.md
index d77f8fa0ff856..b3930ffd8bc4d 100644
--- a/tidb-cloud/changefeed-replication.md
+++ b/tidb-cloud/changefeed-replication.md
@@ -68,7 +68,7 @@ After **Planned Detach** is finished, the original primary cluster is set as rea
To recover from an unplanned outage, use **Force Detach**. In the event of a catastrophic failure in the region where the primary cluster is located, you should use **Force Detach** so that the secondary cluster can serve the business as quickly as possible, ensuring business continuity. Because this operation makes the secondary cluster serve as an individual cluster immediately and does not wait for any unreplicated data, the RPO depends on the Primary-Secondary replication lag, while the RTO depends on how quickly **Force Detach** is triggered by you.
-**Force Detach** detaches the secondary cluster from the primary cluster into an individual cluster. When **Force Detach** is triggered, it performs the following steps：
+**Force Detach** detaches the secondary cluster from the primary cluster into an individual cluster. When **Force Detach** is triggered, it performs the following steps:
1. Stops data replication from the primary to the secondary cluster immediately.
2. Sets the original secondary cluster as writable so that it can start serving your workload.
diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md
index 1286756744648..7f21d66f6eac5 100644
--- a/tidb-cloud/import-csv-files.md
+++ b/tidb-cloud/import-csv-files.md
@@ -1,5 +1,5 @@
---
-title: Import CSV Files from Amazon S3 or GCS into TiDB Cloud
+title: Import CSV Files from Amazon S3 or GCS into TiDB Cloud
summary: Learn how to import CSV files from Amazon S3 or GCS into TiDB Cloud.
---
diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md
index 5a781c0129041..965f35f581914 100644
--- a/tidb-cloud/import-parquet-files.md
+++ b/tidb-cloud/import-parquet-files.md
@@ -1,5 +1,5 @@
---
-title: Import Apache Parquet Files from Amazon S3 or GCS into TiDB Cloud
+title: Import Apache Parquet Files from Amazon S3 or GCS into TiDB Cloud
summary: Learn how to import Apache Parquet files from Amazon S3 or GCS into TiDB Cloud.
---
diff --git a/tidb-cloud/integrate-tidbcloud-with-vercel.md b/tidb-cloud/integrate-tidbcloud-with-vercel.md
index 4052fbe691652..f5d8266c60fe5 100644
--- a/tidb-cloud/integrate-tidbcloud-with-vercel.md
+++ b/tidb-cloud/integrate-tidbcloud-with-vercel.md
@@ -37,7 +37,7 @@ One TiDB Cloud cluster can connect to multiple Vercel projects.
### All IP addresses allowed for traffic filter in TiDB Cloud
-Make sure that the traffic filter of your TiDB Cloud cluster allows all IP addresses (set to `0.0.0.0/0`) for connection, this is because Vercel deployments use [dynamic IP addresses](https://vercel.com/guides/how-to-allowlist-deployment-ip-address). If you use the TiDB Cloud Vercel integration, TiDB Cloud automatically adds a `0.0.0.0/0` traffic filter to your cluster in the integration workflow if there is none.
+Make sure that the traffic filter of your TiDB Cloud cluster allows all IP addresses (set to `0.0.0.0/0`) for connection, this is because Vercel deployments use [dynamic IP addresses](https://vercel.com/guides/how-to-allowlist-deployment-ip-address). If you use the TiDB Cloud Vercel integration, TiDB Cloud automatically adds a `0.0.0.0/0` traffic filter to your cluster in the integration workflow if there is none.
## Connect via the TiDB Cloud Vercel integration
diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md
index 2c8b525461a83..4dcef2025dc27 100644
--- a/tidb-cloud/monitor-built-in-alerting.md
+++ b/tidb-cloud/monitor-built-in-alerting.md
@@ -50,9 +50,9 @@ The following table provides the TiDB Cloud built-in alert conditions and the co
| Total TiDB node CPU utilization exceeded 80% for 10 minutes | Total TiDB node CPU utilization of cluster ABC in project XYZ has exceeded 80% for 10 minutes. If you expect this to continue, it is recommended that you add additional TiDB nodes. To monitor node CPU utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
| Total TiKV node CPU utilization exceeded 80% for 10 minutes | Total TiKV node CPU utilization of cluster ABC in project XYZ has exceeded 80% for 10 minutes. If you expect this to continue, it is recommended that you add additional TiKV nodes. To monitor node CPU utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
| Total TiFlash node CPU utilization exceeded 80% for 10 minutes | Total TiFlash node CPU utilization of cluster ABC in project XYZ has exceeded 80% for 10 minutes. If you expect this to continue, it is recommended that you add additional TiFlash nodes. To monitor node CPU utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
-|`*` TiKV storage utilization exceeds 80% | Total TiKV storage utilization of cluster ABC in project XYZ exceeds 80%. It is recommended that you add additional TiKV nodes to increase your storage capacity. To monitor storage utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
-|`*` TiFlash storage utilization exceeds 80% | Total TiFlash storage utilization of cluster ABC in project XYZ exceeds 80%. It is recommended that you add additional TiFlash nodes to increase your storage capacity. To monitor storage utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
-| Cluster nodes are offline | Some or all nodes in cluster ABC in project XYZ are offline. The TiDB Cloud Operations team is aware and working to resolve the issue. Refer to [TiDB Cloud Status](https://status.tidbcloud.com/) for the latest information. To monitor node status, see [Cluster status and node status](/tidb-cloud/monitor-tidb-cluster.md#cluster-status-and-node-status). |
+|`*` TiKV storage utilization exceeds 80% | Total TiKV storage utilization of cluster ABC in project XYZ exceeds 80%. It is recommended that you add additional TiKV nodes to increase your storage capacity. To monitor storage utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
+|`*` TiFlash storage utilization exceeds 80% | Total TiFlash storage utilization of cluster ABC in project XYZ exceeds 80%. It is recommended that you add additional TiFlash nodes to increase your storage capacity. To monitor storage utilization, see [Monitoring metrics](/tidb-cloud/monitor-tidb-cluster.md#monitoring-metrics). |
+| Cluster nodes are offline | Some or all nodes in cluster ABC in project XYZ are offline. The TiDB Cloud Operations team is aware and working to resolve the issue. Refer to [TiDB Cloud Status](https://status.tidbcloud.com/) for the latest information. To monitor node status, see [Cluster status and node status](/tidb-cloud/monitor-tidb-cluster.md#cluster-status-and-node-status). |
> **Note:**
>
diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md
index b83f9fe7e172e..860a321528f6d 100644
--- a/tidb-cloud/tidb-cloud-auditing.md
+++ b/tidb-cloud/tidb-cloud-auditing.md
@@ -7,10 +7,6 @@ summary: Learn about how to audit a cluster in TiDB Cloud.
TiDB Cloud provides you with a database audit logging feature to record a history of user access details (such as any SQL statements executed) in logs.
-> **Note:**
->
-> Currently, the **audit logging** feature is experimental. The interface and output are subject to change.
-
To assess the effectiveness of user access policies and other information security measures of your organization, it is a security best practice to conduct a periodic analysis of the database audit logs.
The audit logging feature is disabled by default. To audit a cluster, you need to enable the audit logging first, and then specify the auditing filter rules.
@@ -21,7 +17,7 @@ The audit logging feature is disabled by default. To audit a cluster, you need t
## Prerequisites
-- You are using a TiDB Cloud Dedicated tier. Audit logging is not available for TiDB Cloud Serverless Tier clusters.
+- You are using a TiDB Cloud Dedicated Tier cluster. Audit logging is not available for TiDB Cloud Serverless Tier clusters.
- You are the audit administrator of your organization in TiDB Cloud. Otherwise, you cannot see the audit-related options in the TiDB Cloud console. For more information, see [Configure member roles](/tidb-cloud/manage-user-access.md#configure-member-roles).
## Enable audit logging for AWS or GCP
@@ -47,18 +43,16 @@ For more information, see [Creating a bucket](https://docs.aws.amazon.com/Amazon
1. Get the TiDB Cloud account ID and the External ID of the TiDB cluster that you want to enable audit logging.
1. In the TiDB Cloud console, choose a project and a cluster deployed on AWS.
- 2. Select **Settings** > **Audit Settings**. The **Audit Logging** dialog box is displayed.
- 3. In the **Audit Logging** dialog box, click **Show AWS IAM policy settings**. The corresponding TiDB Cloud Account ID and TiDB Cloud External ID of the TiDB cluster are displayed.
+ 2. Select **Settings** > **Audit Settings**. The **Audit Logging** dialog is displayed.
+ 3. In the **Audit Logging** dialog, click **Show AWS IAM policy settings**. The corresponding TiDB Cloud Account ID and TiDB Cloud External ID of the TiDB cluster are displayed.
4. Record the TiDB Cloud Account ID and the External ID for later use.
-2. In the AWS Management console, go to **IAM** > **Access Management** > **Policies**, and then check whether a storage bucket policy with the `s3:PutObject` write-only permission exists.
+2. In the AWS Management console, go to **IAM** > **Access Management** > **Policies**, and then check whether there is a storage bucket policy with the `s3:PutObject` write-only permission.
- If yes, record the matched storage bucket policy for later use.
- If not, go to **IAM** > **Access Management** > **Policies** > **Create Policy**, and define a bucket policy according to the following policy template.
- {{< copyable "" >}}
-
- ```
+ ```json
{
"Version": "2012-10-17",
"Statement": [
@@ -71,7 +65,7 @@ For more information, see [Creating a bucket](https://docs.aws.amazon.com/Amazon
}
```
- In the template, `` is the Amazon Resource Name (ARN) of your S3 bucket where the audit log files are to be written. You can go to the **Properties** tab in your S3 bucket and get the Amazon Resource Name (ARN) value in the **Bucket Overview** area. In the `"Resource"` field, you need to add `/*` after the ARN. For example, if the ARN is `arn:aws:s3:::tidb-cloud-test`, you need to configure the value of the `"Resource"` field as `"arn:aws:s3:::tidb-cloud-test/*"`.
+ In the template, `` is the Amazon Resource Name (ARN) of your S3 bucket where the audit log files are to be written. You can go to the **Properties** tab in your S3 bucket and get the ARN value in the **Bucket Overview** area. In the `"Resource"` field, you need to add `/*` after the ARN. For example, if the ARN is `arn:aws:s3:::tidb-cloud-test`, you need to configure the value of the `"Resource"` field as `"arn:aws:s3:::tidb-cloud-test/*"`.
3. Go to **IAM** > **Access Management** > **Roles**, and then check whether a role whose trust entity corresponds to the TiDB Cloud Account ID and the External ID that you recorded earlier already exists.
@@ -148,7 +142,7 @@ For more information, see [Creating storage buckets](https://cloud.google.com/st
#### Step 3. Enable audit logging
-In the TiDB Cloud console, go back to the **Audit Logging** dialog box where you got the TiDB Cloud account ID，and then take the following steps:
+In the TiDB Cloud console, go back to the **Audit Logging** dialog box where you got the TiDB Cloud account ID, and then take the following steps:
1. In the **Bucket URI** field, enter your full GCS bucket name.
2. In the **Bucket Region** field, select the GCS region where the bucket locates.
@@ -189,6 +183,10 @@ For example, `13796619446086334065/tidb-0/tidb-audit-2022-04-21T18-16-29.529.log
If you no longer want to audit a cluster, go to the page of the cluster, click **Settings** > **Audit Settings**, and then toggle the audit setting in the upper-right corner to **Off**.
+> **Note:**
+>
+> Each time the size of the log file reaches 10 MiB, the log file will be pushed to the cloud storage bucket. Therefore, after the audit log is disabled, the log file whose size is smaller than 10 MiB will not be automatically pushed to the cloud storage bucket. To get the log file in this situation, contact [PingCAP support](/tidb-cloud/tidb-cloud-support.md).
+
## Audit log fields
For each database event record in audit logs, TiDB provides the following fields:
diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md
index 8b42badc203e3..a7351f782d39c 100644
--- a/tidb-cloud/tidb-cloud-faq.md
+++ b/tidb-cloud/tidb-cloud-faq.md
@@ -63,7 +63,7 @@ The best way to learn about TiDB Cloud is to follow our step-by-step tutorial. C
### There are different components in my TiDB cluster. What are PD, TiDB, TiKV, and TiFlash nodes?
-PD, the Placement Driver is “the brain” of the entire TiDB cluster, as it stores the metadata of the cluster. It sends data scheduling commands to specific TiKV nodes according to the data distribution state reported by TiKV nodes in real-time.
+PD, the Placement Driver is "the brain" of the entire TiDB cluster, as it stores the metadata of the cluster. It sends data scheduling commands to specific TiKV nodes according to the data distribution state reported by TiKV nodes in real-time.
TiDB is the SQL computing layer that aggregates data from queries returned from TiKV or TiFlash stores. TiDB is horizontally scalable; increasing the number of TiDB nodes will increase the number of concurrent queries the cluster can handle.
@@ -73,7 +73,7 @@ TiFlash is the analytical storage that replicates data from the transactional st
### How does TiDB replicate data between the TiKV nodes?
-TiKV divides the key-value space into key ranges, and each key range is treated as a “Region”. In TiKV, data is distributed among all nodes in a cluster and uses the Region as the basic unit. PD is responsible for spreading (scheduling) Regions as evenly as possible across all nodes in a cluster.
+TiKV divides the key-value space into key ranges, and each key range is treated as a "Region". In TiKV, data is distributed among all nodes in a cluster and uses the Region as the basic unit. PD is responsible for spreading (scheduling) Regions as evenly as possible across all nodes in a cluster.
TiDB uses the Raft consensus algorithm to replicate data by Regions. Multiple replicas of a Region stored in different nodes form a Raft Group.
diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md
index 5d1b3c0ac30f4..935aeff148c71 100644
--- a/tidb-cloud/tidb-cloud-glossary.md
+++ b/tidb-cloud/tidb-cloud-glossary.md
@@ -71,7 +71,7 @@ Based on the projects created by the organization, resources such as personnel,
### project members
-Project members are users who are invited to join one or more projects of the organization. Project members can manage clusters, network access, backups, etc.
+Project members are users who are invited to join one or more projects of the organization. Project members can manage clusters, network access, backups, and other resources.
## R
diff --git a/tidb-cloud/tidb-cloud-intro.md b/tidb-cloud/tidb-cloud-intro.md
index b9c79a2ebef15..9b6fe74a3190b 100644
--- a/tidb-cloud/tidb-cloud-intro.md
+++ b/tidb-cloud/tidb-cloud-intro.md
@@ -66,7 +66,7 @@ With TiDB Cloud, you can get the following key features:
- TiDB VPC (Virtual Private Cloud)
- For each TiDB Cloud cluster, all TiDB nodes and auxiliary nodes, including TiDB Operator nodes, logging nodes, and so on, are deployed in an independent VPC.
+ For each TiDB Cloud cluster, all TiDB nodes and auxiliary nodes, including TiDB Operator nodes and logging nodes, are deployed in an independent VPC.
- TiDB Cloud Central Services
diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md
index 87e324967ed37..ed89cc161ee93 100644
--- a/tidb-cloud/tidb-cloud-poc.md
+++ b/tidb-cloud/tidb-cloud-poc.md
@@ -195,7 +195,7 @@ Any feedback to our support team is highly appreciated by filling in the [TiDB C
TiDB Cloud provides two types of database backup: automatic backup and manual backup. Both methods back up the full database.
-The time it takes to back up and restore data might vary, depending on the number of tables, the number of mirror copies, the CPU-intensive level, and so on. The backup and restoring rate in one single TiKV node is approximately 50 MB/s.
+The time it takes to back up and restore data might vary, depending on the number of tables, the number of mirror copies, and the CPU-intensive level. The backup and restoring rate in one single TiKV node is approximately 50 MB/s.
Database backup and restore operations are typically CPU-intensive, and always require additional CPU resources. They might have an impact (10% to 50%) on QPS and transaction latency, depending on how CPU-intensive this environment is.
diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md
index d44304f7f1804..6cb7f49bae769 100644
--- a/tidb-cloud/tidb-cloud-tune-performance-overview.md
+++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md
@@ -44,7 +44,7 @@ For example, for a database system running OLTP loads, after its CPU utilization
There are several pages on the TiDB Cloud console that help you troubleshoot user response time.
-- **Overview**: on this tab, you can view TiDB metrics such as total QPS, latency, connections, request QPS, request duration, storage size, CPU, IO Read, and IO Write.
+- **Overview**: on this tab, you can view TiDB metrics such as total QPS, latency, connections, request QPS, request duration, storage size, CPU, IO Read, and IO Write.
- **Diagnosis**:
- **Statement** enables you to directly observe SQL execution on the page, and easily locate performance problems without querying the system tables. You can click a SQL statement to further view the execution plan of the query for troubleshooting and analysis. For more information about SQL performance tuning, see [SQL Tuning Overview](/tidb-cloud/tidb-cloud-sql-tuning-overview.md).
diff --git a/tidb-computing.md b/tidb-computing.md
index 829beaccaa675..f401b0d22747b 100644
--- a/tidb-computing.md
+++ b/tidb-computing.md
@@ -125,7 +125,7 @@ The simplest solution to SQL computing is the [mapping of table data to Key-Valu
For example, to execute the `select count(*) from user where name = "TiDB"` SQL statement, TiDB needs to read all data in the table, then checks whether the `name` field is `TiDB`, and if so, returns this row. The process is as follows:
-1. Construct the Key Range: all `RowID` in a table are in `[0, MaxInt64)` range. According to the row data `Key` encoding rule, using `0` and `MaxInt64` can construct a `[StartKey, EndKey)` range that is left-closed and right-open.
+1. Construct the Key Range: all `RowID` in a table are in `[0, MaxInt64)` range. According to the row data `Key` encoding rule, using `0` and `MaxInt64` can construct a `[StartKey, EndKey)` range that is left-closed and right-open.
2. Scan Key Range: read the data in TiKV according to the key range constructed above.
3. Filter data: for each row of data read, calculate the `name = "TiDB"` expression. If the result is `true`, return to this row. If not, skip this row.
4. Calculate `Count(*)`: for each row that meets the requirements, add up to the result of `Count(*)`.
diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md
index 501b452dc2c4a..287d4b98b02d9 100644
--- a/tidb-configuration-file.md
+++ b/tidb-configuration-file.md
@@ -47,7 +47,7 @@ The TiDB configuration file supports more options than command-line parameters.
> Since v6.3.0, this configuration item is deprecated and superseded by the system variable [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom). When the TiDB cluster is upgraded to v6.3.0 or a later version, it will automatically initialize the variable with the value of `oom-use-tmp-storage`. After that, changing the value of `oom-use-tmp-storage` **does not** take effect anymore.
+ Controls whether to enable the temporary storage for some operators when a single SQL statement exceeds the memory quota specified by the system variable [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query).
-+ Default value: `true`
++ Default value: `true`
### `tmp-storage-path`
@@ -721,6 +721,11 @@ For pessimistic transaction usage, refer to [TiDB Pessimistic Transaction Mode](
+ For scenarios with no conflicts, if there are many auto-commit transactions (the specific number is determined by the real scenarios. For example, the number of auto-commit transactions accounts for more than half of the total number of applications), and a single transaction operates a large data volume, enabling this configuration causes performance regression. For example, the auto-commit `INSERT INTO SELECT` statement.
+ Default value: `false`
+### constraint-check-in-place-pessimistic New in v6.4.0
+
++ Controls the default value of the system variable [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630).
++ Default value: `true`
+
## isolation-read
Configuration items related to read isolation.
diff --git a/tidb-in-kubernetes.md b/tidb-in-kubernetes.md
index b1e2f4c726f06..f85259fb9bd09 100644
--- a/tidb-in-kubernetes.md
+++ b/tidb-in-kubernetes.md
@@ -1,11 +1,11 @@
---
-title: Deploy a TiDB Cluster in Kubernetes
-summary: Learn how to deploy a TiDB cluster in Kubernetes.
+title: Deploy a TiDB Cluster on Kubernetes
+summary: Learn how to deploy a TiDB cluster on Kubernetes.
aliases: ['/docs/tidb-in-kubernetes/dev/']
---
-# Deploy a TiDB Cluster in Kubernetes
+# Deploy a TiDB Cluster on Kubernetes
-You can use [TiDB Operator](https://github.com/pingcap/tidb-operator) to deploy TiDB clusters in Kubernetes. TiDB Operator is an automatic operation system for TiDB clusters in Kubernetes. It provides full life-cycle management for TiDB including deployment, upgrades, scaling, backup, fail-over, and configuration changes. With TiDB Operator, TiDB can run seamlessly in the Kubernetes clusters deployed on a public or private cloud.
+You can use [TiDB Operator](https://github.com/pingcap/tidb-operator) to deploy TiDB clusters on Kubernetes. TiDB Operator is an automatic operation system for TiDB clusters on Kubernetes. It provides full life-cycle management for TiDB including deployment, upgrades, scaling, backup, fail-over, and configuration changes. With TiDB Operator, TiDB can run seamlessly in the Kubernetes clusters deployed on a public or private cloud.
-Currently, the TiDB in Kubernetes documentation is independent of the TiDB documentation. For detailed steps on how to deploy TiDB clusters in Kubernetes using TiDB Operator, see [TiDB in Kubernetes documentation](https://docs.pingcap.com/tidb-in-kubernetes/stable/).
+Currently, the TiDB on Kubernetes documentation is independent of the TiDB documentation. For detailed steps on how to deploy TiDB clusters on Kubernetes using TiDB Operator, see [TiDB on Kubernetes documentation](https://docs.pingcap.com/tidb-in-kubernetes/stable/).
diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md
index 91f4bf7669f9c..536f1a233e461 100644
--- a/tidb-lightning/monitor-tidb-lightning.md
+++ b/tidb-lightning/monitor-tidb-lightning.md
@@ -145,16 +145,16 @@ Metrics provided by `tikv-importer` are listed under the namespace `tikv_import_
Bucketed histogram for the duration of an RPC action. Labels:
- **request**: what kind of RPC is executed
- * `switch_mode` — switched a TiKV node to import/normal mode
- * `open_engine` — opened an engine file
- * `write_engine` — received data and written into an engine
- * `close_engine` — closed an engine file
- * `import_engine` — imported an engine file into the TiKV cluster
- * `cleanup_engine` — deleted an engine file
- * `compact_cluster` — explicitly compacted the TiKV cluster
- * `upload` — uploaded an SST file
- * `ingest` — ingested an SST file
- * `compact` — explicitly compacted a TiKV node
+ * `switch_mode`: switched a TiKV node to import/normal mode
+ * `open_engine`: opened an engine file
+ * `write_engine`: received data and written into an engine
+ * `close_engine`: closed an engine file
+ * `import_engine`: imported an engine file into the TiKV cluster
+ * `cleanup_engine`: deleted an engine file
+ * `compact_cluster`: explicitly compacted the TiKV cluster
+ * `upload`: uploaded an SST file
+ * `ingest`: ingested an SST file
+ * `compact`: explicitly compacted a TiKV node
- **result**: the execution result of the RPC
* `ok`
* `error`
@@ -232,11 +232,11 @@ Metrics provided by `tidb-lightning` are listed under the namespace `lightning_*
Counts idle workers. Labels:
- **name**:
- * `table` — the remainder of `table-concurrency`, normally 0 until the end of the process
- * `index` — the remainder of `index-concurrency`, normally 0 until the end of the process
- * `region` — the remainder of `region-concurrency`, normally 0 until the end of the process
- * `io` — the remainder of `io-concurrency`, normally close to configured value (default 5), and close to 0 means the disk is too slow
- * `closed-engine` — number of engines which have been closed but not yet cleaned up, normally close to index + table-concurrency (default 8). A value close to 0 means TiDB Lightning is faster than TiKV Importer, which might cause TiDB Lightning to stall
+ * `table`: the remainder of `table-concurrency`, normally 0 until the end of the process
+ * `index`: the remainder of `index-concurrency`, normally 0 until the end of the process
+ * `region`: the remainder of `region-concurrency`, normally 0 until the end of the process
+ * `io`: the remainder of `io-concurrency`, normally close to configured value (default 5), and close to 0 means the disk is too slow
+ * `closed-engine`: number of engines which have been closed but not yet cleaned up, normally close to index + table-concurrency (default 8). A value close to 0 means TiDB Lightning is faster than TiKV Importer, which might cause TiDB Lightning to stall
- **`lightning_kv_encoder`** (Counter)
@@ -251,42 +251,42 @@ Metrics provided by `tidb-lightning` are listed under the namespace `lightning_*
Counts processed tables and their statuses. Labels:
- **state**: the status of the table, indicating which phase should be completed
- * `pending` — not yet processed
- * `written` — all data encoded and sent
- * `closed` — all corresponding engine files closed
- * `imported` — all engine files have been imported into the target cluster
- * `altered_auto_inc` — AUTO_INCREMENT ID altered
- * `checksum` — checksum performed
- * `analyzed` — statistics analysis performed
- * `completed` — the table has been fully imported and verified
+ * `pending`: not yet processed
+ * `written`: all data encoded and sent
+ * `closed`: all corresponding engine files closed
+ * `imported`: all engine files have been imported into the target cluster
+ * `altered_auto_inc`: AUTO_INCREMENT ID altered
+ * `checksum`: checksum performed
+ * `analyzed`: statistics analysis performed
+ * `completed`: the table has been fully imported and verified
- **result**: the result of the current phase
- * `success` — the phase completed successfully
- * `failure` — the phase failed (did not complete)
+ * `success`: the phase completed successfully
+ * `failure`: the phase failed (did not complete)
* **`lightning_engines`** (Counter)
Counts number of engine files processed and their status. Labels:
- **state**: the status of the engine, indicating which phase should be completed
- * `pending` — not yet processed
- * `written` — all data encoded and sent
- * `closed` — engine file closed
- * `imported` — the engine file has been imported into the target cluster
- * `completed` — the engine has been fully imported
+ * `pending`: not yet processed
+ * `written`: all data encoded and sent
+ * `closed`: engine file closed
+ * `imported`: the engine file has been imported into the target cluster
+ * `completed`: the engine has been fully imported
- **result**: the result of the current phase
- * `success` — the phase completed successfully
- * `failure` — the phase failed (did not complete)
+ * `success`: the phase completed successfully
+ * `failure`: the phase failed (did not complete)
- **`lightning_chunks`** (Counter)
Counts number of chunks processed and their status. Labels:
- **state**: a chunk's status, indicating which phase the chunk is in
- * `estimated` — (not a state) this value gives total number of chunks in current task
- * `pending` — loaded but not yet processed
- * `running` — data are being encoded and sent
- * `finished` — the entire chunk has been processed
- * `failed` — errors happened during processing
+ * `estimated`: (not a state) this value gives total number of chunks in current task
+ * `pending`: loaded but not yet processed
+ * `running`: data are being encoded and sent
+ * `finished`: the entire chunk has been processed
+ * `failed`: errors happened during processing
- **`lightning_import_seconds`** (Histogram)
diff --git a/tidb-lightning/tidb-lightning-requirements.md b/tidb-lightning/tidb-lightning-requirements.md
index 6eb723c35d020..c7897a9794aba 100644
--- a/tidb-lightning/tidb-lightning-requirements.md
+++ b/tidb-lightning/tidb-lightning-requirements.md
@@ -39,7 +39,7 @@ Based on the import mode and features enabled, the target database users should
|
- | Physical Import Mode |
+ Physical Import Mode |
mysql.tidb |
SELECT |
|
diff --git a/tidb-operator-overview.md b/tidb-operator-overview.md
index c763a7bc05cc5..e03a0119e2c6b 100644
--- a/tidb-operator-overview.md
+++ b/tidb-operator-overview.md
@@ -1,13 +1,13 @@
---
title: TiDB Operator
-summary: Learn about TiDB Operator, the automatic operation system for TiDB clusters in Kubernetes.
+summary: Learn about TiDB Operator, the automatic operation system for TiDB clusters on Kubernetes.
aliases: ['/docs/tidb-in-kubernetes/dev/']
---
# TiDB Operator
-[TiDB Operator](https://github.com/pingcap/tidb-operator) is an automatic operation system for TiDB clusters in Kubernetes. It provides full life-cycle management for TiDB including deployment, upgrades, scaling, backup, fail-over, and configuration changes. With TiDB Operator, TiDB can run seamlessly in the Kubernetes clusters deployed on a public or private cloud.
+[TiDB Operator](https://github.com/pingcap/tidb-operator) is an automatic operation system for TiDB clusters on Kubernetes. It provides full life-cycle management for TiDB including deployment, upgrades, scaling, backup, fail-over, and configuration changes. With TiDB Operator, TiDB can run seamlessly in the Kubernetes clusters deployed on a public or private cloud.
-Currently, the TiDB Operator documentation (also named as TiDB in Kubernetes documentation) is independent of the TiDB documentation. To access the documentation, click the following link:
+Currently, the TiDB Operator documentation (also named as TiDB on Kubernetes documentation) is independent of the TiDB documentation. To access the documentation, click the following link:
-- [TiDB in Kubernetes documentation](https://docs.pingcap.com/tidb-in-kubernetes/stable/)
+- [TiDB on Kubernetes documentation](https://docs.pingcap.com/tidb-in-kubernetes/stable/)
diff --git a/tidb-scheduling.md b/tidb-scheduling.md
index 27a0eb12d3510..2cfe2a43fa0e3 100644
--- a/tidb-scheduling.md
+++ b/tidb-scheduling.md
@@ -19,11 +19,11 @@ Now consider about the following situations:
* When a TiKV store fails, PD needs to consider:
* Recovery time of the failed store.
* If it's short (for example, the service is restarted), whether scheduling is necessary or not.
- * If it's long (for example, disk fault, data is lost, etc.), how to do scheduling.
+ * If it's long (for example, disk fault and data is lost), how to do scheduling.
* Replicas of all Regions.
* If the number of replicas is not enough for some Regions, PD needs to complete them.
* If the number of replicas is more than expected (for example, the failed store re-joins into the cluster after recovery), PD needs to delete them.
-* Read/Write operations are performed on leaders, which can not be distributed only on a few individual stores;
+* Read/Write operations are performed on leaders, which cannot be distributed only on a few individual stores;
* Not all Regions are hot, so loads of all TiKV stores need to be balanced;
* When Regions are in balancing, data transferring utilizes much network/disk traffic and CPU time, which can influence online services.
diff --git a/tidb-storage.md b/tidb-storage.md
index 7fe7876fe9c60..8cb3213c4d1cd 100644
--- a/tidb-storage.md
+++ b/tidb-storage.md
@@ -33,7 +33,7 @@ A simple way is to replicate data to multiple machines, so that even if one mach
Raft is a consensus algorithm. This document only briefly introduces Raft. For more details, you can see [In Search of an Understandable Consensus Algorithm](https://raft.github.io/raft.pdf). The Raft has several important features:
- Leader election
-- Membership changes (such as adding replicas, deleting replicas, transferring leaders, and so on)
+- Membership changes (such as adding replicas, deleting replicas, and transferring leaders)
- Log replication
TiKV use Raft to perform data replication. Each data change will be recorded as a Raft log. Through Raft log replication, data is safely and reliably replicated to multiple nodes of the Raft group. However, according to Raft protocol, successful writes only need that data is replicated to the majority of nodes.
diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md
index 7a1ee94e36988..44ec29c96302f 100644
--- a/tidb-troubleshooting-map.md
+++ b/tidb-troubleshooting-map.md
@@ -52,7 +52,7 @@ Refer to [5 PD issues](#5-pd-issues).
### 3.1 DDL
-- 3.1.1 An error `ERROR 1105 (HY000): unsupported modify decimal column precision` is reported when you modify the length of the `decimal` field. TiDB does not support changing the length of the `decimal` field.
+- 3.1.1 An error `ERROR 1105 (HY000): unsupported modify decimal column precision` is reported when you modify the length of the `decimal` field. TiDB does not support changing the length of the `decimal` field.
- 3.1.2 TiDB DDL job hangs or executes slowly (use `admin show ddl jobs` to check DDL progress)
@@ -186,7 +186,7 @@ For more information about troubleshooting OOM, see [Troubleshoot TiDB OOM Issue
This issue is expected. You can restore the Region using `tikv-ctl`.
-- 4.1.2 If TiKV is deployed on a virtual machine, when the virtual machine is killed or the physical machine is powered off, the `entries[X, Y] is unavailable from storage` error is reported.
+- 4.1.2 If TiKV is deployed on a virtual machine, when the virtual machine is killed or the physical machine is powered off, the `entries[X, Y] is unavailable from storage` error is reported.
This issue is expected. The `fsync` of virtual machines is not reliable, so you need to restore the Region using `tikv-ctl`.
@@ -453,14 +453,14 @@ Check the specific cause for busy by viewing the monitor **Grafana** -> **TiKV**
- 6.2.3 A replication task is interrupted with the `driver: bad connection` error returned.
- - The `driver: bad connection` error indicates that an anomaly has occurred in the connection between DM and the downstream TiDB database (such as network failure, TiDB restart and so on), and that the data of the current request has not yet been sent to TiDB.
+ - The `driver: bad connection` error indicates that an anomaly has occurred in the connection between DM and the downstream TiDB database (such as network failure and TiDB restart), and that the data of the current request has not yet been sent to TiDB.
- For versions earlier than DM 1.0.0 GA, stop the task by running `stop-task` and then restart the task by running `start-task`.
- For DM 1.0.0 GA or later versions, an automatic retry mechanism for this type of error is added. See [#265](https://github.com/pingcap/dm/pull/265).
- 6.2.4 A replication task is interrupted with the `invalid connection` error.
- - The `invalid connection` error indicates that an anomaly has occurred in the connection between DM and the downstream TiDB database (such as network failure, TiDB restart, TiKV busy and so on), and that a part of the data for the current request has been sent to TiDB. Because DM has the feature of concurrently replicating data to the downstream in replication tasks, several errors might occur when a task is interrupted. You can check these errors by running `query-status` or `query-error`.
+ - The `invalid connection` error indicates that an anomaly has occurred in the connection between DM and the downstream TiDB database (such as network failure, TiDB restart, and TiKV busy), and that a part of the data for the current request has been sent to TiDB. Because DM has the feature of concurrently replicating data to the downstream in replication tasks, several errors might occur when a task is interrupted. You can check these errors by running `query-status` or `query-error`.
- If only the `invalid connection` error occurs during the incremental replication process, DM retries the task automatically.
- If DM does not retry or fails to retry automatically because of version problems (automatic retry is introduced in v1.0.0-rc.1), use `stop-task` to stop the task and then use `start-task` to restart the task.
@@ -599,7 +599,7 @@ Check the specific cause for busy by viewing the monitor **Grafana** -> **TiKV**
This transaction commit is too slow, causing it to be rolled back by other transactions after Time To Live (TTL). This transaction will automatically retry, so the business is usually not affected. For a transaction with a size of 0.25 MB or smaller, the default TTL is 3 seconds.
-- 7.2.4 `PessimisticLockNotFound`.
+- 7.2.4 `PessimisticLockNotFound`.
Similar to `TxnLockNotFound`. The pessimistic transaction commit is too slow and thus rolled back by other transactions.
diff --git a/tiflash-620-upgrade-guide.md b/tiflash-620-upgrade-guide.md
index a54a56aded56a..0d831b2a866b1 100644
--- a/tiflash-620-upgrade-guide.md
+++ b/tiflash-620-upgrade-guide.md
@@ -10,7 +10,7 @@ This document describes the functional changes in TiFlash modules you need to pa
To learn the standard upgrade process, see the following documents:
- [Upgrade TiDB Using TiUP](/upgrade-tidb-using-tiup.md)
-- [Upgrade TiDB in Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster)
+- [Upgrade TiDB on Kubernetes](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster)
> **Note:**
>
diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md
index 51bde81db8100..f1cdb07cf1eb1 100644
--- a/tiflash/monitor-tiflash.md
+++ b/tiflash/monitor-tiflash.md
@@ -10,7 +10,7 @@ This document describes the monitoring items of TiFlash.
If you use TiUP to deploy the TiDB cluster, the monitoring system (Prometheus & Grafana) is deployed at the same time. For more information, see [Overview of the Monitoring Framework](/tidb-monitoring-framework.md).
-The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, Node\_exporter, and so on. A lot of metrics are there to help you diagnose.
+The Grafana dashboard is divided into a series of sub dashboards which include Overview, PD, TiDB, TiKV, and Node\_exporter. A lot of metrics are there to help you diagnose.
TiFlash has three dashboard panels: **TiFlash-Summary**, **TiFlash-Proxy-Summary**, and **TiFlash-Proxy-Details**. The metrics on these panels indicate the current status of TiFlash. The **TiFlash-Proxy-Summary** and **TiFlash-Proxy-Details** panels mainly show the information of the Raft layer and the metrics are detailed in [Key Monitoring Metrics of TiKV](/grafana-tikv-dashboard.md).
diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md
index 95fcbe9b7ec07..00a27cbbce6f2 100644
--- a/tiflash/troubleshoot-tiflash.md
+++ b/tiflash/troubleshoot-tiflash.md
@@ -12,9 +12,9 @@ This section describes some commonly encountered issues when using TiFlash, the
The issue might occur due to different reasons. It is recommended that you troubleshoot it following the steps below:
-1. Check whether your system is CentOS8.
+1. Check whether your system is RedHat Enterprise Linux 8.
- CentOS8 does not have the `libnsl.so` system library. You can manually install it via the following command:
+ RedHat Enterprise Linux 8 does not have the `libnsl.so` system library. You can manually install it via the following command:
{{< copyable "shell-regular" >}}
@@ -252,4 +252,4 @@ The causes may vary. You can address the problem by performing the following ste
- `Write Stall Duration`: `TiFlash-summary` > `Storage Write Stall` > `Write Stall Duration`
- `generate snapshot CPU`: `TiFlash-Proxy-Details` > `Thread CPU` > `Region task worker pre-handle/generate snapshot CPU`
- Based on your service priorities, adjust the load accordingly to achieve optimal performance.
\ No newline at end of file
+ Based on your service priorities, adjust the load accordingly to achieve optimal performance.
diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md
index 47899a719a4b1..095027997b144 100644
--- a/tikv-configuration-file.md
+++ b/tikv-configuration-file.md
@@ -414,20 +414,21 @@ Configuration items related to storage.
### `api-version` New in v6.1.0
-+ The storage format and interface version used by TiKV when TiKV serves as the raw key-value store.
++ The storage format and interface version used by TiKV when TiKV serves as the RawKV store.
+ Value options:
+ `1`: Uses API V1, does not encode the data passed from the client, and stores data as it is. In versions earlier than v6.1.0, TiKV uses API V1 by default.
+ `2`: Uses API V2:
- + The data is stored in the MVCC (Multi-Version Concurrency Control) format, where the timestamp is obtained from PD (which is TSO) by tikv-server.
+ + The data is stored in the Multi-Version Concurrency Control (MVCC) format, where the timestamp is obtained from PD (which is TSO) by tikv-server.
+ + Data is scoped according to different usage and API V2 supports co-existence of TiDB, Transactional KV, and RawKV applications in a single cluster.
+ When API V2 is used, you are expected to set `storage.enable-ttl = true` at the same time. Because API V2 supports the TTL feature, you must turn on `enable-ttl` explicitly. Otherwise, it will be in conflict because `storage.enable-ttl` defaults to `false`.
- + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim expired data. Note that this tidb-server instance cannot provide read or write services. To ensure high availability, you can deploy multiple tidb-server instances.
+ + When API V2 is enabled, you need to deploy at least one tidb-server instance to reclaim obsolete data. This tidb-server instance can provide read and write services at the same time. To ensure high availability, you can deploy multiple tidb-server instances.
+ Client support is required for API V2. For details, see the corresponding instruction of the client for the API V2.
- + Since v6.2.0, Change Data Capture (CDC) for RawKV is supported using the component [TiKV-CDC](https://github.com/tikv/migration/tree/main/cdc).
+ + Since v6.2.0, Change Data Capture (CDC) for RawKV is supported. Please refer to [RawKV CDC](https://tikv.org/docs/dev/concepts/explore-tikv-features/cdc/).
+ Default value: `1`
> **Warning:**
-> - You can set the value of `api-version` to `2` **only when** deploying a new TiKV cluster. **Do not** modify the value of this configuration item in an existing TiKV cluster. TiKV clusters with different `api-version` values use different data formats. Therefore, if you modify the value of this item in an existing TiKV cluster, the cluster will store data in different formats and causes data corruption. It will raise the "unable to switch storage.api_version" error when you start the TiKV cluster.
+> - API V1 and API V2 are different from each other in the storage format. You can enable or disable API V2 directly **only** when TiKV contains only TiDB data. In other scenarios, you need to deploy a new cluster, and migrate data using [RawKV Backup & Restore](https://tikv.org/docs/dev/concepts/explore-tikv-features/backup-restore/).
> - After API V2 is enabled, you **cannot** downgrade the TiKV cluster to a version earlier than v6.1.0. Otherwise, data corruption might occur.
## storage.block-cache
@@ -1875,4 +1876,4 @@ To reduce write latency, TiKV periodically fetches and caches a batch of timesta
+ The maximum number of TSOs in a timestamp request.
+ In a default TSO physical time update interval (`50ms`), PD provides at most 262144 TSOs. When requested TSOs exceed this number, PD provides no more TSOs. This configuration item is used to avoid exhausting TSOs and the reverse impact of TSO exhaustion on other businesses. If you increase the value of this configuration item to improve high availability, you need to decrease the value of [`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval) at the same time to get enough TSOs.
-+ Default value: `8192`
\ No newline at end of file
++ Default value: `8192`
diff --git a/tikv-control.md b/tikv-control.md
index 8a89ffcf54023..736c17350c6f4 100644
--- a/tikv-control.md
+++ b/tikv-control.md
@@ -348,9 +348,9 @@ If the command is successfully executed, it prints the above information. If the
### Modify the TiKV configuration dynamically
-You can use the `modify-tikv-config` command to dynamically modify the configuration arguments. Currently, the TiKV configuration items that can be dynamically modified and the detailed modification are consistent with modifying configuration using SQL statements. For details, see [Modify TiKV configuration online](/dynamic-config.md#modify-tikv-configuration-online).
+You can use the `modify-tikv-config` command to dynamically modify the configuration arguments. Currently, the TiKV configuration items that can be dynamically modified and the detailed modification are consistent with modifying configuration using SQL statements. For details, see [Modify TiKV configuration dynamically](/dynamic-config.md#modify-tikv-configuration-dynamically).
-- `-n` is used to specify the full name of the configuration item. For the list of configuration items that can be modified online, see [Modify TiKV configuration online](/dynamic-config.md#modify-tikv-configuration-online).
+- `-n` is used to specify the full name of the configuration item. For the list of configuration items that can be modified dynamically, see [Modify TiKV configuration dynamically](/dynamic-config.md#modify-tikv-configuration-dynamically).
- `-v` is used to specify the configuration value.
Set the size of `shared block cache`:
diff --git a/tiup/customized-montior-in-tiup-environment.md b/tiup/customized-montior-in-tiup-environment.md
index 3b1a38dad37ab..c2f90850f9412 100644
--- a/tiup/customized-montior-in-tiup-environment.md
+++ b/tiup/customized-montior-in-tiup-environment.md
@@ -100,7 +100,7 @@ After the preceding configuration is done, when you deploy, scale out, scale in,
2. Add other configuration items in the `grafana_servers` configuration.
- The following is a configuration example of the `[log.file] level` and `smtp` fields in the topology.yaml file:
+ The following is a configuration example of the `[log.file] level` and `smtp` fields in the topology.yaml file:
```
# # Server configs are used to specify the configuration of Grafana Servers.
diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md
index cf6406d7dac9f..284ba5197500c 100644
--- a/tiup/tiup-component-cluster-scale-in.md
+++ b/tiup/tiup-component-cluster-scale-in.md
@@ -10,7 +10,7 @@ The `tiup cluster scale-in` command is used to scale in the cluster, which takes
Because the TiKV, TiFlash, and TiDB Binlog components are taken offline asynchronously (which requires TiUP to remove the node through API first) and the stopping process takes a long time (which requires TiUP to continuously check whether the node is successfully taken offline), the TiKV, TiFlash, and TiDB Binlog components are handled particularly as follows:
-- For TiKV, TiFlash and, TiDB Binlog components:
+- For TiKV, TiFlash, and TiDB Binlog components:
1. TiUP Cluster takes the node offline through API and directly exits without waiting for the process to be completed.
2. To check the status of the nodes being scaled in, you need to execute the `tiup cluster display` command and wait for the status to become `Tombstone`.
diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md
index c462f8a05b51f..997750736894a 100644
--- a/troubleshoot-high-disk-io.md
+++ b/troubleshoot-high-disk-io.md
@@ -73,8 +73,8 @@ In addition, some other panel metrics might help you determine whether the bottl
It might be that too many level-0 SST files cause the write stall. To address the issue, you can add the `[rocksdb] max-sub-compactions = 2 (or 3)` parameter to speed up the compaction of level-0 SST files. This parameter means that the compaction tasks of level-0 to level-1 can be divided into `max-sub-compactions` subtasks for multi-threaded concurrent execution.
If the disk's I/O capability fails to keep up with the write, it is recommended to scale up the disk. If the throughput of the disk reaches the upper limit (for example, the throughput of SATA SSD is much lower than that of NVMe SSD), which results in write stall, but the CPU resource is relatively sufficient, you can try to use a compression algorithm of higher compression ratio to relieve the pressure on the disk, that is, use CPU resources to make up for disk resources.
-
- For example, when the pressure of `default cf compaction` is relatively high, you can change the parameter`[rocksdb.defaultcf] compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd" , "zstd"]` to `compression-per-level = ["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]`.
+
+ For example, when the pressure of `default cf compaction` is relatively high, you can change the parameter`[rocksdb.defaultcf] compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd" , "zstd"]` to `compression-per-level = ["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]`.
### I/O issues found in alerts
diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md
index cd0fb48caf790..26863393c4ca0 100644
--- a/troubleshoot-lock-conflicts.md
+++ b/troubleshoot-lock-conflicts.md
@@ -175,7 +175,7 @@ You can detect the read-write conflict in your TiDB cluster by the following way
* Monitoring data through Grafana
- On the `KV Errors` panel in the TiDB dashboard, there are two monitoring metrics `Lock Resolve OPS` and `KV Backoff OPS` which can be used to check read-write conflicts in the transactions. If the values of both `not_expired` and `resolve` under `Lock Resolve OPS` increase, there might be many read-write conflicts. The `not_expired` item means that the transaction's lock has not timed out. The `resolve` item means that the other transaction tries to clean up the locks. If the value of another `txnLockFast` item under `KV Backoff OPS` increases, there might also be read-write conflicts.
+ In the `KV Errors` panel in the TiDB dashboard, `not_expired`/`resolve` in `Lock Resolve OPS` and `tikvLockFast` in `KV Backoff OPS` are monitoring metrics that can be used to check read-write conflicts in transactions. If the values of all the metrics increase, there might be many read-write conflicts. The `not_expired` item means that the transaction's lock has not timed out. The `resolve` item means that the other transaction tries to clean up the locks. The `tikvLockFast` item means that read-write conflicts occur.
@@ -323,7 +323,7 @@ Solutions:
### TTL manager has timed out
-The transaction execution time can not exceed the GC time limit. In addition, the TTL time of pessimistic transactions has an upper limit, whose default value is 1 hour. Therefore, a pessimistic transaction executed for more than 1 hour will fail to commit. This timeout threshold is controlled by the TiDB parameter [performance.max-txn-ttl](https://github.com/pingcap/tidb/blob/master/config/config.toml.example).
+The transaction execution time cannot exceed the GC time limit. In addition, the TTL time of pessimistic transactions has an upper limit, whose default value is 1 hour. Therefore, a pessimistic transaction executed for more than 1 hour will fail to commit. This timeout threshold is controlled by the TiDB parameter [performance.max-txn-ttl](https://github.com/pingcap/tidb/blob/master/config/config.toml.example).
When the execution time of a pessimistic transaction exceeds the TTL time, the following error message occurs in the TiDB log:
diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md
index ec35dca70fc3f..1dd132220650c 100644
--- a/troubleshoot-write-conflicts.md
+++ b/troubleshoot-write-conflicts.md
@@ -89,4 +89,4 @@ You can use `indexID` and the table name to find the name of the related index:
SELECT * FROM INFORMATION_SCHEMA.TIDB_INDEXES WHERE TABLE_SCHEMA='{db_name}' AND TABLE_NAME='{table_name}' AND INDEX_ID={indexID};
```
-In addition, in TiDB v3.0.8 and later versions, the pessimistic transaction becomes the default mode. The pessimistic transaction mode can avoid write conflicts during the transaction prewrite stage, so you do not need to modify the application any more. In the pessimistic transaction mode, each DML statement writes a pessimistic lock to the related keys during execution. This pessimistic lock can prevent other transactions from modifying the same keys, thus ensuring no write conflicts exist in the `prewrite` stage of the transaction 2PC.
+In addition, in TiDB v3.0.8 and later versions, the pessimistic transaction becomes the default mode. The pessimistic transaction mode can avoid write conflicts during the transaction prewrite stage, so you do not need to modify the application any more. In the pessimistic transaction mode, each DML statement writes a pessimistic lock to the related keys during execution. This pessimistic lock can prevent other transactions from modifying the same keys, thus ensuring no write conflicts exist in the `prewrite` stage of the transaction 2PC.
diff --git a/tune-tikv-memory-performance.md b/tune-tikv-memory-performance.md
index af2b07bb04e6a..3fdf8010e6a44 100644
--- a/tune-tikv-memory-performance.md
+++ b/tune-tikv-memory-performance.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/tune-tikv-performance/','/docs/dev/reference/performance/tu
# Tune TiKV Memory Parameter Performance
-This document describes how to tune the TiKV parameters for optimal performance. You can find the default configuration file in [etc/config-template.toml](https://github.com/tikv/tikv/blob/master/etc/config-template.toml). To modify the configuration, you can [use TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration) or [modify TiKV online](/dynamic-config.md#modify-tikv-configuration-online) for a limited set of configuration items. For the complete configuration, see [TiKV configuration file](/tikv-configuration-file.md).
+This document describes how to tune the TiKV parameters for optimal performance. You can find the default configuration file in [etc/config-template.toml](https://github.com/tikv/tikv/blob/master/etc/config-template.toml). To modify the configuration, you can [use TiUP](/maintain-tidb-using-tiup.md#modify-the-configuration) or [modify TiKV dynamically](/dynamic-config.md#modify-tikv-configuration-dynamically) for a limited set of configuration items. For the complete configuration, see [TiKV configuration file](/tikv-configuration-file.md).
TiKV uses RocksDB for persistent storage at the bottom level of the TiKV architecture. Therefore, many of the performance parameters are related to RocksDB. TiKV uses two RocksDB instances: the default RocksDB instance stores KV data, the Raft RocksDB instance (RaftDB) stores Raft logs.
diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md
index a5d50fff944a3..c95c6b2885e79 100644
--- a/upgrade-tidb-using-tiup.md
+++ b/upgrade-tidb-using-tiup.md
@@ -16,7 +16,7 @@ This document is targeted for the following upgrade paths:
> **Warning:**
>
-> - You cannot upgrade TiFlash online from versions earlier than 5.3 to 5.3 or later. Instead, you must first stop all the TiFlash instances of the early version, and then upgrade the cluster offline. If other components (such as TiDB and TiKV) do not support an online upgrade, follow the instructions in warnings in [Online upgrade](#online-upgrade).
+> - You cannot upgrade TiFlash online from versions earlier than 5.3 to 5.3 or later. Instead, you must first stop all the TiFlash instances of the early version, and then upgrade the cluster offline. If other components (such as TiDB and TiKV) do not support an online upgrade, follow the instructions in warnings in [Online upgrade](#online-upgrade).
> - **DO NOT** upgrade a TiDB cluster when a DDL statement is being executed in the cluster (usually for the time-consuming DDL statements such as `ADD INDEX` and the column type changes).
> - Before the upgrade, it is recommended to use the [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md) command to check whether the TiDB cluster has an ongoing DDL job. If the cluster has a DDL job, to upgrade the cluster, wait until the DDL execution is finished or use the [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md) command to cancel the DDL job before you upgrade the cluster.
> - In addition, during the cluster upgrade, **DO NOT** execute any DDL statement. Otherwise, the issue of undefined behavior might occur.