dumpling 导出数据慢

🪐 TiDB 技术问题
1

背景: tidb dumping 导出数据发现针对分区表的导出越来越慢, dumpling 版本 6.5.10

分区表表结构，共 106 个分区

Create Table: CREATE TABLE t1 (
a bigint(20) unsigned NOT NULL AUTO_INCREMENT,
b bigint(20) NOT NULL COMMENT ‘xx’,
…
create_date date NOT NULL COMMENT ‘xx’,
create_time datetime DEFAULT NULL,
PRIMARY KEY (a,create_date) /*T![clustered_index] NONCLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=xxx /*T! SHARD_ROW_ID_BITS=4 */ COMMENT=‘xxx’
PARTITION BY RANGE COLUMNS(create_date)
(PARTITION p20240419 VALUES LESS THAN (‘20240420’),
PARTITION p20240420 VALUES LESS THAN (‘20240421’),
…
PARTITION p20240802 VALUES LESS THAN (‘20240803’))

发现执行越来越慢：

image
image1914×498 90.9 KB

尝试过：

  1. 修改 GC 时间 10m
  2. 收集统计信息

在 dump 慢时，发现 SQL 在这步的耗时较长（大约 100s+）

SELECT * FROM xxx.t1 WHERE _tidb_rowid>=8070450535665104911 ORDER BY _tidb_rowid

SELECT * FROM xx.t1 WHERE _tidb_rowid>=6341068278783285469 and _tidb_rowid<6917529031091403347 ORDER BY _tidb_rowid

不确定是什么问题，想请教下，多谢

2

表是按create_date进行分区的，dumpling可能在导出过程中需要扫描所有的分区。随着分区数量的增加，扫描所有分区的开销也会增大，导致导出速度变慢。

3

导出大量分区时，如果每个分区都独立进行导出，且没有合理的并发控制，可能会占用大量资源

4

看下这慢sql里执行计划

5

我想知道dumping 导出分区表，不是按分区导出的吗？走到 SELECT * FROM xx .t1 WHERE _tidb_rowid >=6341068278783285469 and _tidb_rowid <6917529031091403347 ORDER BY _tidb_rowid这里的话，是走单个分区吗？

6

分别单个分区导出试试？并行开起来

7
  1. 合理设置 --rows 参数：这个参数用来指定单个文件的最大行数，通过合理设置 --rows 参数可以划分数据区块，减少 TiDB 扫描数据的内存开销，同时开启表内并发提高导出效率。在实践中，配置 --rows=200000 一般能够兼顾并发效果与导出速度11。
  2. 针对 TiDB v5.0 及以上版本的优化 ：TiDB v5.0 开始支持聚簇索引，不再使用 _tidb_rowid 列。可以使用 SELECT fields FROM table TABLESAMPLE REGIONS() 语法获取每个 region 的第一行聚簇索引的各列值，用于均匀划分 chunk
8

Dashboard或者Explain Aanlyze看下实际执行计划，看下具体慢在哪一步

9

可以看下 tikv 整体资源有没有用满，没有的话可以把并发开大点试试

10

可以加一个--rows 1000 参数，dumpling 在备份 TiDB 时候，如果加了-r，会直接按照 region 的上下界来并发导出，速度特别快还比较均匀。