转成分区表耗时很久

🌞 建议反馈 产品缺陷
1 
MySQL [dw_raw]> ALTER TABLE user_pay PARTITION BY RANGE COLUMNS (event_datetime) INTERVAL (1 YEAR) FIRST PARTITION LESS THAN ('2022-01-01') LAST PARTITION LESS THAN ('2030-01-01');
Query OK, 0 rows affected, 1 warning (1 hour 9 min 57.072 sec)

MySQL [dw_raw]> select count(1) from user_pay;
+----------+
| count(1) |
+----------+
|  4774033 |
+----------+

MySQL [dw_raw]> admin show ddl jobs\G
*************************** 1. row ***************************
      JOB_ID: 1590
     DB_NAME: dw_raw
  TABLE_NAME: user_pay
    JOB_TYPE: alter table partition by
SCHEMA_STATE: none
   SCHEMA_ID: 61
    TABLE_ID: 109
   ROW_COUNT: 348715609
 CREATE_TIME: 2024-03-15 00:53:32
  START_TIME: 2024-03-15 00:53:32
    END_TIME: 2024-03-15 02:03:26
       STATE: synced

之前也查过添加索引时候的ddl进度，row_count我记得是代表已处理的行数，比较好奇的是为什么400万行的表在处理分区的时候row_count会到3亿

2

ALTER TABLE 卡很常见 :smiley:

3

348715609条数据，应该是很大的表，慢很正常

4
  1. 可能是统计的算法有问题
  2. 可能有过多 mvcc
  3. 可能在 DDL 执行过程中有变更影响。

可以去反馈区反馈下。

5

Bug 反馈
清晰准确地描述您发现的问题，提供任何可能复现问题的步骤有助于研发同学及时处理问题
【 TiDB 版本】
【 Bug 的影响】

【可能的问题复现步骤】

【看到的非预期行为】

【期望看到的行为】

【相关组件及具体版本】

【其他背景信息或者截图】
如集群拓扑，系统和内核版本，应用 app 信息等；如果问题跟 SQL 有关，请提供 SQL 语句和相关表的 Schema 信息；如果节点日志存在关键报错，请提供相关节点的日志内容或文件；如果一些业务敏感信息不便提供，请留下联系方式，我们与您私下沟通。

请按照这样子反馈反馈~

6

gc设置的多长时间呢，会不会跟旧版本数据有关系

7

是不是统计信息不准确，或者历史版本太多了

8

kv数据库这里是不是key的数量，可以看看视图这个表有多少key

9 
MySQL [dw_raw]> create table user_pay_test like user_pay;
Query OK, 0 rows affected (0.530 sec)

MySQL [dw_raw]> ALTER TABLE user_pay_test PARTITION BY RANGE COLUMNS (event_datetime) INTERVAL (1 MONTH) FIRST PARTITION LESS THAN ('2021-01-01') LAST PARTITION LESS THAN ('2030-01-01');
Query OK, 0 rows affected, 1 warning (48.037 sec)

MySQL [dw_raw]> create table user_pay_test2 like user_pay_test;
Query OK, 0 rows affected (1.691 sec)

感觉不是统计信息，空表耗时也有点久，但是分好区的表再复制一个出来就很快，就很神奇

1 个赞
10

这个 warning 是啥？show warnings;

11

image
image3484×1042 212 KB

我这边观察下来还行，不确定为啥你的那么慢。 48s 是有点久了。
我这边是 v7.5.1 版本，我倾斜 TiDB 是有什么可以优化的地方。我看看研发有没有能看的 :thinking:。

1 个赞
12

感觉像是历史版本问题，看一下gc时间设置的多久

1 个赞
13 
MySQL [dw_raw]> show warnings;
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                                                                            |
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------+
| Warning | 1105 | The statistics of new partitions will be outdated after reorganizing partitions. Please use 'ANALYZE TABLE' statement if you want to update it now |
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.016 sec)


MySQL [dw_raw]> select version();
+--------------------+
| version()          |
+--------------------+
| 8.0.11-TiDB-v7.5.1 |
+--------------------+
1 row in set (0.024 sec)

MySQL [dw_raw]> select @@global.tidb_gc_life_time;
+----------------------------+
| @@global.tidb_gc_life_time |
+----------------------------+
| 24h0m0s                    |
+----------------------------+
1 row in set (0.026 sec)

版本是7.5.1，gc24h

1 个赞
14

这里转成 partition 表有几件事情要做：split region（每个 partition 1 个 region）， 搬移数据， 添加索引。数据大时间就会更久。 可能还有其他操作
你的 SQL 要一次性分区 100 多个，所以慢预期。
具体有没有优化空间，后续会再看看。

1 个赞
15

img_v3_029b_01999694-b808-474c-b631-e4e9c5aff08g
img_v3_029b_01999694-b808-474c-b631-e4e9c5aff08g1432×494 125 KB

而且 MySQL 上来说 也是线性的，只是要快一些。

16

GC 24H 有点夸张吧？表改动如果频繁，这得有多少个MVCC版本

17

表结构是常年不动的，这次分区的起因也是有个表过大，占了集群1/3的存储，而且最多只需要半年内的数据，脚本定时清理又影响到了集群性能，正好新版本也支持了转成分区表，这才考虑先分区，以后直接按分区清理

18

24h不算长，论坛看到长的72h的