You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: sql-plan-management.md
+13-13
Original file line number
Diff line number
Diff line change
@@ -231,25 +231,25 @@ The original SQL statement and the bound statement must have the same text after
231
231
232
232
#### Create a binding according to a historical execution plan
233
233
234
-
To make the execution plan of a SQL statement fixed to a historical execution plan, you can use `plan_digest`to bind that historical execution plan to the SQL statement, which is more convenient than binding it according to a SQL statement.
234
+
To make the execution plan of a SQL statement fixed to a historical execution plan, you can use Plan Digest to bind that historical execution plan to the SQL statement, which is more convenient than binding it according to a SQL statement. In addition, you can bind the execution plan for multiple SQL statements at once. For more details and examples, see [`CREATE [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-create-binding.md).
235
235
236
236
When using this feature, note the following:
237
237
238
238
- The feature generates hints according to historical execution plans and uses the generated hints for binding. Because historical execution plans are stored in [Statement Summary Tables](/statement-summary-tables.md), before using this feature, you need to enable the [`tidb_enable_stmt_summary`](/system-variables.md#tidb_enable_stmt_summary-new-in-v304) system variable first.
239
239
- For TiFlash queries, Join queries with three or more tables, and queries that contain subqueries, the auto-generated hints are not adequate, which might result in the plan not being fully bound. In such cases, a warning will occur when creating a binding.
240
-
- If a historical execution plan is for a SQL statement with hints, the hints will be added to the binding. For example, after executing `SELECT /*+ max_execution_time(1000) */ * FROM t`, the binding created with its `plan_digest` will include `max_execution_time(1000)`.
240
+
- If a historical execution plan is for a SQL statement with hints, the hints will be added to the binding. For example, after executing `SELECT /*+ max_execution_time(1000) */ * FROM t`, the binding created with its Plan Digest will include `max_execution_time(1000)`.
241
241
242
242
The SQL statement of this binding method is as follows:
243
243
244
244
```sql
245
-
CREATE [GLOBAL | SESSION] BINDING FROM HISTORY USING PLAN DIGEST 'plan_digest';
245
+
CREATE [GLOBAL | SESSION] BINDING FROM HISTORY USING PLAN DIGEST StringLiteralOrUserVariableList;
246
246
```
247
247
248
-
This statement binds an execution plan to a SQL statement using `plan_digest`. The default scope is SESSION. The applicable SQL statements, priorities, scopes, and effective conditions of the created bindings are the same as that of [bindings created according to SQL statements](#create-a-binding-according-to-a-sql-statement).
248
+
The preceding statement binds an execution plan to a SQL statement using Plan Digest. The default scope is SESSION. The applicable SQL statements, priorities, scopes, and effective conditions of the created bindings are the same as that of [bindings created according to SQL statements](#create-a-binding-according-to-a-sql-statement).
249
249
250
-
To use this binding method, you need to first get the `plan_digest`corresponding to the target historical execution plan in`statements_summary`, and then create a binding using the `plan_digest`. The detailed steps are as follows:
250
+
To use this binding method, you need to first get the Plan Digest corresponding to the target historical execution plan in`statements_summary`, and then create a binding using the Plan Digest. The detailed steps are as follows:
251
251
252
-
1. Get the `plan_digest` corresponding to the target execution plan in`statements_summary`.
252
+
1. Get the Plan Digest corresponding to the target execution plan in`statements_summary`.
253
253
254
254
For example:
255
255
@@ -274,9 +274,9 @@ To use this binding method, you need to first get the `plan_digest` correspondin
In this example, you can see that the execution plan corresponding to `plan_digest` is `4e3159169cc63c14b139a4e7d72eae1759875c9a9581f94bb2079aae961189cb`.
277
+
In this example, you can see that the execution plan corresponding to Plan Digest is `4e3159169cc63c14b139a4e7d72eae1759875c9a9581f94bb2079aae961189cb`.
278
278
279
-
2. Use `plan_digest` to create a binding:
279
+
2. Use Plan Digest to create a binding:
280
280
281
281
```sql
282
282
CREATE BINDING FROM HISTORY USING PLAN DIGEST '4e3159169cc63c14b139a4e7d72eae1759875c9a9581f94bb2079aae961189cb';
You can remove a binding according to a SQL statement or `sql_digest`.
320
+
You can remove a binding according to a SQL statement or SQL Digest.
321
321
322
322
#### Remove a binding according to a SQL statement
323
323
@@ -343,15 +343,15 @@ explain SELECT * FROM t1,t2 WHERE t1.id = t2.id;
343
343
344
344
In the example above, the dropped binding in the SESSION scope shields the corresponding binding in the GLOBAL scope. The optimizer does not add the `sm_join(t1, t2)` hint to the statement. The top node of the execution plan in the `explain` result is not fixed to MergeJoin by this hint. Instead, the top node is independently selected by the optimizer according to the cost estimation.
345
345
346
-
#### Remove a binding according to `sql_digest`
346
+
#### Remove a binding according to SQL Digest
347
347
348
-
In addition to removing a binding according to a SQL statement, you can also remove a binding according to `sql_digest`.
348
+
In addition to removing a binding according to a SQL statement, you can also remove a binding according to SQL Digest. For more details and examples, see [`DROP [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-drop-binding.md).
349
349
350
350
```sql
351
-
DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST 'sql_digest';
351
+
DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST StringLiteralOrUserVariableList;
352
352
```
353
353
354
-
This statement removes an execution plan binding corresponding to `sql_digest`at the GLOBAL or SESSION level. The default scope is SESSION. You can get the `sql_digest` by [viewing bindings](#view-bindings).
354
+
This statement removes an execution plan binding corresponding to SQL Digest at the GLOBAL or SESSION level. The default scope is SESSION. You can get the SQL Digest by [viewing bindings](#view-bindings).
You can create a binding according to a SQL statement or a historical execution plan.
34
40
41
+
When you create a binding according to a historical execution plan, you need to specify the corresponding Plan Digest:
42
+
43
+
- You can use either the string literal or user variable of the string type to specify the Plan Digest.
44
+
- You can specify multiple Plan Digests to create bindings for multiple statements at the same time. In this case, you can specify multiple strings, and include multiple digests in each string. Note that the strings or digests need to be separated by commas.
45
+
35
46
The following example shows how to create a binding according to a SQL statement.
36
47
37
48
{{< copyable "sql" >}}
@@ -139,34 +150,165 @@ mysql> EXPLAIN ANALYZE SELECT * FROM t1 WHERE b = 123;
139
150
The following example shows how to create a binding according to a historical execution plan.
140
151
141
152
```sql
142
-
mysql> CREATE TABLE t(id INTPRIMARY KEY , a INT, KEY(a));
CREATE GLOBAL BINDING FROM HISTORY USING PLAN DIGEST 'e72819cf99932f63a548156dbf433adda60e10337e89dcaa8638b4caf16f64d8,c291edc36b2482738d3389d335f37efc76290be2930330fe5034c5f4c42eeb36,8dc146249484f4a6ab219bfe9effa6b7a18aeed3764d49b610da61ac347ab914,73b2dec866595688ea416675f88ccb3456eb8e7443a79cd816695b688e07ac6b';
0 commit comments