navicat“导入成功”不可信，因其可能跳过错误、截断语句、忽略字符集不匹配而不报错；须手动验证结构、行数、关键字段及字符集。
navicat 导入完成后不能只看“成功完成”弹窗，必须手动验证数据完整性——因为导入过程可能跳过错误、截断语句、忽略字符集不匹配，导致表结构或数据缺失却不报错。
为什么 Navicat 的“导入成功”不可信
Navicat 在导入 SQL 文件时，默认行为是「遇到单条语句错误就停止当前批次」，但不会回滚已执行的语句；勾选「遇到错误时继续」仅让任务调度器跳过报错语句，INSERT 冲突、CREATE TABLE 语法错误、字段长度超限等仍会导致部分数据丢失。更隐蔽的问题是：
- 字符集未显式声明时，Navicat 用系统 locale（如 Windows 中文环境默认 gbk）解析 UTF-8 编码的
.sql文件 → 中文字段值变成???，但无任何警告 - SQL 文件末尾被截断（如 FTP 传输中断），Navicat 可能只执行到中间某条
INSERT就静默结束，不提示“文件不完整” -
CREATE DATABASE语句缺失或目标库已存在，而没勾选「包含创建数据库语句」→ 后续USE `xxx`失败，但 Navicat 不报错，只跳过所有建表语句
快速验证三步法：查结构 + 查行数 + 查关键字段
不用写脚本，开 Navicat 就能完成。重点不是“有没有表”，而是“表里有没有该有的数据”：
- 查结构是否完整：右键数据库 → 「刷新」→ 展开「表」节点，确认所有预期表名都存在；双击任意一张表 → 切换到「结构」标签页，核对字段名、类型、主键、索引是否与源库一致
-
查行数是否匹配：在查询窗口运行：
SELECT COUNT(*) FROM user_log;（把user_log换成你业务中最核心的一张表）；对比导入前源库导出快照里的行数（比如导出日志里有-- Dump completed on ... Rows: 12456） -
查关键字段是否乱码/为空：运行
SELECT id, username, nickname FROM sys_user LIMIT 5;；重点看nickname这类含中文的字段是否显示正常，而不是æå或NULL
容易被忽略的字符集陷阱
即使表结构和行数都对，中文仍可能错乱——问题常出在连接层而非存储层：
- 导入时 Navicat 默认用客户端字符集（Windows 系统常为
gbk）读取 UTF-8 文件 → 解析失败，但不报错 - 解决方法：导入前右键数据库 → 「运行 SQL 文件」→ 弹窗中手动把「编码」下拉框改成
65001 (UTF-8)（不是自动检测） - 验证是否生效：导入后执行
SHOW VARIABLES LIKE 'character_set_client';，结果应为utf8mb4；若仍是gbk，说明导入时编码选错了，需重新导入
批量验证小技巧（适合多表场景）
如果导入了几十张表，逐个 COUNT(*) 太慢，可用 Navicat 自带的「数据同步」功能反向比对：
- 新建一个空库（如
test_import_check），用相同参数再导入一次原 SQL 文件 - 右键源库 → 「数据同步」→ 选择「源：刚导入的库」、「目标：test_import_check」→ 下一步勾选「比较结构和数据」
- 它会生成差异报告，直接标出哪些表行数不一致、哪些字段值不同——比人工查快得多，且能暴露隐性截断问题
真正耗时的不是导入，而是验证；最危险的不是报错，而是静默失败。尤其当 SQL 文件来自他人或 CI 流水线时，务必在生产环境还原前，在测试库走完这四步——结构、行数、字段值、字符集，缺一不可。
