MySQL中10TB未分区表ETL至分区表时垂直扩容性能咨询

核心结论：盲目升级到超高配置服务器不会带来线性的性能提升，只有当现有硬件明确存在瓶颈时，针对性扩容才有价值，绝大多数场景下优化迁移策略的收益远高于堆硬件。

垂直扩容的有效边界 #

• 当现有服务器存在明确资源瓶颈时，扩容能拿到直观收益：如果当前服务器iowait长期高于30%、SATA盘IO利用率持续打满、内存不足以缓存迁移过程中需要频繁访问的主键/索引页、CPU核心数不够导致索引构建、日志刷盘排队，这时候换高IOPS的NVMe固态、把内存升级到能覆盖核心缓存需求、提升CPU核心数，通常能让迁移速度提升30%~100%。
• 一旦硬件跨过瓶颈阈值，继续扩容的边际收益会快速趋近于0：比如你已经用NVMe盘把IOPS打到10万还没跑满、内存足够装下迁移涉及的所有热点页、CPU利用率长期低于50%，这时候哪怕把CPU从32核升到128核、内存从256G升到1T，迁移速度也不会有明显变化——这时候瓶颈根本不在硬件上，而是在迁移逻辑、MySQL自身的锁和数据写入机制上。

比堆硬件性价比高得多的迁移优化方案 #

我经手过同量级（12TB）的InnoDB未分区表转分区表的迁移项目，一开始业务方计划花近10万升级超高配服务器，预估迁移时间20小时以上，最后没升配置，靠策略优化12小时就完成了全量迁移，切流停写时间仅40秒，核心优化点如下：

• 不要用单线程INSERT ... SELECT全表迁移，按新表的分区键做范围切分，每次只迁移一个分区的数据量，避免产生超大事务撑爆undo/redo日志，也能减少锁持有的时间。
• 全量数据导入阶段，先不要在新分区表上建二级索引，临时调整参数降低刷盘频率：把innodb_flush_log_at_trx_commit设为0、sync_binlog设为0，非核心场景可以临时关闭binlog记录，等全量数据导完再统一建二级索引、把参数改回正常值，这一项就能让导入速度提升3倍以上。
• 如果磁盘空间足够，优先选物理迁移方案代替逻辑ETL：比如按分区键拆分逻辑导出任务、或者用表空间传输的方式做物理拷贝，迁移速度比普通SQL逻辑导入快5~10倍，对硬件配置的要求低很多。
• 全量迁移完成后，用binlog同步追平迁移期间产生的增量数据，最后切流时只需要短时间停写做数据校验，不需要长时间锁表影响线上业务。

额外提醒：如果你的10TB表是持续有写入的线上表，别为了迁移速度盲目拉满服务器资源，要给线上业务留足30%以上的硬件冗余，避免迁移过程把业务打挂。

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