导出的 SQL 文件完整性需验证三要素：必须含 CREATE DATABASE 或 USE 语句、至少一条 INSERT INTO 语句、以及 /!40101 SET.../ 兼容性头；否则可能仅导出结构或导入失败。
导出的 SQL 文件是否完整？先看这三行
直接打开导出的 .sql 文件，用文本编辑器（如 vs code、notepad++）搜索以下三处关键内容，缺一不可：
-
CREATE DATABASE或USE `数据库名`—— 确认目标库被显式指定，避免导入时误写入其他库 -
INSERT INTO `表名` VALUES（或INSERT INTO `表名` (`字段1`,...)）—— 至少有一条 INSERT，说明数据实际被导出，而非仅结构 -
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */类似的版本兼容头 —— 表明导出时启用了“兼容性模式”，能减少导入报错
如果文件开头只有 CREATE TABLE 且无任何 INSERT，大概率是勾选了「仅结构」；若连 CREATE DATABASE 都没有，导入时需手动 CREATE DATABASE 并 USE，否则会报 Unknown database 错误。
用 mysql 命令行快速验证 SQL 是否可解析
不依赖 phpMyAdmin，用 MySQL 自带工具做轻量级语法校验：把导出文件丢进命令行执行一次「空导入」（不真正写入），靠错误反馈判断完整性：
mysql -u root -p --one-database your_db_name < backup.sql 2>&1 | grep -iE "(error|warning|unknown)"
重点关注输出中的：
-
ERROR 1046 (3D000): No database selected→ 缺USE或CREATE DATABASE -
ERROR 1146 (42S02): Table 'xxx' doesn't exist→ 表结构未导出，或顺序颠倒（INSERT 在 CREATE TABLE 前） -
ERROR 1064 (42000): You have an error in your SQL syntax→ 导出时字符集/转义异常，常见于含 emoji 或二进制 blob 的字段
注意：--one-database 是关键参数，它让 MySQL 忽略文件中对其他库的操作，防止误删或污染；没加它可能静默跳过错误。
立即学习“PHP免费学习笔记（深入）”；
对比行数：SELECT COUNT(*) vs 文件里 INSERT 行数
导出后立刻在原库运行统计，再跟 SQL 文件里的 INSERT 数量粗略比对（适合中小规模表）：
- 查原表总行数：
SELECT COUNT(*) FROM `users`; - 查 SQL 文件中该表的 INSERT 条数：
grep -c "INSERT INTO \`users\`" backup.sql
两者应基本一致（允许 ±1，因导出过程中可能有新写入）。若差值 >5%，需检查：
- phpMyAdmin 导出页是否勾选了「忽略 INSERT 语句中的 AUTO_INCREMENT 值」——它不会影响行数，但会影响主键连续性
- 是否启用了「压缩」导出（.sql.gz）？
grep无法直接读取，需先zcat backup.sql.gz | grep ... - 大表是否触发了 phpMyAdmin 的
max_allowed_packet截断？此时文件末尾会突然中断，无结束分号或注释
导入前必做的最小化还原测试
别等真正出事才试——用一个临时库快速跑通整个链路：
- 新建空库：
CREATE DATABASE test_restore CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 导入备份：
mysql -u root -p test_restore < backup.sql - 验证关键表数据存在且可查：
mysql -u root -p -e "SELECT COUNT(*) FROM test_restore.users;"
这一步耗时通常不到 10 秒（10MB 以内 SQL），却能暴露 90% 的兼容性问题：比如导出时用 utf8 而目标库默认 utf8mb4，会导致中文乱码或导入失败；又或者 phpMyAdmin 导出勾选了「延迟键写入」，而目标 MySQL 版本不支持该语法。
真正容易被忽略的是：phpMyAdmin 默认导出不含 SET FOREIGN_KEY_CHECKS=0;，如果备份里有外键约束，而导入时没关检查，会因依赖顺序报错。手动补上这一行再导入，比反复调试快得多。
