GCP平台MySQL Dump导入速度过慢问题排查与优化咨询

我之前也踩过一模一样的坑——相同的Dump文件在配置相近的服务器上导入速度差了好几倍，那种等着超时的感觉真的糟透了。咱们一步步来排查和优化，应该能把速度提上去：

一、先核对基础环境差异 #

虽然你说配置相近，但细节往往是关键：

• 磁盘类型与IO性能：Hetzner的默认服务器大多用SSD，你的目标服务器是不是HDD？用这个命令测下磁盘写速度：

  dd if=/dev/zero of=test_file bs=1G count=1 oflag=direct
  

  对比两台服务器的输出，要是你的磁盘速度只有Hetzner的1/10，那慢是正常的。
• MySQL版本与配置基线：确认目标服务器的MySQL也是5.7吗？不同版本的默认参数、语法兼容处理可能有差异；另外Hetzner的默认配置会不会偷偷做了基础优化？可以用mysqld --help --verbose对比两台机器的默认参数。

二、优化导入命令本身 #

别用默认的mysql < file.sql，试试这些参数组合，效果立竿见影：

• 带--quick --disable-keys参数，减少内存占用并临时禁用索引：

  mysql --quick --disable-keys -u username -p database < file.sql
  

• 导入前手动关闭事务自动提交、外键与唯一检查（可以把这些命令加到Dump文件开头，或者先登录MySQL执行）：

  SET autocommit=0;
  SET foreign_key_checks=0;
  SET unique_checks=0;
  

  导入完成后再执行：

  COMMIT;
  SET foreign_key_checks=1;
  SET unique_checks=1;
  

• 用source命令代替重定向：先登录MySQL，再执行source /path/to/file.sql;，不仅能看到实时进度，有时候比重定向更稳定。

三、临时调整MySQL配置（导入后可改回） #

针对InnoDB引擎做临时优化，不用重启服务：

• 调大innodb_buffer_pool_size：如果服务器内存够，设为物理内存的50%-70%，比如8G内存就设为5G：

  SET GLOBAL innodb_buffer_pool_size = 5*1024*1024*1024;
  

• 临时降低日志刷写频率：把innodb_flush_log_at_trx_commit设为2，牺牲一点临时安全性换速度，导入完改回1：

  SET GLOBAL innodb_flush_log_at_trx_commit = 2;
  

• 要是能重启MySQL，建议提前调大innodb_log_file_size（比如设为1G）：修改my.cnf后，停止MySQL，删除旧的ib_logfile0和ib_logfile1，再启动服务，这个能大幅减少日志切换的开销。

四、检查Dump文件本身的问题 #

• 确认Dump是用mysqldump --opt导出的：--opt包含了--extended-insert（批量插入）、--disable-keys等一堆优化参数，导出的文件导入速度会快很多。如果你的Dump没加这个参数，重新导出一次试试。
• 看Dump里的INSERT语句：要是都是单条INSERT INTO table VALUES (...);，那肯定慢，改成批量INSERT INTO table VALUES (...), (...), (...);能提升数倍速度——可以用脚本批量替换，或者重新导出时加--extended-insert=TRUE。

五、系统层面排查 #

• 导入时用top、iostat看负载：是不是有其他进程占了CPU、内存或者磁盘IO？比如磁盘IO使用率100%的话，导入肯定卡。
• 查看MySQL错误日志：tail -f /var/log/mysql/error.log，有没有锁等待、磁盘空间不足、权限警告之类的问题，这些都可能拖慢导入速度。
• 检查文件系统：比如是不是用了ext3（换成ext4会好很多），或者开启了磁盘加密、配额等功能，这些都会影响写入性能。

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