Supported table DDL statements include CREATE, ALTER, and DROP statements for databases, tablespaces, tables, and indexes, and the TRUNCATE TABLE statement.支持的表DDL语句包括数据库、表空间、表和索引的CREATE、ALTER和DROP语句，以及TRUNCATE TABLE语句。

Supported non-table DDL statements include:支持的非表DDL语句包括：

Table-related DDL statements that involve a storage engine other than InnoDB.涉及InnoDB以外的存储引擎的表相关DDL语句。

INSTALL PLUGIN and UNINSTALL PLUGIN statements.INSTALL PLUGIN语句和UNINSTALL PLUGIN语句。

INSTALL COMPONENT and UNINSTALL COMPONENT statements.INSTALL COMPONENT语句和UNINSTALL COMPONENT语句。

CREATE SERVER, ALTER SERVER, and DROP SERVER statements.CREATE SERVER、ALTER SERVER和DROP SERVER语句。

Metadata updates, binary log writes, and storage engine operations, where applicable, are combined into a single atomic operation.元数据更新、二进制日志写入和存储引擎操作（如果适用）组合到单个原子操作中。

There are no intermediate commits at the SQL layer during the DDL operation.在DDL操作期间，SQL层没有中间提交。

Where applicable:如适用：

The visible behaviour of DDL operations is atomic, which changes the behavior of some DDL statements. DDL操作的可见行为是原子的，这改变了一些DDL语句的行为。See Changes in DDL Statement Behavior.请参阅DDL语句行为中的更改。

DROP TABLE operations are fully atomic if all named tables use an atomic DDL-supported storage engine. 如果所有命名表都使用原子DDL支持的存储引擎，则DROP TABLE操作是完全原子的。The statement either drops all tables successfully or is rolled back.语句要么成功删除所有表，要么回滚。

DROP TABLE fails with an error if a named table does not exist, and no changes are made, regardless of the storage engine. 如果命名表不存在，并且无论存储引擎如何，都不会进行任何更改，则DROP TABLE将失败并出现错误。This change in behavior is demonstrated in the following example, where the DROP TABLE statement fails because a named table does not exist:下面的示例演示了这种行为变化，其中DROP TABLE语句由于命名表不存在而失败：

mysql> CREATE TABLE t1 (c1 INT);
mysql> DROP TABLE t1, t2;
ERROR 1051 (42S02): Unknown table 'test.t2'
mysql> SHOW TABLES;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
+----------------+

Prior to the introduction of atomic DDL, DROP TABLE reports an error for the named table that does not exist but succeeds for the named table that does exist:在引入原子DDL之前，DROP TABLE为不存在的命名表报告错误，但为存在的命名表报告成功：

mysql> CREATE TABLE t1 (c1 INT);
mysql> DROP TABLE t1, t2;
ERROR 1051 (42S02): Unknown table 'test.t2'
mysql> SHOW TABLES;
Empty set (0.00 sec)

DROP DATABASE is atomic if all tables use an atomic DDL-supported storage engine. 如果所有表都使用支持原子DDL的存储引擎，则DROP DATABASE是原子的。The statement either drops all objects successfully or is rolled back. 语句要么成功删除所有对象，要么回滚。However, removal of the database directory from the file system occurs last and is not part of the atomic operation. 但是，从文件系统中删除数据库目录是最后一次，并且不是原子操作的一部分。If removal of the database directory fails due to a file system error or server halt, the DROP DATABASE transaction is not rolled back.如果由于文件系统错误或服务器停止而删除数据库目录失败，则不会回滚DROP DATABASE事务。

For tables that do not use an atomic DDL-supported storage engine, table deletion occurs outside of the atomic DROP TABLE or DROP DATABASE transaction. 对于不使用原子DDL支持的存储引擎的表，表删除发生在原子DROP table或DROP DATABASE事务之外。Such table deletions are written to the binary log individually, which limits the discrepancy between the storage engine, data dictionary, and binary log to one table at most in the case of an interrupted DROP TABLE or DROP DATABASE operation. 这样的表删除会分别写入二进制日志，这样在中断DROP TABLE或DROP DATABASE操作的情况下，存储引擎、数据字典和二进制日志之间的差异最多只能限于一个表。For operations that drop multiple tables, the tables that do not use an atomic DDL-supported storage engine are dropped before tables that do.对于删除多个表的操作，不使用原子DDL支持的存储引擎的表将在使用原子DDL支持的存储引擎的表之前删除。

CREATE TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE TABLESPACE, and DROP TABLESPACE operations for tables that use an atomic DDL-supported storage engine are either fully committed or rolled back if the server halts during their operation. 使用支持DDL的原子存储引擎的表的CREATE TABLE、ALTER TABLE、RENAME TABLE、TRUNCATE TABLE、CREATE TABLESPACE和DROP TABLESPACE操作要么完全提交，要么在操作期间服务器停止时回滚。In earlier MySQL releases, interruption of these operations could cause discrepancies between the storage engine, data dictionary, and binary log, or leave behind orphan files. 在早期的MySQL版本中，这些操作的中断可能会导致存储引擎、数据字典和二进制日志之间的差异，或者留下孤立文件。RENAME TABLE operations are only atomic if all named tables use an atomic DDL-supported storage engine.只有当所有命名表都使用支持原子DDL的存储引擎时，RENAME TABLE操作才是原子的。

