【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】create index添加索引
【遇到的问题：问题现象及影响】
表大小200G左右，行数 26741006，执行了快一天了，一直不动
主机什么配置啊？
升级到 7.x （6.5.x 好像也支持），支持 fastreorg，就没这问题了
之前的版本确实有问题…
那现在只能等，没有其他办法了吗？ 
5.x 是单线程的，确实很慢…
只能等 
或者，新建一个表，把索引弄好之后，把数据填充进去来替换原来的表
等等吧
ROW_COUNT 在涨就行，希望涨快点可以用 6.5 以上版本支持 tidb_ddl_enable_fast_reorg ，一直不涨的话搜下用的版本是不是有什么已知问题吧
耐心等，勿轻易取消操作。
看下 tidb-server 的日志，看有什么报错么？
是的，ROW_COUNT 只要在变化就没问题
ROW_COUNT 在变化就行，或者升级到支持参数的的版本 tidb_ddl_enable_fast_reorg
蹲一个答案，已经不敢对大表加索引了
经历过这种情况，最终选择了升级版本。
升级前版本是v5.1.0，数据库表现：添加索引特别慢，稍微大点的表就要几十分钟甚至超过1个小时。
升级后版本是v6.5.4，数据库表现：1.6亿数据表加索引，用时192秒，3分钟左右。
V6.5.4版本亿级数据量加索引有这么快吗？
也得分具体情况吧。看字段数量和类型。
这个是实测数据，相同的ddl语句。当时确实很震惊~
最后是这样解决的：
参考：
https://docs.pingcap.com/zh/tidb/v7.1/garbage-collection-configuration#gc-in-compaction-filter-机制
关闭 Compaction Filter，以加快 GC 速度
关闭之后，观察这个表的GC情况
explain analyze select * from table_name;
total_process_keys: 27467763, total_process_keys_size: 15794369502, total_keys: 842294971
total_keys/total_process_keys=842294971/27467763=30.67
total_keys/total_process_keys的值越高，表示GC延迟越高，mvcc版本越多，就会导致建索引的时候需要扫描越多的数据块。
修改后第二天查看GC延迟已经降下来了，添加索引的DDL也执行完了
total_process_keys: 26354251, total_process_keys_size: 15873718557, total_keys: 57310326
total_keys/total_process_keys=57310326/26354251=2.17
1 个赞
另外参考这个帖子：