1 DDL简介
TiDB的DDL变更参考了《Online，Asynchronous Schema Change in F1》论文，使其DDL变更具有异步（asynchronous）和在线（online）的特性，比起MySQL等传统数据库，十分灵活，是TiDB的一大特色。
论文引入了4个状态，其中两个外部状态：absent和public；两个内部状态：delete only和 write only。TiDB同样使用上述状态的变迁，达到在线DDL的功能，在状态变迁过程中，集群中最多只能存在两种状态，各个状态的含义，详见论文。
为了简化流程，TiDB首先会选出一个ddl owner 来处理具体处理每个DDL。选举会借助PD中的etcd服进行， 每个TiDB会通过调用Campaign 接口进行 owner 选举。如果选举成功，那么该 TiDB 会周期性的进行续租；当选举不成功，会watch ownerKey，一旦ownerKey有变动（如owner宕机），会触发再次竞选。只有成为ddl owner才有权执行DDL。可以通过直连TiDB执行 admin show ddl;命令来查看当前owner节点。
所有的DDL操作都会存储在KV上的ddl job queue中，ddl owner 会依次取出ddl job执行。执行完成的DDL会被移动到ddl history job queue中。如果该DDL job被移动到了ddl history job queue中，则表示该DDL已经执行完成。
DDL整体架构如下图所示，详细流程参考 DDL 源码解析。
2 常见DDL的状态迁移
创建库：
absent -> public
删除库：
public -> write only -> delete only -> absent
创建表：
absent -> public
删除表：
public -> write only -> delete only -> absent
创建视图：
absent -> public
删除视图：
public -> write only -> delete only -> absent
添加列：
absent -> delete only -> write only -> write reorganization -> public
删除列
public -> write only -> delete only -> delete reorganizeation -> absent
新建索引：
absent -> delete only -> write only -> write reorganization -> public
删除索引：
public -> write only -> delete only -> delete reorganizeation -> absent
其中的删除操作，会将对应的信息存储到gc_delete_range表中，在GC阶段真正处理。
恢复表：
absent ->write only -> public
3 DDL状态查看相关命令
DDL操作官网文档很详细，这里就不再赘述了。
admin show ddl;
admin show ddl jobs;
admin show ddl job queues xxx
admin cancel ddl jobs xxx
4 DDL调优
4.1 参数
tidb_ddl_reorg_worker_cnt default 16
tide_ddl_reorg_batch_size default 1024
当执行add index时，该集群上有频繁的写入操作，则add index 操作会对写入有一定的影响，可能会造成写入冲突。此时应该合理的降低上述两个参数的值，减少DDL造成的负载。当集群系统主要是频繁写入时，可以适当的调高参数，增加DDL的速度，此时对读取性能影响不大。
相关性能测试参考 线上负载与 ADD INDEX 相互影响测试
更全的DDL相关参数的传送门：传送门
4.2 DDL执行慢 和 正常耗时
不赘述了，参考官网相关内容就好啦：传送门
5 DDL的限制
同样不赘述了，参考官网相关内容就好啦：传送门