用mysql命令行恢复mysqldump备份需先创建目标库并确保字符集匹配、权限充足；若备份含CREATE DATABASE语句且库已存在会报错1007；大文件恢复需调大max-allowed-packet、net-read/write-timeout参数。
用 mysql 命令行恢复 mysqldump 备份文件
能直接恢复，但必须确保目标数据库已存在、字符集匹配、权限足够。最常卡在权限不足或数据库没提前创建。
- 先手动创建空库：
mysql -u root -p -e "CREATE DATABASE \`mydb\` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" - 确认备份文件里没有
CREATE DATABASE语句（如果有，且目标库已存在，会报错ERROR 1007 (HY000): Can't create database 'mydb'; database exists） - 恢复命令很简单：
mysql -u root -p mydb ，注意这里 <code>mydb是数据库名，不是文件名 - 如果备份时用了
--single-transaction或--skip-lock-tables，恢复时完全不影响，这些只影响导出逻辑
遇到 ERROR 1062 Duplicate entry 怎么办
说明表里已有数据，而 dump 文件里又包含 INSERT 语句（默认行为）。不是数据坏了，是插入策略冲突。
- 临时清空表再恢复：
mysql -u root -p -e "TRUNCATE TABLE mydb.users;"，但要小心外键约束，建议先关掉：SET FOREIGN_KEY_CHECKS=0; - 更稳妥的是重导备份：下次用
mysqldump --replace或--insert-ignore，这样生成的INSERT会变成REPLACE INTO或INSERT IGNORE - 别用
mysqldump --add-drop-table后直接恢复到非空库——它会在每个表前加DROP TABLE，但不会自动重建，容易中途失败
中文乱码、emoji 插不进去怎么办
根本原因是 dump 文件保存编码和 MySQL 服务端/客户端编码不一致，不是“恢复失败”，而是字符被截断或替换成 ?。
- 检查备份文件实际编码：
file -i backup.sql，常见是utf-8或utf-8-with-bom；BOM 会导致 mysql 客户端解析出错，用sed -i '1s/^\xEF\xBB\xBF//' backup.sql清掉 - 恢复时强制指定字符集：
mysql --default-character-set=utf8mb4 -u root -p mydb ，不能只靠 <code>SET NAMES - 确认 MySQL 服务端配置：
character_set_server和collation_server应为utf8mb4，否则即使命令行指定了，建表时仍可能用错默认值
大文件（>100MB）恢复卡住或超时
不是命令错了，是 MySQL 默认限制了单次执行长度和网络等待时间，尤其通过管道导入时容易中断。
- 增大关键参数：
mysql --max-allowed-packet=512M --net-read-timeout=3600 --net-write-timeout=3600 -u root -p mydb - 避免 shell 管道瓶颈：改用
source命令，在 mysql 客户端内执行：mysql -u root -p mydb<br>mysql> source /path/to/backup.sql;
- 如果备份含大量
INSERT，可提前在 SQL 文件头加SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;，末尾再COMMIT;，能提速 3–5 倍
--skip-extended-insert，恢复就慢但好调试；导出没加 --routines，恢复完过程、函数就没了。这些细节不报错，但结果不对。 
