新DDL执行引擎引入任务管理，外部行为与之前版本相比有所变化。本文将介绍相关的常见场景与限制。
- 典型的应用场景
- DDL正常执行成功时，无需关注DDL任务的状态，已成功完成的DDL任务会被自动清理。
- 建议执行DDL成功后，立即执行
CHECK TABLE检查确认逻辑表的一致性。 - DDL执行失败时，会返回导致失败的错误码和错误信息，您也可以通过
SHOW DDL查看PENDING状态的DDL任务失败的原因（即REMARK字段中记录的信息）。建议您在排除导致DDL执行错误的因素后，再尝试执行DDL任务管理语句进行恢复、回滚或删除操作，否则DDL执行可能仍会失败。 - 若DDL执行失败，对应的DDL任务处于PENDING状态时，出于保护目的，目标表会处于不可访问状态（
SHOW TABLES等操作无法显示，DML等操作可能会收到Unknown table或doesn't exist之类的报错），直到DDL任务通过恢复或回滚等方式使目标表达到一致性的状态后，该表才可以被正常访问。 - 当为CREATE TABLE指定
IF NOT EXISTS或者为DROP TABLE指定IF EXISTS时，一些执行过程中的错误不会导致 DDL失败，但会记录在warning警告中，请注意DDL执行后是否返回warning数量的消息（例如1 warning），并用SHOW WARNINGS语句检查警告，避免遗漏重要的信息。 - 通过DMS等客户端工具执行DDL时，若无法评估DDL需要的执行时间，并且客户端工具本身带有超时中断连接（客户端与PolarDB-X之间的连接）的设置，为了避免DDL被超时中断，可启用
PURE_ASYNC_DDL_MODE异步模式，执行后立即返回，继续通过SHOW DDL查看DDL任务状态 - 通过DDL任务管理语句恢复、回滚或删除DDL任务后，也建议执行
CHECK TABLE检查确认逻辑表的一致性。
- DDL任务管理的限制
- 仅支持
CREATE TABLE和RENAME TABLE两种DDL回滚操作。 - 不支持对处于PENDING状态的任务执行恢复（
RECOVER DDL）和回滚（ROLLBACK DDL）的组合重复操作（如先回滚失败任务，回滚失败后再对任务进行恢复操作。此类组合操作有可能造成逻辑表的不一致状态，如果遇到此类复杂场景，请联系客服或提交工单解决问题。 REMOVE DDL要在非常确定安全性的前提下谨慎使用，若不确定则不应执行REMOVE DDL，误用可能造成DDL任务的中间状态暴露，出现逻辑表不一致的情况。如果因为误用REMOVE DDL产生问题或不确定的状态，请联系客服或提交工单解决问题。- 默认拆分表的单个物理库允许创建最多128个分表，您也可以通过如下参数调整上限。
mysql> create table test_mdb_mtb (c1 intnotnull auto_increment primary key, c2 varchar(10), c3 date) dbpartition by hash(c1) tbpartition by hash(c1) tbpartitions 129;ERROR 4647(HY000):[f5bd90594800000][30.25.86.55:8527][JICHEN_LOCAL_APP]ERR-CODE:[TDDL-4647][ERR_TABLE_PARTITIONS_EXCEED_LIMIT]The number of table partitions '129' exceeds the upper limit '128'.Please specify less table partitions or adjust the value of the parameter MAX_TABLE_PARTITIONS_PER_DB.mysql>/*+TDDL:cmd_extra(MAX_TABLE_PARTITIONS_PER_DB=400)*/create table test_mdb_mtb (c1 intnotnull auto_increment primary key, c2 varchar(10), c3 date) dbpartition by hash(c1) tbpartition by hash(c1) tbpartitions 129;Query OK,0 rows affected (2.64 sec)
- DDL执行引擎内部的任务队列，最多允许堆积65535个PENDING状态的DDL任务，超过此上限则无法执行DDL，需要通过
REMOVE DDL谨慎清理可删除的遗留任务，该数量限制无法通过参数调整上限。
