900w表添加索引超过一天还没执行完，如何排查？

🪐 TiDB 技术问题
21

终于加完了，耗时5天又5个小时

22

只有这个表有问题，其他900w左右的表很快就能加上索引

23

这表是不是比较频繁更新或之前有大量删除，23亿的历史版本，感觉像是表范围内，某段范围的历史版本较多导致reorg回填数据显得慢

24

以后可以提前评估一下系统资源使用情况，加索引等相关系统参数，然后调整一下参数在开搞

25

@DBRE

感谢反馈。

v5.2.2 版本存在已知多版本 GC 问题，可能导致 mvcc deletion 版本无法被 GC 删除 使得版本堆积影响 scan 姓名。 DDL index backfill 需要通过 kv_scan 接口扫描 row 数据，如果遇到该问题可能导致 kv_scan 处理慢拖慢整个backfill 过程。
建议升级到最新发布版本（如希望保留 v5.2.x，可使用 v5.2 最新的 v5.2.4 版本），以解决该问题。

1 个赞
26

具体是什么原因导致gc不能清理，其他版本貌似也有这问题，能否整理个列表每个大半本升级到哪个小版本可以解决

27

上述问题对应 issue: https://github.com/tikv/tikv/issues/11217

影响版本

  • v5.0.0-v5.0.4
  • v5.1.0-v5.1.2
  • v5.2.0-v5.2.2

现象和确认方法

  • 部分 scan 相关操作执行慢，集群中有比较多的 UPDATE/DELETE 语句执行
  • EXPLAIN ANALYZE 的 scan detail 中显示 key_skipped_count 远远多于 total_process_keys 或者 slow log 中 key_skipped_count 远远多于 total_process_keys

解决方案

  • 设置 gc.enable-compaction-filter: false 以关闭 TiKV 的 compaction filter GC，使用旧的 GC 模式进行多版本 GC
  • 升级到新版本，如上所述选择发行版最新的发布版本
2 个赞
28

系统压力不大，ddl参数也调整了，加索引就是慢:joy:

29

请问，像这种情况gc不能清理历史版本，能通过什么可以查看到吗，这样可以提前预知。

30

GC的bug，只能升级了

31

目前我也是5.2.2版本遇到这个问题，尝试使用 设置 gc.enable-compaction-filter: false 。add index也是没有推进。

32

目前暂时没有直接的方法，版本堆积有些情况下可能是预期的现象，版本堆积造成的问题现象也可能多种多样。一些常见的方法是尝试关注查询的性能，如果查询中出现跳过大量版本，或者 tombstone key 的情况，则可能是版本存在堆积，之后再进一步分析版本堆积是否出现异常，如长时间不清理等。

33

add index 可能已经卡在 kv_scan 读取数据上，上面提到的方式是激活旧版本 GC 来清理多版本数据，有一个时间过程，需要等到这些历史版本被 GC 且被彻底清理之后，相关的扫描性能才能提升。

34

目前还有别的集群遇到的 也是这个问题么 我改了gc.enable-compaction-filter: false 大概需要等多久，我看改了10分钟之后GC KEYS都一直为0了，感觉都没GC了。担心出问题就改回来了

35

需要先分析下目前 DDL 卡住状态的具体问题和现象，比如：

  • 是否是 ddl owner 卡住了有无对应 ddl owner 错误日志，可参考 [FAQ] DDL 卡住排查经验 这个帖子，有可能需要抓取 ddl owner 所在 tidb-server 堆栈进一步分析
  • 如果 ddl owner 推进正常，再进一步分析卡在了哪个环节。比如 ddl 任务确实卡在了 kv_scan，那么大概率遇到了上述问题