As of MySQL 8.0.21, on storage engines that support atomic DDL, the CREATE TABLE ... SELECT statement is logged as one transaction in the binary log when row-based replication is in use. 从MySQL8.0.21开始，在支持原子DDL的存储引擎上，当使用基于行的复制时，CREATE TABLE ... SELECT语句作为一个事务记录在二进制日志中。Previously, it was logged as two transactions, one to create the table, and the other to insert data. 以前，它被记录为两个事务，一个用于创建表，另一个用于插入数据。A server failure between the two transactions or while inserting data could result in replication of an empty table. 两个事务之间或插入数据时发生服务器故障可能会导致复制空表。With the introduction of atomic DDL support, CREATE TABLE ... SELECT statements are now safe for row-based replication and permitted for use with GTID-based replication.随着原子DDL支持的引入，CREATE TABLE ... SELECT语句现在对于基于行的复制是安全的，并且允许与基于GTID的复制一起使用。

On storage engines that support both atomic DDL and foreign key constraints, creation of foreign keys is not permitted in CREATE TABLE ... SELECT statements when row-based replication is in use. 在同时支持原子DDL和外键约束的存储引擎上，当使用基于行的复制时，不允许在CREATE TABLE ... SELECT语句中创建外键。Foreign key constraints can be added later using ALTER TABLE.外键约束可以稍后使用ALTERTABLE添加。

When CREATE TABLE ... SELECT is applied as an atomic operation, a metadata lock is held on the table while data is inserted, which prevents concurrent access to the table for the duration of the operation.当CREATE TABLE ... SELECT作为原子操作应用，插入数据时在表上保留元数据锁，这会在操作期间阻止对表的并发访问。

DROP VIEW fails if a named view does not exist, and no changes are made. 如果命名视图不存在且未进行任何更改，则DROP VIEW将失败。The change in behavior is demonstrated in this example, where the DROP VIEW statement fails because a named view does not exist:此示例演示了行为的更改，其中DROP VIEW语句由于不存在命名视图而失败：

mysql> CREATE VIEW test.viewA AS SELECT * FROM t;
mysql> DROP VIEW test.viewA, test.viewB;
ERROR 1051 (42S02): Unknown table 'test.viewB'
mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';
+----------------+------------+
| Tables_in_test | Table_type |
+----------------+------------+
| viewA          | VIEW       |
+----------------+------------+

Prior to the introduction of atomic DDL, DROP VIEW returns an error for the named view that does not exist but succeeds for the named view that does exist:在引入原子DDL之前，DROP VIEW为不存在的命名视图返回一个错误，但为存在的命名视图返回一个成功的错误：

mysql> CREATE VIEW test.viewA AS SELECT * FROM t;
mysql> DROP VIEW test.viewA, test.viewB;
ERROR 1051 (42S02): Unknown table 'test.viewB'
mysql> SHOW FULL TABLES IN test WHERE TABLE_TYPE LIKE 'VIEW';
Empty set (0.00 sec)

Partial execution of account management statements is no longer permitted. 不再允许部分执行账户管理报表。Account management statements either succeed for all named users or roll back and have no effect if an error occurs. 帐户管理语句要么对所有指定用户成功，要么回滚，并且在发生错误时不起作用。In earlier MySQL versions, account management statements that name multiple users could succeed for some users and fail for others.在早期的MySQL版本中，命名多个用户的帐户管理语句可能对某些用户成功，而对其他用户失败。

The change in behavior is demonstrated in this example, where the second CREATE USER statement returns an error but fails because it cannot succeed for all named users.这个例子演示了行为的变化，其中第二个CREATE USER语句返回一个错误，但是失败了，因为它不能对所有命名用户成功。

mysql> CREATE USER userA;
mysql> CREATE USER userA, userB;
ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'
mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';
+-------+
| User  |
+-------+
| userA |
+-------+

Prior to the introduction of atomic DDL, the second CREATE USER statement returns an error for the named user that does not exist but succeeds for the named user that does exist:在引入原子DDL之前，第二条CREATE USER语句为不存在的命名用户返回一个错误，但为存在的命名用户返回一个成功的错误：

mysql> CREATE USER userA;
mysql> CREATE USER userA, userB;
ERROR 1396 (HY000): Operation CREATE USER failed for 'userA'@'%'
mysql> SELECT User FROM mysql.user WHERE User LIKE 'user%';
+-------+
| User  |
+-------+
| userA |
| userB |
+-------+

id: A unique identifier for a DDL log record.：DDL日志记录的唯一标识符。

thread_id: Each DDL log record is assigned a thread_id, which is used to replay and remove DDL logs that belong to a particular DDL operation. ：为每个DDL日志记录分配一个thread_id，用于重播和删除属于特定DDL操作的DDL日志。DDL operations that involve multiple data file operations generate multiple DDL log records.涉及多个数据文件操作的DDL操作生成多个DDL日志记录。

type: The DDL operation type. Types include FREE (drop an index tree), DELETE (delete a file), RENAME (rename a file), or DROP (drop metadata from the mysql.innodb_dynamic_metadata data dictionary table).：DDL操作类型。类型包括FREE（删除索引树）、DELETE（删除文件）、RENAME（重命名文件）或DROP（从mysql.innodb_dynamic_metadata数据字典表中删除元数据）。

space_id: The tablespace ID.：表空间ID。

page_no: A page that contains allocation information; an index tree root page, for example.：包含分配信息的页面；例如，索引树根页。

index_id: The index ID.：索引ID。

table_id: The table ID.：表ID。

old_file_path: The old tablespace file path. ：旧表空间文件路径。Used by DDL operations that create or drop tablespace files; also used by DDL operations that rename a tablespace.用于创建或删除表空间文件的DDL操作；也由重命名表空间的DDL操作使用。

new_file_path: The new tablespace file path. Used by DDL operations that rename tablespace files.：新表空间文件路径。由重命名表空间文件的DDL操作使用。