数据库导入中途断开

一句话结论：大体积 SQL 别依赖网页工具导入，改走命令行，中断问题基本就绕开了。 ## 为什么网页导入容易断 phpMyAdmin 这类网页管理工具导入时，要经过上传限制、PHP 执行超时、内存上限三道关卡。SQL 文件超过几十 MB，任何一个限制都会让导入半途而废，而且页面上往往只有一个笼统的失败提示，具体卡在哪很难判断。 还有个连带问题：中断之后库里只剩半截数据，重新导入前先删库重建或清空表，带着残留续导会产生一堆主键冲突报错，越导越乱。 ## 命令行导入的完整流程 把 SQL 文件先传到服务器上，比如放在 /root/backup.sql，然后： mysql -u root -p mydb < /root/backup.sql 几个 GB 的文件导入时间较长，建议放进 screen 或 tmux（远程会话保持工具）里跑，SSH 断开也不受影响： screen -S import mysql -u root -p mydb < /root/backup.sql 想看进度可以借助 pv（管道流速查看工具）： pv /root/backup.sql | mysql -u root -p mydb 压缩包不用先解压，管道直连更省磁盘： gunzip < backup.sql.gz | mysql -u root -p mydb 远程导入更稳的姿势是先把文件传到服务器本机再导：走 mysql -h 远程直导时，网络抖动会把中断风险原样带回来。想提速可以临时调大 InnoDB 的日志刷新参数，但导完必须改回默认值，安全参数不要长期让路。 ## 文件实在太大时分卷 超过十 GB 的导出文件，可以在源头上分卷：按表拆分最稳妥，mysqldump 逐表导出后逐个导入，哪张表出问题重导哪张。也可以用 split 按行切块，split -l 100000 backup.sql part_，再按顺序逐个导入，失败的那块单独重跑。 导出端配套优化同样有用：mysqldump 加 --single-transaction 保证一致性、--quick 流式输出，导出侧顺了，导入侧压力也小。导入完成后做两件事核对：查表数量和关键表行数是否与预期一致；检查导入过程的报错输出里有没有被跳过的语句。平时把备份文件按大小分目录存放，超大的单独标注，需要演练导入时就不用临时摸索。命令行方式看着朴素，但断点少、可重试、进度可见，报错还会直接打到终端，逐条读比网页的笼统提示有料得多，错在哪一句一目了然。