Azure托管MariaDB迁移时mysqldump恢复性能低下的优化方案咨询

看起来你在把本地MariaDB迁移到Azure托管服务时遇到了恢复速度瓶颈——25GB的库要花2小时，而且VM和托管DB的资源都没跑满，确实让人头疼。结合你的环境参数和Azure MariaDB的配置限制，我给你几个针对性的优化建议：

一、优化恢复时的客户端命令参数 #

• 除了设置autocommit=0，恢复前一定要加上--disable-keys参数，它会暂时关闭非唯一索引的更新，等所有数据插入完成后再批量重建索引，能大幅减少IO操作开销。命令示例：

  mysql --disable-keys --init-command="SET autocommit=0;SET FOREIGN_KEY_CHECKS=0;SET UNIQUE_CHECKS=0;" -u your_user -p your_db < dump.sql
  

  这里顺便把外键检查、唯一键检查也临时关掉，避免每次插入都做关联验证，进一步节省CPU和IO资源。
• 调大max_allowed_packet参数，比如设置为--max_allowed_packet=64M，确保大的批量插入语句不会因为数据包大小限制被截断，同时提升传输效率。
• 加上--quick参数，让MySQL客户端不缓存查询结果，直接把数据发送到服务器，减少本地VM的内存占用，让更多资源集中在数据传输和处理上。

二、改用并行导入工具替代单线程mysqldump #

mysqldump默认是单线程恢复，这很可能是你资源没跑满但速度上不去的核心原因。推荐用mydumper/myloader工具，它支持多线程并行导出和导入：

• 导出时用mydumper可以按表分文件，同时开启多个线程导出，生成的文件更适合并行导入；
• 导入时用myloader指定多个线程（比如和CPU核心数匹配，4核就设4-8线程），同时插入不同的表，能充分利用托管DB的CPU和IO资源。
• 注意：并行导入前要确保表之间没有外键依赖，或者像上面那样临时关闭外键检查，避免出现关联报错。

三、排查网络与存储IO的潜在瓶颈 #

• 确认你的VM和Azure托管MariaDB是否在同一区域：跨区域的网络延迟和带宽限制会严重拖慢数据传输，同一区域内的内网传输速度要快得多，这可能是你当前只有9MB/s吞吐量的原因之一。
• 检查托管DB的存储IOPS：你当前的配置是450 IOPS，单线程恢复可能没法把IO跑满，但并行导入后应该能更充分利用这些IO资源。如果并行导入后IO Percent接近100%，可以考虑临时升级存储的IOPS配额，恢复完成后再降回去，这样能在短维护窗口内完成迁移。

四、导出阶段的前置优化（如果还能重新导出的话） #

如果还能重新生成dump文件，建议调整导出参数让后续恢复更高效：

• 加上--extended-insert（默认开启，但可以明确指定），让导出的INSERT语句是批量插入的形式，减少事务提交次数；
• 用--single-transaction参数导出InnoDB数据，避免锁表的同时，生成的dump文件一致性更好，恢复时也更顺畅；
• 不要用--lock-tables（对InnoDB没必要），避免影响本地业务的同时，导出效率也更高。

总结一下，最立竿见影的应该是改用myloader并行导入，再配合临时关闭各种检查、优化客户端参数，大概率能把恢复时间压缩到半小时以内。如果网络跨区域的话，先把VM移到同一区域再操作，效果会更明显。

备注：内容来源于stack exchange，提问作者Alex T.