.psc文件需手动解压验证是否含INSERT语句，.sql文件须检查前20行含字符集声明、CREATE TABLE与INSERT语句匹配，且还原前必须建库、设字符集、开启autocommit。
不能只靠“双击能打开”就认为备份可用——.psc 文件损坏、.sql 文件缺数据、字符集错位，Navicat 都不会主动报错，只会静默失败。
如何手动验证 .psc 文件是否真含数据
Navicat 的 .psc 文件本质是 ZIP 压缩包，双击看到表列表 ≠ 有真实数据。必须解压看底层 SQL 内容：
- 把
.psc文件后缀改成.zip，用 7-Zip 或系统自带解压工具打开 - 进入
data/目录，找对应表名的.sql文件（如users.sql） - 用文本编辑器打开该文件，搜索
INSERT INTO—— 如果完全找不到，说明导出时误选了「仅结构」或权限不足导致无数据写入 - 若发现大量
INSERT但某张大表缺失，检查 MySQL 服务端max_allowed_packet是否过小（还原前应设为1024M）
如何快速判断 .sql 文件是否完整可还原
SQL 备份文件不校验、不带元信息，打开前 20 行就能暴露多数问题：
- 开头必须有明确字符集声明，如
SET NAMES utf8mb4;或/*!40101 SET NAMES utf8mb4 */;；若只有SET CHARSET latin1;，还原到新库大概率中文乱码 - 确认包含
CREATE TABLE和紧随其后的INSERT INTO，且两者表名一致；若中间夹着大量注释或空行，可能是导出中途被中断 - 检查是否有
DEFINER=`user`@`%`子句：MySQL 8.0 默认禁用 DEFINER，还原会报错，需在 Navicat 备份时勾选Remove DEFINER and SQL SECURITY - 若备份来自 MySQL 5.7，而目标库是 8.0，搜索
utf8（非utf8mb4），这类语句在 8.0 中会被忽略或报错
还原前必须做的三件事
跳过任何一项，都可能让“还原成功”变成“数据静默丢失”：
- 手动执行
CREATE DATABASE `your_db_name` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;—— Navicat 不自动建库，且默认字符集常为latin1 - 在 Navicat 还原设置中，取消勾选
遇到错误时继续和在每个运行中运行多个查询，否则一条 INSERT 失败，后续全跳过 - 还原前在目标库执行
SELECT @@autocommit;，若返回0，先执行SET autocommit = 1;，避免整批数据卡在未提交事务里
为什么“还原日志显示成功”不等于数据到位
Navicat 的还原日志只记录语句是否发出去，不校验执行结果。最危险的是这三种静默失败：
-
Packet too large错误被吞掉：max_allowed_packet不够时，mysqldump 截断 INSERT，但 Navicat 仍标“完成” - 权限不足导致 SELECT * 返回空结果：账号只被授予部分列权限，Navicat 不报错，导出文件却无数据行
- 连错实例：还原时连接指向测试库而非生产库，日志一切正常，但数据进了错误的地方
真正可靠的验证，是还原后立刻执行 SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db_name'; 确认表数，再挑关键表查 COUNT(*) 和 MIN(id), MAX(id) 对比备份前快照——别等出事才查。
