常见原因是路径错误，MySQL只识别绝对路径或当前shell目录下的相对路径；应先用pwd和ls确认文件位置，推荐使用绝对路径导入。
mysql 命令直接导入 SQL 文件失败，提示 No such file or directory
常见原因是 shell 当前工作目录和文件路径没对上，mysql 不会自动帮你找文件——它只认你写的**绝对路径**或**当前 shell 所在目录下的相对路径**。
- 先用
pwd确认当前路径，再用ls -l your_file.sql看文件是否真在那儿 - 推荐一律用绝对路径：
mysql -u root -p database_name - 如果 SQL 文件在远程服务器，别用图形工具拖过去就完事；用
scp或rsync传到目标机器的某个确定路径，再从那里导入 -
source命令（在 MySQL 客户端里）也受路径限制：必须是 MySQL 服务进程有读权限的路径，且默认只认/var/lib/mysql-files/下的文件（取决于secure_file_priv配置）
导入大 SQL 文件卡住、超时或报 MySQL server has gone away
不是网络断了，大概率是 MySQL 服务端主动切断了连接——因为单条语句太长、或整个导入过程太久，触发了 max_allowed_packet 或 wait_timeout 限制。
- 导入前先检查并临时调高限制：
mysql -u root -p -e "SET GLOBAL max_allowed_packet = 512*1024*1024; SET GLOBAL wait_timeout = 28800;" - 避免用重定向（
）导入超大文件，改用 <code>mysqlimport或分段执行：split -l 1000 bigfile.sql part_，再逐个mysql -u ... - SQL 文件里如果有
CREATE DATABASE或USE，确保目标库已存在且权限正确；否则会静默跳过或报错中断 - 注意字符集：如果原库是
utf8mb4，而导入命令没指定，默认可能走latin1，导致乱码或解析失败。加--default-character-set=utf8mb4
SQL 文件含 DROP TABLE 或 CREATE TABLE IF NOT EXISTS，但表结构不一致
这类语句看似安全，实则容易埋雷：比如字段类型变了、索引名重复、外键约束冲突，都会让导入中途失败，而且错误位置难定位。
- 导入前先用
mysql -u ... -D database_name -e "SHOW TABLES;"确认目标库是否为空或是否需要清理 - 如果要保留旧数据，别盲目执行全量
DROP；改用mysqldump --no-create-info导出纯数据，再配合--ignore-table跳过不想覆盖的表 - 遇到外键报错（如
Cannot add or update a child row），临时关掉检查：SET FOREIGN_KEY_CHECKS = 0;，导入完再开回来 - 用
head -n 50 your_file.sql快速看开头有没有SET SQL_MODE或SET TIME_ZONE，这些会影响时间字段解析行为
用 mysqldump 备份的文件，还原时提示 Unknown collation: 'utf8mb4_0900_ai_ci'
这是 MySQL 8.0+ 默认排序规则，老版本（如 5.7）不认识，直接报错退出。
- 最稳解法：在导出时就兼容低版本：
mysqldump --compatible=mysql40 --default-character-set=utf8 - 或者手动替换 SQL 文件里的排序规则：
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' backup.sql - 注意
utf8mb4字符集本身 MySQL 5.5.3+ 就支持，问题只出在新排序规则名；别误删整个COLLATE子句，否则字段排序行为会变 - 如果备份里用了 JSON 字段或 CTE（
WITH查询），而目标 MySQL 版本太低，也会报语法错误——得先查清两端版本差异再操作
实际还原最耗时间的往往不是命令本身，而是没提前确认字符集、排序规则、版本兼容性这三件事。尤其跨大版本迁移时，光看文件能执行不报错，不代表数据逻辑没歪。
