MySQL 导入大 SQL 失败：连接中断、大小限制与断点误区
大 SQL 导入失败后，最危险的操作之一是从报错行附近随便继续执行。之前的语句可能已经提交，当前语句可能还没有完成，文件中的事务与分隔符也未必按行划分。本文针对 MySQL 8.4 命令行恢复，优先在独立测试目标中定位问题。
先保留错误和导入上下文
记录导入命令、客户端与服务端版本、开始时间、完整错误码及退出状态。区分连接断开、语法不兼容、权限不足、重复对象和磁盘不足，不能把任何中断都归结为文件太大。
确认目标数据库是否已经含有部分内容，并暂停其他会向它写入的任务。失败文件应保留原始副本和校验值，避免一边编辑一边重试后再也无法确定执行过什么。生产库有原数据时，先停止不明确的恢复操作。
数据包限制看的是单次内容
max_allowed_packet 约束的不是整个 SQL 文件总大小。某条很大的 INSERT、长字符串或二进制数据可能超过限制，即使总文件并不特别大；相反，一个巨大的文件由很多合理大小的语句组成，也可能正常导入。
客户端与服务器端都可能有相关限制，修改一端未必解决问题。先查看实际设置与失败语句大小，再选择有限且合理的值，并评估内存影响，不能简单改成最大值当作通用修复。MySQL 数据包过大说明
如果能重新导出，可以评估更适合恢复的导出批量与格式。拆分时应使用理解 SQL 结构的工具，不能按固定字符数或文件行数截断，避免破坏字符串、事务或存储程序定义。
同时检查连接、磁盘与兼容性
导入时间长可能暴露 SSH 会话中断、网络不稳定或任务管理问题。应使用有明确日志和退出状态的受控执行方式，不依赖管理员电脑保持连接。服务端错误日志还能帮助区分服务器重启、资源耗尽与普通客户端断开。
磁盘需要容纳数据、索引和导入过程产生的额外写入，不能只比较 SQL 文件大小与剩余容量。还应核对字符集、排序规则、SQL 模式、对象定义和版本兼容性；把不兼容语句强行忽略，可能留下缺失约束或逻辑错误。
明确目标后再执行恢复
下面示例仅用于已经准备好的独立恢复库，终端采用支持输入重定向的 Linux shell：
mysql --user=restore_user --password --database=site_restore < /srv/backups/site.sql
事先检查可信 SQL 是否包含 USE、完整数据库名或其他会改变作用范围的语句。命令里的默认数据库并不能强制把文件中的所有操作都限制在那里。不要对未经审查的外部 SQL 直接执行恢复。MySQL 批处理执行说明
避免使用继续忽略错误的选项来制造“导入结束”的假象。需要收集错误时应保留完整日志，并以明确的成功条件判断，而不是只看终端有没有回到提示符。
失败后重新建立可解释的状态
重新导入之前，要明确是使用新的空恢复目标，还是已有经过验证的续传方案。部分导入并不保证整次操作可统一回滚，DDL 和不同事务边界会影响结果。不能直接重复执行全部文件并假定不会覆盖、重复或冲突。
修复根因后，在隔离环境重新验证对象、行数抽样、索引与应用流程，再规划正式恢复或切换。保留原生产数据和可恢复备份直到验收完成。把最终参数、耗时和遇到的边界写入恢复说明，下一次大文件导入才不会再次变成临时试错。