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: ddl-introduction.md
+25-25
Original file line number
Diff line number
Diff line change
@@ -77,6 +77,31 @@ absent -> delete only -> write only -> write reorg -> public
77
77
For users, the newly created index is unavailable before the `public` state.
78
78
79
79
<SimpleTab>
80
+
<divlabel="Parallel DDL framework starting from v6.2.0">
81
+
82
+
Before TiDB v6.2.0, because the Owner can only execute one DDL task of the same type (either logical or physical) at a time, which is relatively strict, and affects the user experience.
83
+
84
+
If there is no dependency between DDL tasks, parallel execution does not affect data correctness and consistency. For example, user A adds an index to the `T1` table, while user B deletes a column from the `T2` table. These two DDL statements can be executed in parallel.
85
+
86
+
To improve the user experience of DDL execution, starting from v6.2.0, TiDB enables the Owner to determine the relevance of DDL tasks. The logic is as follows:
87
+
88
+
+ DDL statements to be performed on the same table are mutually blocked.
89
+
+`DROP DATABASE` and DDL statements that affect all objects in the database are mutually blocked.
90
+
+ Adding indexes and column type changes on different tables can be executed concurrently.
91
+
+ A logical DDL statement must wait for the previous logical DDL statement to be executed before it can be executed.
92
+
+ In other cases, DDL can be executed based on the level of availability for concurrent DDL execution.
93
+
94
+
Specifically, TiDB 6.2.0 has enhanced the DDL execution framework in the following aspects:
95
+
96
+
+ The DDL Owner can execute DDL tasks in parallel based on the preceding logic.
97
+
+ The first-in-first-out issue in the DDL Job queue has been addressed. The DDL Owner no longer selects the first job in the queue, but instead selects the job that can be executed at the current time.
98
+
+ The number of workers that handle physical DDL statements has been increased, enabling multiple physical DDL statements to be executed in parallel.
99
+
100
+
Because all DDL tasks in TiDB are implemented using an online change approach, TiDB can determine the relevance of new DDL jobs through the Owner, and schedule DDL tasks based on this information. This approach enables the distributed database to achieve the same level of DDL concurrency as traditional databases.
101
+
102
+
The concurrent DDL framework enhances the execution capability of DDL statements in TiDB, making it more compatible with the usage patterns of commercial databases.
103
+
104
+
</div>
80
105
<divlabel="Online DDL asynchronous change before TiDB v6.2.0">
81
106
82
107
Before v6.2.0, the process of handling asynchronous schema changes in the TiDB SQL layer is as follows:
@@ -103,31 +128,6 @@ Before TiDB v6.2.0, the DDL execution framework had the following limitations:
103
128
104
129
These limitations might lead to some "unintended" DDL blocking behavior. For more details, see [SQL FAQ - DDL Execution](https://docs.pingcap.com/tidb/stable/sql-faq#ddl-execution).
105
130
106
-
</div>
107
-
<divlabel="Parallel DDL framework starting from v6.2.0">
108
-
109
-
Before TiDB v6.2.0, because the Owner can only execute one DDL task of the same type (either logical or physical) at a time, which is relatively strict, and affects the user experience.
110
-
111
-
If there is no dependency between DDL tasks, parallel execution does not affect data correctness and consistency. For example, user A adds an index to the `T1` table, while user B deletes a column from the `T2` table. These two DDL statements can be executed in parallel.
112
-
113
-
To improve the user experience of DDL execution, starting from v6.2.0, TiDB enables the Owner to determine the relevance of DDL tasks. The logic is as follows:
114
-
115
-
+ DDL statements to be performed on the same table are mutually blocked.
116
-
+`DROP DATABASE` and DDL statements that affect all objects in the database are mutually blocked.
117
-
+ Adding indexes and column type changes on different tables can be executed concurrently.
118
-
+ A logical DDL statement must wait for the previous logical DDL statement to be executed before it can be executed.
119
-
+ In other cases, DDL can be executed based on the level of availability for concurrent DDL execution.
120
-
121
-
Specifically, TiDB 6.2.0 has enhanced the DDL execution framework in the following aspects:
122
-
123
-
+ The DDL Owner can execute DDL tasks in parallel based on the preceding logic.
124
-
+ The first-in-first-out issue in the DDL Job queue has been addressed. The DDL Owner no longer selects the first job in the queue, but instead selects the job that can be executed at the current time.
125
-
+ The number of workers that handle physical DDL statements has been increased, enabling multiple physical DDL statements to be executed in parallel.
126
-
127
-
Because all DDL tasks in TiDB are implemented using an online change approach, TiDB can determine the relevance of new DDL jobs through the Owner, and schedule DDL tasks based on this information. This approach enables the distributed database to achieve the same level of DDL concurrency as traditional databases.
128
-
129
-
The concurrent DDL framework enhances the execution capability of DDL statements in TiDB, making it more compatible with the usage patterns of commercial databases.
0 commit comments