*: update

FAQ.md

@@ -367,7 +367,16 @@ Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD
 
 启动 TiDB Server 时，需要通过命令行参数设置 lease 参数（--lease=60），其值会影响 DDL 的速度（只会影响当前执行 DDL 的 session，其他的 session 不会受影响）。在测试阶段，lease 的值可以设为 1s，加快测试进度；在生产环境下，我们推荐这个值设为分钟级（一般可以设为 60），这样可以保证 DDL 操作的安全。
 
-#### 3.3.2 为什么有的时候执行 DDL 会很慢？
+#### 3.3.2 DDL 在正常情况下的耗时是多少？
+
+一般情况下处理一个 DDL 操作（之前没有其他 DDL 操作在处理）的耗时基本可以分如下为三种：
+- add index 操作，且此操作对应表数据行数比较少，耗时约为 3s.
+- add index 操作，且此操作对应表数据行数比较多，耗时具体由表中数据行数和当时 QPS 情况定（add index 操作优先级比一般 SQL 低）。
+- 其他 DDL 操作耗时约为 1s.
+
+此外，如果接收 DDL 请求的 TiDB 和 DDL owner 所处的 TiDB 是一台，那么上面列举的第一和第三种可能的耗时应该在几十到几百毫秒。
+
+#### 3.3.3 为什么有的时候执行 DDL 会很慢？
 
 可能原因如下：
 
@@ -376,14 +385,6 @@ Client 连接只能通过 TiDB 访问集群，TiDB 负责连接 PD 与 TiKV，PD
 - 在滚动升级或者停机升级时，由于停机顺序（先停 PD 再停 TiDB）或者用 `kill -9` 指令停 TiDB 导致 TiDB 没有及时清理注册数据，那么会影响 TiDB 启动后 10min 内的 DDL 语句处理时间。这段时间内运行 DDL 语句时，每个 DDL 状态变化都需要等待 2 * lease（默认 lease = 45s）。
 - 当集群中某个 TiDB 与 PD 之间发生通讯问题，即 TiDB 不能从 PD 及时获取或更新版本信息，那么这时候 DDL 操作的每个状态处理需要等待 2 * lease。
 
-#### 3.3.3 DDL 在正常情况下的耗时是多少？
-
-当只有一个 DDL 操作时，大部分 DDL 操作的耗时都约等于定时检查 DDL job 完成的间隔时间（其中间隔分两种：add index 操作为 3s，其他 DDL 操作为 1s）。如果接收 DDL 请求的 TiDB 和 DDL owner 所处的 TiDB 是一台的话，此 DDL 操作耗时为真实修改 schema 的耗时(约为上百毫秒)，即可忽略间隔时间，比如只有一台 TiDB 的集群。在正常情况下不属于此大部分 DDL 操作的是 add index 操作，且此操作所在表的行数过比较多时。
-
-这个间隔耗时问题后续会有优化。
-
-在此 DDL 操作开始前还有未完成的 DDL 操作时，还需加上处理之前 DDL 操作的时间。
-
 #### 3.3.4 TiDB 可以使用 S3 作为后端存储吗？
 
 不可以，目前 TiDB 只支持分布式存储引擎和 Goleveldb/Rocksdb/Boltdb 引擎；