TiDB大表创建索引时间超长尚未完成

【 TiDB 使用环境】生产环境、测试

【 TiDB 版本】v5.1.0

【遇到的问题】TiDB v5.1.0中执行如下创建索引命令,已经执行4-5天了还未执行完毕,有无方法查看其进度。
图一:创建索引命令

图二:创建索引时间

图三:表信息

admin show ddl jobs 查看一下ddl的进度

1 个赞

之前有类似的案例,是因为 GC 无法删除多版本数据的bug导致,
详见链接:https://asktug.com/t/topic/903353/22

1 个赞

能看到显示进程,就是进度慢。
1、2022年10月26日 14:52

2、2022年10月26日 14:56

如果不是因为bug导致加索引慢,可通过如下方式为 ADD INDEX 增加更多资源,但是会影响线上业务。

1 个赞

已经调整tidb_ddl_reorg_worker_cnt由4调整为8,观察一下不行就调整为16

1 个赞

但是调整tidb_ddl_reorg_priority报如下错误:


按提示应该是在create index时候就要用如下命令调整,只可惜创建索引命令已经执行了。
set tidb_ddl_reorg_priority=‘PRIORITY_HIGH’;

官方网站的相关add index在写入负载和查询负载,调整一下 tidb_ddl_reorg_worker_cnt、tidb_ddl_reorg_batch_size 的测试案例

https://docs.pingcap.com/zh/tidb/v3.0/online-workloads-and-add-index-operations

  1. 相关参数

tidb_ddl_reorg_worker_cnt

作用域:GLOBAL

默认值(2.1.17 之前版本):16 默认值(2.1.17 及之后版本):4

这个变量用来设置 DDL 操作 re-organize 阶段的并发度。

tidb_ddl_reorg_batch_size

作用域:GLOBAL

默认值(2.1.17 以前版本):1024 默认值(2.1.17 及以后版本):256

这个变量用来设置 DDL 操作 re-organize 阶段的 batch size。比如 Add Index 操作,需要回填索引数据,通过并发 tidb_ddl_reorg_worker_cnt 个 worker 一起回填数据,每个 worker 以 batch 为单位进行回填。如果 Add Index 时有较多 Update 操作或者 Replace 等更新操作,batch size 越大,事务冲突的概率也会越大,此时建议调小 batch size 的值,最小值是 32。在没有事务冲突的情况下,batch size 可设为较大值,最大值是 10240,这样回填数据的速度更快,但是 TiKV 的写入压力也会变大。

tidb_ddl_reorg_priority

作用域:SESSION

默认值:PRIORITY_LOW

这个变量用来设置 ADD INDEX 操作 re-organize 阶段的执行优先级,可设置为 PRIORITY_LOW/PRIORITY_NORMAL/PRIORITY_HIGH。

一般选择默认就可以

  1. 一定要在写入的业务低峰期,或者整体的业务空闲期,进行add index的操作,否在会造成大量的写写冲突,大表add index会造成tikv的负载很高

由于创建索引在扫表回填索引的时候会消耗大量资源,甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间,所以要尽可能地平衡执行时间和集群性能之间的关系,比如选择非高频更新时间段

参数调整:

目前主要使用 tidb_ddl_reorg_worker_cnt 和 tidb_ddl_reorg_batch_size 这两个参数来动态调整索引创建速度,通常来说它们的值越小对系统影响越小,但是执行时间越长。

一般情况下,先将值保持为默认的 4 和 256 ,观察集群资源使用情况和响应速度,再逐渐调大 tidb_ddl_reorg_worker_cnt 参数来增加并发,观察监控如果系统没有发生明显的抖动,再逐渐调大 tidb_ddl_reorg_batch_size 参数,但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。

另外还可以通过调整参数 tidb_ddl_reorg_priority 为 PRIORITY_HIGH 来让创建索引的任务保持高优先级来提升速度,但在通用 OLTP 系统上,一般建议保持默认。

SET GLOBAL tidb_ddl_reorg_worker_cnt = 16;
SET GLOBAL tidb_ddl_reorg_batch_size = 10240;

一定是业务低峰空闲时段进行

先检查下gc把,这么大的表,gc影响就挺大的

看下IO使用情况,如果IO利用率较高,这么大数据量创建索引回填数据也的确较慢

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。