diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md
index 7ebb40ebeb81..313233a94eba 100644
--- a/ticdc/ticdc-ddl.md
+++ b/ticdc/ticdc-ddl.md
@@ -61,7 +61,7 @@ summary: 了解 TiCDC 支持同步的 DDL 和一些特殊情况
 
 ### 创建和添加索引 DDL 的异步执行
 
-为了减小对 Changefeed 同步延迟的影响，如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以避免阻塞后续的 DML 执行。
+虽然 TiCDC 在大多数情况下会按顺序同步 DDL，但如果下游是 TiDB，TiCDC 会异步执行创建和添加索引的 DDL 操作，即 TiCDC 将 `ADD INDEX` 和 `CREATE INDEX` DDL 同步到下游执行后，会立刻返回，而不会等待 DDL 操作完成。这样可以减小对 Changefeed 同步延迟的影响，避免阻塞后续的 DML 执行。
 
 当 `ADD INDEX` 或 `CREATE INDEX` DDL 操作在下游执行期间，TiCDC 执行同一张表的下一条 DDL 时，这条 DDL 可能长期被阻塞在 `queueing` 状态，导致其被 TiCDC 重复执行多次，重试时间过长时还会导致同步任务失败。从 v8.4.0 开始，如果拥有下游数据库的 `SUPER` 权限，TiCDC 会定期执行 `ADMIN SHOW DDL JOBS` 查询异步执行的 DDL 任务的状态，等到索引创建完成后再继续同步。这期间虽然同步任务的延迟会加剧，但避免了同步任务失败的问题。
 
diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md
index 359473732894..4628b5af0fb4 100644
--- a/ticdc/ticdc-faq.md
+++ b/ticdc/ticdc-faq.md
@@ -403,12 +403,14 @@ BR (Backup & Restore) 工具是将直接将数据生成 SST 文件并导入 TiKV
 
 ## 如何理解 DML 和 DDL 语句之间的执行顺序？
 
-目前，TiCDC 采用了以下执行顺序：
+对于大多数 DDL，TiCDC 采用以下执行顺序：
 
 1. TiCDC 阻塞受 DDL 影响的表的同步进度，直到 DDL `commitTS` 的时间点，以确保在 DDL `commitTS` 之前执行的 DML 先成功同步到下游。
-2. TiCDC 继续同步 DDL。当存在多个 DDL 时，TiCDC 是以串行的方式进行同步的。
+2. TiCDC 继续同步 DDL。当存在多个 DDL 时，TiCDC 通常以串行的方式进行同步。
 3. 当 DDL 在下游执行完成之后，TiCDC 继续同步 DDL `commitTS` 之后执行的 DML。
 
+对于 `ADD INDEX` 和 `CREATE INDEX`，当下游是 TiDB 时，TiCDC 会异步执行这两类 DDL，不会等待其在下游执行完成后再返回，以减小对 Changefeed 同步延迟的影响。更多信息，请参考[创建和添加索引 DDL 的异步执行](/ticdc/ticdc-ddl.md#创建和添加索引-ddl-的异步执行)。
+
 ## 如何对比上下游数据的一致性？
 
 如果下游是 TiDB 集群或者 MySQL，我们推荐使用 [sync diff inspector](/sync-diff-inspector/sync-diff-inspector-overview.md) 工具进行数据对比。