导入前必须确认三件事：目标MySQL实例已启动、导出参数是否含非法语句（如--all-databases会生成information_schema建库语句）、当前用户具备CREATE/INSERT/ALTER权限。
导入前必须确认的三件事
全库导入不是“把文件扔进去就完事”，mysqldump导出的 sql 文件本质是一堆 create database、create table 和 insert 语句，执行失败往往卡在最基础的环境假设上。
- 目标 MySQL 实例是否已启动？用
mysqladmin ping -u root -p快速验证 - 导出时用的是
--databases还是--all-databases？前者生成的 SQL 包含CREATE DATABASE，后者还带CREATE DATABASE `information_schema`这种非法语句——直接执行必报错ERROR 1044 (42000) - 当前登录用户是否有
CREATE、INSERT、ALTER权限？特别是恢复到新实例时，root@localhost不等于有所有权限（比如没开--skip-grant-tables）
用 mysql 命令行导入：最简路径但易忽略编码
这是最常用也最容易翻车的方式。核心命令是 mysql -u user -p ，但默认字符集不匹配会导致中文变 <code>??? 或直接报错 ERROR 1366 (HY000)。
- 先查导出文件的编码：用
file -i backup.sql看charset=后面是什么（常见utf-8或gbk） - 导入时强制指定客户端编码：
mysql -u user -p --default-character-set=utf8mb4 （注意不是 <code>utf8，MySQL 的utf8是阉割版） - 如果备份里有
SET NAMES latin1这类语句，它会覆盖命令行参数——此时得先用sed -i 's/SET NAMES.*/SET NAMES utf8mb4;/g' backup.sql清洗
跳过特定库或表：避免 information_schema 或系统库报错
mysqldump --all-databases 导出的文件开头总有一段对 information_schema、performance_schema、sys 的操作，这些库不能被 DROP 或 INSERT，强行执行会中断整个导入。
- 临时方案：用
grep -v "CREATE DATABASE.*information_schema\|CREATE DATABASE.*performance_schema\|CREATE DATABASE.*sys" backup.sql > clean.sql过滤掉建库语句 - 更稳妥的做法是分库导出：下次备份改用
mysqldump --databases db1 db2 db3 -u user -p > backup.sql，完全避开系统库 - 如果已经导入失败卡住，别急着重跑——检查
mysql -u user -p -e "SHOW DATABASES;"，确认哪些库实际建成了，再手动DROP DATABASE干净后重试
大文件导入慢或中断：别硬扛，换 streaming 模式
超过 100MB 的 SQL 文件用重定向导入，常遇到超时、内存溢出或连接中断。MySQL 默认的 max_allowed_packet 和 wait_timeout 都不够用，但改全局配置风险高。
- 优先用
source命令，在 MySQL 客户端内执行：mysql -u user -p -e "source /path/to/backup.sql"，它按语句流式执行，不依赖 shell 缓冲区 - 若仍超时，进客户端后先调参：
SET GLOBAL max_allowed_packet = 512*1024*1024;和SET SESSION wait_timeout = 28800; - 极端情况（如几百 GB）：用
mysqlimport配合--fields-terminated-by导入 CSV，但这要求原始 dump 是--tab格式，普通 SQL 文件不适用
真正麻烦的不是命令敲不对，而是导出时没加 --set-gtid-purged=OFF（GTID 环境下）或没关 foreign_key_checks，结果导入一半被外键拦住——这种问题得回源头改 dump 参数，补救成本远高于预防。
