起因在测试环境中反应

• 如图所示，加索引执行了几千秒没有成功。
• 运维人员加了一个索引，又加了一个索引，后面又执行了一个加字段的动作

• 通过admin show ddl的命令看到了最早的加索引命令。（后面的都被堵塞着，没机会执行，也就是推断DDL这个是串行动作）

• 在执行admin show ddl jobs命令看到历史上最新的10个命令以及现在最新的状态。
• 实在不理解为什么这个加索引会卡主而加字段顺利通过
  只能说加字段是在元数据上修改，加索引是有一个写磁盘的操作，所以一度怀疑是磁盘处理能力不够。

• 但是当看到表的数据之后就打消了这个想法，毕竟100多万的数据，即使在NAS这种不适合数据库的磁盘上也不至于几个小时没有返回。

• 为此还特意用了fio工具来测试磁盘。虽然只有2M每秒的IO能力，但是测试环境也不是说不过去。另外整个表也没有多大。全表排序也不至于说几个小时没有动静。

• 分布式数据库就是这样，有时候不一定能定位到哪个组件的问题。我都想到了把整个集群重启一次。想着是不是有未知的领域存在着不知道的锁。（因为单独查锁，没有查到任何锁）

• 重启以后可见，已经回退完成
  

• 但是问题没有解决
  

• 这个时候发挥开源社区的力量了，我在版主群中核大家讨论。
  有人给出建议说把tidb_enable_dist_task =off 关这个试试。这样做的目的是回避磁盘慢的可能性。
  不过结果是没有其作用。

• 又有人提出修改一个参数

• 设置tidb_service_scope = ‘background’

• 经过测试改成tidb_service_scope = 'background’以后 问题解决了。

• 小结：是我们人为指定，告诉数据库去让tidb这个组件去执行，tidb_service_scope = ‘background’。
  tidb_service_scope 是指定分布式ddl任务再哪个实例跑，只会调度到设置这个值的实例。

• 我们大家讨论的建议是：应该是存在可以优化的地方。如果tidb_service_scope就没设置，其实就等于ddl分布式执行框架没有可以执行的节点。这个应该在运行ddl的时候就提示。而不是执行ddl然后卡住。

• 当然这个问题是有迹可循的。如下图：
  

架构层面

• 从上面的描述得出要看各个节点的CPU

• 看到这个忽然明白了。CPU数量不一致
• 各抒己见：
  1.我们重要系统都会有一个查询节点，这个节点配置一般不会高，看样子以后还不能用这种分布式ddl?
  2.大型系统，更换机器也是逐批更换，cpu不一定完全相同。
  3.关键问题是没提示，就一直卡着。这就很难找到问题在哪里。
  4.现在这环境下，大系统的资源更是分批购置，东拼西借，差异还是有的。
  5. tidb_service_scope=’'background"的节点全挂了，那么执行ddl的节点会变成在tidb_service_scope=""的节点上执行，影响正常业务。
  6. 这个坑踩得好，学习知识了。

感悟

• 有时候我们认为理所应当的实际不是那样
• 纵然是很多老手也可能遇到新问题，这些新问题是我们从来没有考虑过的
• 建议官方这里执行之前预检测一下，不能一直这样等待