那是什么引起的呢？
怎么判断问题呢？
1、找出 DDL owner 节点：
通过 curl http://{TiDBIP}:10080/info/all 获取当前集群的 Owner，
2、如果 Owner 不存在，尝试手动触发 Owner 选举：curl -X POST http://{TiDBIP}:10080/ddl/owner/resign。
3、如果 Owner 存在，导出 Goroutine 堆栈并检查可能卡住的地方。
4、如果cpu较高，为了避免对业务影响，可以将 tidb_ddl_reorg_worker_cnt 和 tidb_ddl_reorg_batch_size 适当调小
1 个赞
好的，我学习一下
我觉的有可能是用的人看没有反映有点了一下，导致实际执行了好几次
看监控，看dashboard，分析慢SQL 
这个猜测有可能，但建议你还是先看监控，看dashboard分析慢SQL
限制一下随便乱用 sql 的开发吧！
首先，你们在社区已经有一段时间了。
建议 你和 @等一分钟 先把目前社区上免费的课程先学习了。
要对 TiDB 正确的使用方式有一个具体的了解，你才能知道怎么样用好 TiDB ~
再好的产品要架不住 随便乱造呀！
你把sql 发出来看看 可能300k
最好在空闲时添加
1 个赞
跑一周？对后续的读写有影响力吧？这种生产环境肯定不允许啊
加索引本身就是一个耗资源的操作。
有啥不允许的，它就得跑一周你咋办，我们ddl 参数调整的没那么大，对业务影响较小
tidb也是后加索引资源消耗更低吧
资源消耗不是以sql条数来算的。
聚合查询确实会导致tidb server的cpu上升，可以把加tiflash资源需求提上去，同时进行TOPSQL优化
要是可以分批添加索引就挺好 
应该是的，这样做的好处是空表加索引快，迁移数据可以采取并行也比较快。
1 个赞
SET GLOBAL tidb_enable_metadata_lock= ‘off’ ; 试试
SET GLOBAL tidb_ddl_enable_fast_reorg= ‘off’ ;
这个，复制错了