MySQL怎么从SQL备份脚本快速恢复导入数据-LINUX-PHP中文网

MySQL大文件导入需调大max_allowed_packet等参数防卡顿，关外键、修自增、补字符集、过滤表数据可提速避坑。

mysql怎么从sql备份脚本快速恢复导入数据

能直接用 mysql 命令行导入，但“快”不等于“无脑执行”——大文件卡住、中文乱码、外键报错、自增ID重置，都是 5 分钟内就能踩到的坑。

默认的 max_allowed_packet 和 innodb_log_file_size 会拦住百 MB 级以上的备份文件，导入中途静默失败是常态。

先查当前限制：mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"，常见值是 4MB，而 1GB 的备份文件根本进不去
临时加大（命令行生效）：mysql --max_allowed_packet=512M -u root -p mydb
如果还报 Lost connection，加 --net_buffer_length=1M 缓冲；InnoDB 大事务失败则需调大 innodb_log_file_size（改配置文件后要重启 MySQL）
压缩包别解压：用 zcat backup.sql.gz | mysql --max_allowed_packet=512M -u root -p mydb，省磁盘又避免中间文件损坏

导出时没指定字符集，恢复时就容易出现 Incorrect string value 或字段变 ???，甚至 Unknown character set: 'utf8mb4' 这类报错。

检查备份文件头：head -n 20 backup.sql | grep "CHARACTER SET"，确认是否含 DEFAULT CHARSET=utf8mb4
导出时应带 --default-character-set=utf8mb4，恢复时也显式指定：mysql --default-character-set=utf8mb4 -u root -p mydb
若备份里有 CREATE DATABASE 语句但目标库已存在，会因字符集冲突失败；建议提前建库：CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

恢复完发现新插入报 Cannot add or update a child row，或主键从 1 开始重复，说明外键和 AUTO_INCREMENT 没被正确还原。

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

导入前关外键检查：SET FOREIGN_KEY_CHECKS = 0;，导入后再开：SET FOREIGN_KEY_CHECKS = 1;（注意：不能只在 SQL 文件开头加，得在 mysql 客户端里先执行，或把这两句塞进备份文件最前面）
mysqldump 默认不导出自增值，恢复后 AUTO_INCREMENT 会重置为 1；加 --skip-auto-increment 无效，正确做法是导出时用 --single-transaction + --skip-triggers 配合 --hex-blob，但更稳的是恢复后手动修正：ALTER TABLE t1 AUTO_INCREMENT = 123456;（查原表 SELECT MAX(id) 得到）
触发器、存储过程默认不导出，加 --routines 和 --triggers 参数才包含

全量备份文件几 GB，你只想救一张 orders 表？别全量导入再删表，效率低还污染数据。

用 sed 或 awk 提取段落：sed -n '/^CREATE TABLE `orders`/,/^\$/p' full_backup.sql > orders_only.sql（注意匹配结尾空行或下一个 CREATE TABLE）
更准的方法是用 grep -A 2000 "CREATE TABLE \`orders\`" full_backup.sql | grep -B 2000 "^INSERT INTO \`orders\`" > orders_restore.sql，再补上 SET FOREIGN_KEY_CHECKS=0; 开头
如果备份用了 --add-drop-table，恢复前确保目标库没有同名表，否则 DROP TABLE 会误删其他数据