MySQL命令行导入（mysql -u -p db_name < file.sql）是最稳定可控的方式，适合生产环境；source命令仅限已登录会话且需绝对路径，易因字符集、超时或USE语句出错。
mysql 命令直接导入是最稳定、最可控的方式，尤其适合生产环境；source 命令仅适用于已登录 MySQL 会话且文件路径在服务器本地，容易因字符集或超时中断。
用 mysql -u -p db_name < file.sql 导入（推荐）
这是 Linux 下最常用、最可靠的导入方式，整个过程由 shell 层面完成，不经过 MySQL 客户端交互层，规避了 source 的诸多限制。
常见错误现象：ERROR 1064 (42000) 或中文乱码，多数因未指定字符集或 SQL 文件含 CREATE DATABASE 语句但目标库已存在。
- 确保目标数据库已存在：执行
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" - 导入前加
SET NAMES utf8mb4;不起作用 —— 因为该命令只对当前会话生效，而重定向导入是“无会话”的；正确做法是在 SQL 文件头部手动插入这行，或用mysql --default-character-set=utf8mb4 -u ...显式指定 - 大文件（>100MB）导入失败？检查
max_allowed_packet：临时加大可加参数--max-allowed-packet=512M - 如果 SQL 文件里有
DROP DATABASE或CREATE DATABASE，而你只想往现有库追加数据，建议先用sed -i '/^CREATE DATABASE\|^DROP DATABASE/d' file.sql过滤掉
用 source 在 MySQL 会话内导入（慎用）
适用于调试小文件或已有连接、不想退出再重连的场景。但它本质是逐行读取并执行，对换行、注释、长 BLOB、多字节字符更敏感。
常见错误现象：ERROR 2006 (HY000): MySQL server has gone away，或导入中途卡住无响应。
- 必须先
USE mydb;，否则source会报错“no database selected” -
source只接受绝对路径，如source /tmp/data.sql；相对路径（source ./data.sql）会失败 - 若 SQL 文件含
USE other_db;，它会自动切换数据库，可能导致数据写错库 —— 建议提前用grep -n "USE " file.sql检查 - 导入前务必执行
SET autocommit=0;和SET unique_checks=0;加速，完成后记得COMMIT;和SET unique_checks=1;
导入后验证和收尾要点
导入成功不等于数据就位，尤其是跨版本、跨字符集迁移时，表结构和索引可能异常静默失效。
- 检查表数量是否匹配：执行
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'mydb'; - 抽查几条含中文、emoji 的记录是否显示正常，避免
utf8被误当utf8mb4处理 - 运行
mysqlcheck -u root -p --optimize --repair mydb修复可能损坏的索引（尤其从低版本 MySQL 导出的文件） - 别忘了清理临时文件：
rm /tmp/data.sql—— 生产环境上传的 SQL 文件常含明文密码或敏感字段
--skip-triggers、--routines、--events 等开关，这些决定了存储过程、事件、触发器会不会一并还原。没注意这点，应用上线后定时任务或业务逻辑就可能直接失效。 
