能恢复，但必须满足三个前提：SQL文件本身有效、当前用户有对应权限、目标数据库已存在或SQL里自带CREATE DATABASE；执行source前需确认文件含CREATE DATABASE语句、已USE目标库、路径为绝对路径且MySQL进程可读。
能恢复，但必须满足三个前提：SQL文件本身有效、当前用户有对应权限、目标数据库已存在或SQL里自带CREATE DATABASE。
source命令执行前必须确认的三件事
很多人执行source后报错“Unknown database”，其实不是命令错了，而是环境没准备好：
- 检查SQL文件是否含
CREATE DATABASE语句：用head -n 20 backup.sql看开头。不含的话，得先手动建库：CREATE DATABASE IF NOT EXISTS mydb DEFAULT CHARACTER SET utf8mb4; - 确认已
USE到目标库：USE mydb;——source不会自动切换数据库，它只在当前库上下文里执行SQL - 路径必须是绝对路径，且MySQL进程有读取权限。Linux下常见错误是路径用了相对路径或含中文，比如
source ./backup.sql会失败；正确写法是source /home/user/backup.sql
source导入时字符集乱码怎么办
导入后中文变问号或方块，基本是客户端与SQL文件编码不一致。不是改数据库默认字符集，而是让当前会话匹配文件编码：
- 先查SQL文件编码（Linux）：
file -i backup.sql，常见为utf-8或gbk - 导入前立刻执行：
SET NAMES utf8mb4;（对应UTF-8文件）或SET NAMES gbk;（对应GBK导出的Navicat备份） - 如果SQL文件头部已有
SET NAMES或character_set_client设置，优先以它为准；否则必须手动设，否则INSERT语句里的中文会按默认latin1解析
大SQL文件导入卡住或报max_allowed_packet
645MB的SQL文件用source导入时，常卡在中间不动，或报错Packets larger than max_allowed_packet are not allowed：
- 临时调高限制（仅本次会话有效）：
SET GLOBAL max_allowed_packet = 1024*1024*512;（即512MB） - 注意：该值单位是字节，且需有
GLOBAL权限；若无，只能改配置文件my.cnf中[mysqld]段的max_allowed_packet并重启MySQL - 更稳妥的做法是关掉二进制日志加速导入：
SET SQL_LOG_BIN = 0;，导入完再开：SET SQL_LOG_BIN = 1;—— 尤其对生产库，避免Binlog暴涨
导入完成后怎么验证不是假成功
Query OK, 0 rows affected只是表示SQL语句语法通过，不代表数据真进去了。必须人工核验：
- 查表结构是否存在：
SHOW CREATE TABLE users;，看字段和引擎是否符合预期 - 查行数是否合理：
SELECT COUNT(*) FROM orders;，对比原库或备份日志里的记录数 - 抽样查数据内容：
SELECT id, name, created_at FROM users ORDER BY id DESC LIMIT 3;，重点看时间戳、中文、特殊符号是否正常 - 特别注意外键约束：如果SQL里没带
SET FOREIGN_KEY_CHECKS=0;，而表间依赖强，可能部分INSERT被静默跳过
最容易被忽略的是SQL文件里隐含的USE other_db;语句——它会把后续所有操作切到别的库，导致你以为恢复到了A库，实际数据全写进了B库。导入前用grep -n "USE " backup.sql | head -5扫一眼，比事后排查快十倍。
