关键问题在于 --where 里的过滤没有让 dumpling 高效分块。dumpling 默认按主键（或 _tidb_rowid）做区间分块并发导出，你加了 update_time < ‘xxx’ 这种非主键条件后，它没法用 update_time 索引来切分块，只能对全表做区间扫描再逐行判断 where，所以日志里 estimate total rows 显示的是全量 64 亿——这个值是 dumpling 估算的整表行数（用于分块规划），不是你条件命中的行数。这就是慢的根因：等于全表扫 64 亿行去筛你那 689 万。优化方向：1）如果导出目的是按 update_time 归档，考虑用主键范围配合，或者先确认表是否按 update_time 做了分区，用分区裁剪导出对应分区；2）加大 -t（并发）意义不大，因为瓶颈在全表扫描；3）对这种大宽表 + 条件导出，更适合直接用 SQL（SELECT … WHERE update_time < xxx，走 update_time 索引）配合 SELECT INTO OUTFILE 或分批导出，让优化器用上索引；4）也可以用 --sql 参数给 dumpling 传一条能走索引的自定义查询。核心是让扫描走 update_time 索引而不是全表分块。
1 个赞