8TB未分区MySQL表查询慢 高效分区迁移方案及工具咨询

你之前手写循环导入慢的核心问题是走了逐行/小批量事务写入，每条提交都要刷日志、更新索引，随机IO占比极高，8TB数据跑几周都正常，还容易打满生产库资源。下面是生产验证过的高性价比方案，比你现有方案效率高10倍以上：

高吞吐迁移实现路径 #

不要用逐行INSERT的逻辑，优先选批量物理/半物理导入方式：

• 优先选批量LOAD DATA+分区对齐导入方案，兼容性最好，不需要特殊版本支持：
  1. 先在同实例建好和原表结构完全一致的分区新表，确认字段、索引、字符集、行格式和原表100%匹配，分区规则提前按查询场景定好（比如按时间范围分区就别用哈希，不然查询裁剪不生效等于白做）。
  2. 按新表的单分区粒度切分原表数据范围，每次只导对应一个分区的数据集，用SELECT ... INTO OUTFILE直接导出CSV格式，加SQL_NO_CACHE避免占用业务用的Buffer Pool，单批数据量控制在50G~100G，和单分区大小对齐。
  3. 单批导出完成后，临时调大当前会话的bulk_insert_buffer_size到2G~4G，设置innodb_flush_log_at_trx_commit=2，用LOAD DATA INFILE把CSV文件直接导入新表对应的指定分区，这个命令是MySQL原生批量加载逻辑，会延迟更新二级索引，导入完成后批量构建索引，比逐行插入快一个数量级。
  4. 每导完一个分区立刻做数据校验，对比原表对应范围的行数、核心数值字段的汇总值，不要等全表导完再校验，出错返工成本极高。
• 如果你的环境是MySQL 8.0.27及以上版本，磁盘剩余空间足够，可以用可传输表空间方案：按分区范围拆分原表的独立表空间文件，直接物理拷贝到新表分区目录下挂载导入，全程不需要逻辑解析数据，8TB数据在SSD盘上几个小时就能跑完，只是对表结构一致性要求极高，操作前必须做全量备份。

所有操作必须先在从库完整跑通全流程，测算单批耗时、资源占用，再回主库低峰期执行。导入过程中实时监控IOPS、CPU、主从延迟，超过阈值立刻暂停，绝对不能跑无流控的全表大事务，会撑爆undo表空间，还会阻塞正常业务写入。

可替代手写Python脚本的成熟工具 #

完全没必要自己写循环脚本，成熟工具已经把断点续传、流控、数据校验、异常回滚这些坑踩完了，稳定性和效率都比自研脚本高：

• 首推pt-archiver，是Percona工具集里专门做大表迁移归档的组件，直接指定源表、目标分区表，配置按主键范围切分批次（单批1万行左右，不会产生长事务），自带主从延迟检测、IO流控，超过你设置的安全阈值自动暂停，支持--bulk-insert批量写入模式，导数据的时候不会删原表数据，等全量校验完再处理原表，比手写Python脚本稳得多，速度快3~5倍。
• 不想装额外工具的话，直接用MySQL自带的mysqldump --tab按主键范围分批导出CSV格式文件，再用mysqlimport批量导入对应分区，全程不需要自己写数据解析、重连、断点续传逻辑，足够应对8TB级别的迁移。

切流注意事项 #

• 全量数据导完后不要直接切表，先补增量：记录全量导入完成时原表的GTID位点或者最大主键ID，把这个位点之后原表的增删改数据同步到新分区表，两边数据完全一致后，用RENAME TABLE 原表名 TO 备份表名, 新分区表名 TO 原业务表名秒级切流，切完观察1~2小时业务查询无异常，再把老备份表归档删除。
• 如果你之前判定“原位重分区不可行”是怕锁表，MySQL 8.0之后支持ALGORITHM=INPLACE, LOCK=NONE的在线DDL加分区，只是8TB表做这个操作需要预留至少1.5倍表大小的临时磁盘空间，会占用一定IO资源，可以先在从库测下实际耗时和资源占用，如果能接受的话比迁新表流程更简单。

内容的提问来源于stack exchange，提问作者kikee1222