modify column执行时间过长

Leonard · 2023 年10 月 12 日 02:08

【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.1
【复现路径】做过哪些操作出现的问题
修改这张表的一个字段长度
【遇到的问题：问题现象及影响】
执行时间过长，而且ddl jobs中的ROW_COUNT 远远大于 STATS_META中的Row_count。
表健康度为95
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面

【附件：截图/日志/监控】

Fly-bird · 2023 年10 月 12 日 03:25

数据量大吗

Leonard · 2023 年10 月 12 日 03:41

26亿多行

h5n1 · 2023 年10 月 12 日 03:41

做的什么modify 操作，需要回填数据，这个就慢了

Leonard · 2023 年10 月 12 日 03:43

修改一个字段的长度

像风一样的男子 · 2023 年10 月 12 日 03:44

这个就慢了预估十来个小时了，只能等了。

Leonard · 2023 年10 月 12 日 03:45

现在已经执行了60多个小时了，而且为啥 show ddl jobs 的row count 远大于实际的row count呢

像风一样的男子 · 2023 年10 月 12 日 03:49

表统计信息不准确，ddl跑完后analyze下表

Leonard · 2023 年10 月 12 日 03:50

好的，目前还是只能等着是吧。

Leonard · 2023 年10 月 12 日 06:05

select count(*) 也是26亿多，统计信息准确的吧
企业微信截图_bba6dba5-4cfd-4708-8a88-ae3676e6eb24

hey-hoho · 2023 年10 月 12 日 10:52

modify的SQL发一下

Kongdom · 2023 年10 月 12 日 12:10

会不会是中间又插入记录了？毕竟执行了60多个小时

TiDBer_小阿飞 · 2023 年10 月 13 日 03:24

ROW_COUNT() 函数返回上一个 SQL 语句执行的受影响的行数。ROW_COUNT() 函数的执行逻辑如下：

如果上一个语句是 DDL 语句，ROW_COUNT() 函数将返回 0。比如 CREATE TABLE, DROP TABLE 等。
如果上一个语句是 UPDATE, INSERT, DELETE, ALTER TABLE 或者 LOAD DATA 语句，ROW_COUNT() 函数将返回受影响的行数。
如果上一个语句是一个返回结果集的 SELECT 语句，ROW_COUNT() 函数将返回 -1。
如果上一个语句不是一个返回结果集的 SELECT 语句，ROW_COUNT() 函数将返回受影响的行数。比如： SELECT * FROM t1 INTO OUTFILE 'file_name'。

xingzhenxiang · 2023 年10 月 13 日 08:07

啥时候ddl都要这么长时间了，我用tidb，除了索引，就没见过时间长的

路在何chu · 2023 年10 月 13 日 10:29

t这个有点异常啊，我们11亿的数据修改字段，很快完成了

tidb菜鸟一只 · 2023 年10 月 16 日 01:47

这个回填会产生全表数据量的两倍，所以你这种操作，modify_column大概回事总数据量的2倍也就是52亿行左右。

Leonard · 2023 年10 月 16 日 02:19

都5天多了，还没跑完，表里面就26亿多条数据，现在这个rowcount都有80多亿了

Leonard · 2023 年10 月 16 日 02:27

ALTER TABLE xxxx_dw.xxxxx_sku
MODIFY COLUMN xxx_price decimal(16, 4) NULL DEFAULT NULL COMMENT ‘售价’ AFTER xxxx_num

Kongdom · 2023 年10 月 16 日 02:28

中间不会是中断重试，然后行数就一直累加吧。

Leonard · 2023 年10 月 16 日 02:30

应该不能，tidb up 5天前的