From b0ae70dcc00b1510009ad7934d4fa61c7d8c5fae Mon Sep 17 00:00:00 2001 From: ti-srebot <66930949+ti-srebot@users.noreply.github.com> Date: Fri, 26 Mar 2021 13:37:23 +0800 Subject: [PATCH] hide the config global-kill (#5075) (#5126) --- explain-joins.md | 2 +- explain-subqueries.md | 73 +++++++++++++++------------- optimizer-hints.md | 4 -- sql-statements/sql-statement-kill.md | 30 ------------ tidb-configuration-file.md | 7 +-- 5 files changed, 40 insertions(+), 76 deletions(-) diff --git a/explain-joins.md b/explain-joins.md index f37fe4ce95255..a50a7b01992dd 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -180,7 +180,7 @@ Query OK, 0 rows affected (3.65 sec) ### Variations of Index Join -An index join operation using the hint [`INL_JOIN`](/optimizer-hints.md#inl_joint1_name--tl_name-) creates a hash table of the intermediate results before joining on the outer table. TiDB also supports creating a hash table on the outer table using the hint [`INL_HASH_JOIN`](/optimizer-hints.md#inl_hash_join). If the column sets on the inner table match the columns of the outer table, the [`INL_MERGE_JOIN`](/optimizer-hints.md#inl_merge_join) index join can apply. Each of these variations of index join is automatically selected by the SQL Optimizer. +An index join operation using the hint [`INL_JOIN`](/optimizer-hints.md#inl_joint1_name--tl_name-) creates a hash table of the intermediate results before joining on the outer table. TiDB also supports creating a hash table on the outer table using the hint [`INL_HASH_JOIN`](/optimizer-hints.md#inl_hash_join). Each of these variations of index join is automatically selected by the SQL Optimizer. ### Configuration diff --git a/explain-subqueries.md b/explain-subqueries.md index 9c01ca8a3954c..35780dacfc2e9 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -54,21 +54,22 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); ``` ```sql -+--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------+ -| id | estRows | task | access object | operator info | -+--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------+ -| IndexMergeJoin_19 | 45.00 | root | | inner join, inner:TableReader_14, outer key:test.t2.t1_id, inner key:test.t1.id | -| ├─HashAgg_38(Build) | 45.00 | root | | group by:test.t2.t1_id, funcs:firstrow(test.t2.t1_id)->test.t2.t1_id | -| │ └─IndexReader_39 | 45.00 | root | | index:HashAgg_31 | -| │ └─HashAgg_31 | 45.00 | cop[tikv] | | group by:test.t2.t1_id, | -| │ └─IndexFullScan_37 | 90000.00 | cop[tikv] | table:t2, index:t1_id(t1_id) | keep order:false | -| └─TableReader_14(Probe) | 1.00 | root | | data:TableRangeScan_13 | -| └─TableRangeScan_13 | 1.00 | cop[tikv] | table:t1 | range: decided by [test.t2.t1_id], keep order:true | -+--------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------+ -7 rows in set (0.00 sec) ++----------------------------------+----------+-----------+------------------------------+---------------------------------------------------------------------------------------------------------------------------+ +| 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) ``` -The result above shows that TiDB performs an index join operation (merge variant) that starts by reading the index on `t2.t1_id`. The values of `t1_id` are deduplicated inside TiKV first as a part of the `└─HashAgg_31` operator task, and then deduplicated again in TiDB as a part of the `├─HashAgg_38(Build)` operator task. The deduplication is performed by the aggregation function `firstrow(test.t2.t1_id)`. The result is then joined against the `t1` table's `PRIMARY KEY`. +The result above shows that TiDB performs an index join operation that starts by reading the index on `t2.t1_id`. The values of `t1_id` are deduplicated inside TiKV first as a part of the `└─HashAgg_31` operator task, and then deduplicated again in TiDB as a part of the `├─HashAgg_38(Build)` operator task. The deduplication is performed by the aggregation function `firstrow(test.t2.t1_id)`. The result is then joined against the `t1` table's `PRIMARY KEY`. ## Inner join (unique subquery) @@ -79,23 +80,24 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t3); ``` ```sql -+-----------------------------+---------+-----------+------------------------------+---------------------------------------------------------------------------------+ -| id | estRows | task | access object | operator info | -+-----------------------------+---------+-----------+------------------------------+---------------------------------------------------------------------------------+ -| IndexMergeJoin_20 | 999.00 | root | | inner join, inner:TableReader_15, outer key:test.t3.t1_id, inner key:test.t1.id | -| ├─IndexReader_39(Build) | 999.00 | root | | index:IndexFullScan_38 | -| │ └─IndexFullScan_38 | 999.00 | cop[tikv] | table:t3, index:t1_id(t1_id) | keep order:false | -| └─TableReader_15(Probe) | 1.00 | root | | data:TableRangeScan_14 | -| └─TableRangeScan_14 | 1.00 | cop[tikv] | table:t1 | range: decided by [test.t3.t1_id], keep order:true | -+-----------------------------+---------+-----------+------------------------------+---------------------------------------------------------------------------------+ -5 rows in set (0.00 sec) ++----------------------------------+---------+-----------+-----------------------------+---------------------------------------------------------------------------------------------------------------------------+ +| 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) ``` Semantically because `t3.t1_id` is guaranteed unique, it can be executed directly as an `INNER JOIN`. ## Semi join (correlated subquery) -In the previous two examples, TiDB is able to perform an `INNER JOIN` operation after the data inside the subquery is made unique (via `HashAgg`) or guaranteed unique. Both joins are performed using an Index Join (merge variant). +In the previous two examples, TiDB is able to perform an `INNER JOIN` operation after the data inside the subquery is made unique (via `HashAgg`) or guaranteed unique. Both joins are performed using an Index Join. In this example, TiDB chooses a different execution plan: @@ -104,17 +106,18 @@ 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 | ++----------------------------------+---------+-----------+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------+ +| IndexJoin_14 | 1582.40 | root | | anti semi join, inner:IndexLookUp_13, outer key:test.t3.t1_id, inner key:test.t1.id, equal cond:eq(test.t3.t1_id, test.t1.id) | +| ├─TableReader_35(Build) | 1978.00 | root | | data:TableFullScan_34 | +| │ └─TableFullScan_34 | 1978.00 | cop[tikv] | table:t3 | keep order:false | +| └─IndexLookUp_13(Probe) | 1.00 | root | | | +| ├─IndexRangeScan_10(Build) | 1.00 | cop[tikv] | table:t1, index:PRIMARY(id) | range: decided by [eq(test.t1.id, test.t3.t1_id)], keep order:false | +| └─Selection_12(Probe) | 1.00 | cop[tikv] | | lt(test.t1.int_col, 100) | +| └─TableRowIDScan_11 | 1.00 | cop[tikv] | table:t1 | keep order:false | ++----------------------------------+---------+-----------+-----------------------------+-------------------------------------------------------------------------------------------------------------------------------+ +7 rows in set (0.00 sec) ``` 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. diff --git a/optimizer-hints.md b/optimizer-hints.md index 598433dfc44d5..6be6193e01655 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -118,10 +118,6 @@ The parameter(s) given in `INL_JOIN()` is the candidate table for the inner tabl The `INL_HASH_JOIN(t1_name [, tl_name])` hint tells the optimizer to use the index nested loop hash join algorithm. The conditions for using this algorithm are the same with the conditions for using the index nested loop join algorithm. The difference between the two algorithms is that `INL_JOIN` creates a hash table on the joined inner table, but `INL_HASH_JOIN` creates a hash table on the joined outer table. `INL_HASH_JOIN` has a fixed limit on memory usage, while the memory used by `INL_JOIN` depends on the number of rows matched in the inner table. -### INL_MERGE_JOIN - -The `INL_MERGE_JOIN(t1_name [, tl_name])` hint tells the optimizer to use the index nested loop merge join algorithm. This hint is used in the same scenario as in that of `INL_JOIN`. Compared with `INL_JOIN` and `INL_HASH_JOIN`, it saves more memory but requires more strict usage conditions: the column sets of the inner table in join keys is the prefix of the inner table index, or the index of the inner table is the prefix of the column sets of the inner table in join keys. - ### HASH_JOIN(t1_name [, tl_name ...]) The `HASH_JOIN(t1_name [, tl_name ...])` hint tells the optimizer to use the hash join algorithm for the given table(s). This algorithm allows the query to be executed concurrently with multiple threads, which achieves a higher processing speed but consumes more memory. For example: diff --git a/sql-statements/sql-statement-kill.md b/sql-statements/sql-statement-kill.md index 1ab52a6d71099..ee2ee7f4d477a 100644 --- a/sql-statements/sql-statement-kill.md +++ b/sql-statements/sql-statement-kill.md @@ -38,36 +38,6 @@ Query OK, 0 rows affected (0.00 sec) * By design, this statement is not compatible with MySQL by default. This helps prevent against a case of a connection being terminated on the wrong TiDB server, because it is common to place multiple TiDB servers behind a load balancer. * The `KILL TIDB` statement is a TiDB extension. If you are certain that the session you are attempting to kill is on the same TiDB server, set [`compatible-kill-query = true`](/tidb-configuration-file.md#compatible-kill-query) in your configuration file. -## Global kill New in v5.0.0-rc - -Since v5.0, TiDB provides experimental support for [Global kill](https://github.com/pingcap/tidb/blob/master/docs/design/2020-06-01-global-kill.md). This feature is used to safely terminate any connection between the client and the TiDB server. When this feature is enabled, each TiDB server ensures that each connection ID is globally unique. The client can issue a `KILL` statement to any TiDB server, and the server internally routes the request to the corresponding TiDB instance. This ensures that `KILL` is safe to execute even when the TiDB server is behind a load balancer. - -To enable Global Kill, set `enable-global-kill = true` in the `experimental` section of the [TiDB configuration file](/tidb-configuration-file.md#enable-global-kill-new-in-v500-rc). - -## Global kill example - -Execute the following statement on the TiDB instance `127.0.0.1:10180`: - -```sql -SELECT SLEEP(60); -``` - -Execute the following statements on the TiDB instance `127.0.0.1:10080`: - -```sql -SELECT * FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST; -+-----------------+---------------------+------+-----------+--------------------+---------+------+------------+------------------------------------------------------+------------------------------------------------------------------+------+----------------------------------------+ -| INSTANCE | ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | DIGEST | MEM | TxnStart | -+-----------------+---------------------+------+-----------+--------------------+---------+------+------------+------------------------------------------------------+------------------------------------------------------------------+------+----------------------------------------+ -| 127.0.0.1:10180 | 8824324082762776581 | root | 127.0.0.1 | test | Query | 2 | autocommit | SELECT SLEEP(60) | b4dae6a771c1d84157dcc302bef38cbff77a7a8ff89ee38302ac3324485454a3 | 0 | | -| 127.0.0.1:10080 | 98041252825530373 | root | 127.0.0.1 | information_schema | Query | 0 | autocommit | SELECT * FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST | 43113c6fe27fb20eae4a6dc8c43f176f9292fd873dd08f1041debdff6d335cb0 | 0 | 01-15 23:13:20.609(422241527558045697) | -+-----------------+---------------------+------+-----------+--------------------+---------+------+------------+------------------------------------------------------+------------------------------------------------------------------+------+----------------------------------------+ -2 rows in set (0.07 sec) - -KILL 8824324082762776581; -Query OK, 0 rows affected (0.00 sec) -``` - ## See also * [SHOW \[FULL\] PROCESSLIST](/sql-statements/sql-statement-show-processlist.md) diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index b719610fded41..f5ed3e365093f 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -602,9 +602,4 @@ The `experimental` section, introduced in v3.1.0, describes configurations relat ### `allow-expression-index` New in v4.0.0 - Determines whether to create the expression index. -- Default value: `false` - -### `enable-global-kill` New in v5.0.0-rc - -- Determines whether to enable the Global Kill feature. To enable this feature, set the value of this configuration item to `true`. When enabled, this feature can safely kill any connection even when the TiDB server is behind a load balancer. -- Default value: `false` +- Default value: `false` \ No newline at end of file