MySQL交互式环境下source命令仅支持绝对路径，相对路径无效；大文件导入需调大max_allowed_packet、启用verbose模式并防范超时，Navicat导出应禁用兼容模式以避免shell解析错误。
mysql -u -p
直接执行 mysql -u root -p mydb 报这个错，不是密码输错了，而是 shell 找不到 <code>backup.sql 文件路径。linux 不会自动在当前目录搜文件，必须用绝对路径或明确的相对路径。
常见错误操作：
- 把
backup.sql放在桌面，却在/home/user目录下运行命令 - 路径里用了中文、空格或波浪号
~（shell 不展开） - 文件权限为只读，且当前用户无读取权限（
ls -l backup.sql看一眼）
正确做法：先 cd 进文件所在目录，再用 pwd 确认，然后执行：
mysql -u root -p mydb < /home/user/backup.sql
或者用相对路径（当前就在同目录）：
mysql -u root -p mydb < ./backup.sql
Navicat 导出的 SQL 在 Linux 导入时乱码（中文变问号或 Mojibake）
Navicat 默认导出时可能没显式声明字符集，而 Linux MySQL 客户端默认是 latin1，一读 utf8mb4 的内容就崩。这不是数据库层编码问题，是连接层“解码方式”错配。
解决关键不是改表或字段编码，而是让导入过程全程走 utf8mb4：
- 确认目标库已用 utf8mb4 创建：
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 导入命令加
--default-character-set=utf8mb4参数：
mysql -u root -p --default-character-set=utf8mb4 mydb < /path/to/backup.sql
不加这个参数，即使库和表都是 utf8mb4，mysql 命令行客户端仍可能以 latin1 解析 SQL 流，导致建表语句里的中文注释、默认值全乱。
source 命令在 mysql> 提示符下无法读取远程或相对路径文件
在交互式 mysql 里执行 source backup.sql，它只认**绝对路径**，且要求文件对运行 mysql 的用户（通常是当前 shell 用户）可读。相对路径如 ./backup.sql 或 backup.sql 会直接报 Failed to open file。
典型失败场景：
-
source ~/backup.sql——~不被 mysql 内部解析 -
source /tmp/backup.sql，但文件属主是 root，当前用户是普通用户 - SQL 文件里有
CREATE DATABASE，但你已经USE mydb，结果报错“database exists”或语法冲突
稳妥做法：
先退出 mysql，用 shell 确认路径有效：
ls -l /tmp/backup.sql
再进 mysql，用完整路径：
mysql> source /tmp/backup.sql;
大 SQL 文件导入卡住、无响应、超时断连
Navicat 导出的全量库 SQL 往往几十 MB 甚至上 GB。mysql -u -p db < file.sql 表面看没报错，但实际可能中途静默失败：网络中断、MySQL max_allowed_packet 超限、或客户端被服务端 kill（因 wait_timeout）。
排查和绕过方法：
- 导入前先设大包限制：
mysql -u root -p --max-allowed-packet=512M mydb < backup.sql - 加
-v（verbose）看实时输出：mysql -u root -p -v mydb < backup.sql 2>&1 | head -50 - 避免超时：临时调高服务端参数（需有权限），或改用
mysql --init-command="SET SESSION wait_timeout=28800" - 真正的大文件（>500MB），别硬扛——拆成多个小文件，或用
mysqldump --no-create-info分离结构与数据再导入
最易被忽略的一点：Navicat 导出时若勾选了“兼容模式”或“转义反斜杠”，生成的 SQL 可能在 Linux shell 下被误解析（尤其含 \n 或 $ 符号），建议导出时取消所有兼容选项，用纯标准 SQL 格式。
