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
This statement binds SQL execution plans at the GLOBAL or SESSION level. Currently, supported bindable SQL statements (BindableStmt) in TiDB include `SELECT`, `DELETE`, `UPDATE`, and `INSERT` / `REPLACE` with `SELECT` subqueries. The following is an example:
44
44
45
45
```sql
46
-
CREATE GLOBAL BINDING USING SELECT/*+ use_index(t1, idx_a) */*FROMt1;
47
-
CREATE GLOBAL BINDING FOR SELECT*FROMt1 USING SELECT/*+ use_index(t1, idx_a) */*FROMt1;
46
+
CREATE GLOBAL BINDING USING SELECT/*+ use_index(orders, orders_book_id_idx) */*FROMorders;
47
+
CREATE GLOBAL BINDING FOR SELECT*FROMorders USING SELECT/*+ use_index(orders, orders_book_id_idx) */*FROMorders;
48
48
```
49
49
50
50
> **Note:**
51
51
>
52
52
> Bindings have higher priority over manually added hints. Therefore, when you execute a statement containing a hint while a corresponding binding is present, the hint controlling the behavior of the optimizer does not take effect. However, other types of hints are still effective.
53
53
54
-
Specifically, two types of these statements cannot be bound to execution plans due to syntax conflicts. See the following examples:
54
+
Specifically, two types of these statements cannot be bound to execution plans due to syntax conflicts. A syntax error will be reported during binding creation. See the following examples:
55
55
56
56
```sql
57
57
-- Type one: Statements that get the Cartesian product by using the `JOIN` keyword and not specifying the associated columns with the `USING` keyword.
58
58
CREATE GLOBAL BINDING for
59
-
SELECT*FROMt t1JOINt t2
59
+
SELECT*FROMorders o1JOINorders o2
60
60
USING
61
-
SELECT*FROMt t1JOINt t2;
61
+
SELECT*FROMorders o1JOINorders o2;
62
62
63
63
-- Type two: `DELETE` statements that contain the `USING` keyword.
64
64
CREATE GLOBAL BINDING for
65
-
DELETEFROMt1 USING t1JOINt2ONt1.a=t2.a
65
+
DELETEFROMusers USING usersJOINordersONusers.id=orders.user_id
66
66
USING
67
-
DELETEFROMt1 USING t1JOINt2ONt1.a=t2.a;
67
+
DELETEFROMusers USING usersJOINordersONusers.id=orders.user_id;
68
68
```
69
69
70
70
You can bypass syntax conflicts by using equivalent statements. For example, you can rewrite the above statements in the following ways:
71
71
72
72
```sql
73
-
--First rewrite of type one statements: Add a `USING` clause for the `JOIN` keyword.
73
+
--Rewrite of type one statements: Delete the `JOIN` keyword. Replace it with a comma.
74
74
CREATE GLOBAL BINDING for
75
-
SELECT*FROMt t1 JOIN t t2 USING (a)
75
+
SELECT*FROMorders o1, orders o2
76
76
USING
77
-
SELECT*FROMt t1 JOIN t t2 USING (a);
77
+
SELECT*FROMorders o1, orders o2;
78
78
79
-
--Second rewrite of type one statements: Delete the `JOIN` keyword.
79
+
--Rewrite of type two statements: Remove the `USING` keyword from the `DELETE` statement.
If you do not specify the scope when creating an execution plan binding, the default scope is SESSION. The TiDB optimizer normalizes bound SQL statements and stores them in the system table. When processing SQL queries, if a normalized statement matches one of the bound SQL statements in the system table and the system variable `tidb_use_plan_baselines` is set to `on` (the default value is `on`), TiDB then uses the corresponding optimizer hint for this statement. If there are multiple matchable execution plans, the optimizer chooses the least costly one to bind.
113
107
114
108
`Normalization` is a process that converts a constant in an SQL statement to a variable parameter and explicitly specifies the database for tables referenced in the query, with standardized processing on the spaces and line breaks in the SQL statement. See the following example:
115
109
116
110
```sql
117
-
SELECT*FROMtWHEREa>1
111
+
SELECT*FROMusersWHEREbalance>100
118
112
-- After normalization, the above statement is as follows:
119
-
SELECT*FROMtest . tWHEREa> ?
113
+
SELECT*FROMbookshop . usersWHEREbalance> ?
120
114
```
121
115
122
116
> **Note:**
@@ -126,11 +120,11 @@ SELECT * FROM test . t WHERE a > ?
>-- After normalization, the above statements are as follows:
132
-
>SELECT*FROMtest . tWHEREaIN ( ... )
133
-
>SELECT*FROMtest . tWHEREaIN ( ... )
126
+
>SELECT*FROMbookshop . booksWHEREtypeIN ( ... )
127
+
>SELECT*FROMbookshop . booksWHEREtypeIN ( ... )
134
128
>```
135
129
>
136
130
> After normalization, `IN` predicates of different lengths are recognized as the same statement, so you only need to create one binding that applies to all these predicates.
0 commit comments