Navicat导出的SQL文件如何在Linux命令行导入_使用mysql -u -p

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 
<p>或者用相对路径（当前就在同目录）：</p>
<pre class="brush:php;toolbar:false;">mysql -u root -p mydb 

<h3>Navicat 导出的 SQL 在 Linux 导入时乱码（中文变问号或 Mojibake）</h3>
<p>Navicat 默认导出时可能没显式声明字符集，而 Linux MySQL 客户端默认是 <code>latin1</code>，一读 utf8mb4 的内容就崩。这不是数据库层编码问题，是连接层“解码方式”错配。</p>
<p>解决关键不是改表或字段编码，而是让导入过程全程走 utf8mb4：</p>

确认目标库已用 utf8mb4 创建：CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
导入命令加 --default-character-set=utf8mb4 参数：

mysql -u root -p --default-character-set=utf8mb4 mydb 
<p>不加这个参数，即使库和表都是 utf8mb4，<code>mysql</code> 命令行客户端仍可能以 latin1 解析 SQL 流，导致建表语句里的中文注释、默认值全乱。</p>

<h3>source 命令在 mysql> 提示符下无法读取远程或相对路径文件</h3>
<p>在交互式 <code>mysql</code> 里执行 <code>source backup.sql</code>，它只认**绝对路径**，且要求文件对运行 <code>mysql</code> 的用户（通常是当前 shell 用户）可读。相对路径如 <code>./backup.sql</code> 或 <code>backup.sql</code> 会直接报 <code>Failed to open file</code>。</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7940" title="Zynq Linux Hardware Debug"><img
														src="https://img.php.cn/upload/skill/000/000/081/179177762288958.jpg" alt="Zynq Linux Hardware Debug" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill7940" title="Zynq Linux Hardware Debug" class="overflowclass">Zynq Linux Hardware Debug</a>
													<p class="overflowclass">Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill7940" title="Zynq Linux Hardware Debug" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>
<p>典型失败场景：</p>

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 表面看没报错，但实际可能中途静默失败：网络中断、MySQL <code>max_allowed_packet 超限、或客户端被服务端 kill（因 wait_timeout）。

排查和绕过方法：

导入前先设大包限制：mysql -u root -p --max-allowed-packet=512M mydb
加 -v（verbose）看实时输出：mysql -u root -p -v mydb &1 | head -50
避免超时：临时调高服务端参数（需有权限），或改用 mysql --init-command="SET SESSION wait_timeout=28800"
真正的大文件（>500MB），别硬扛——拆成多个小文件，或用 mysqldump --no-create-info 分离结构与数据再导入

最易被忽略的一点：Navicat 导出时若勾选了“兼容模式”或“转义反斜杠”，生成的 SQL 可能在 Linux shell 下被误解析（尤其含 \n 或 $ 符号），建议导出时取消所有兼容选项，用纯标准 SQL 格式。