导出文件导入失败主因是环境不匹配：SQL语法版本不兼容（如MySQL 8.0导出到5.7）、时区设置触发#1298错误、max_allowed_packet与PHP上传限制不同步、字符集声明错位（utf8 vs utf8mb4），需前置检查并统一配置。
因为导出文件里混着目标服务器不认的语法、时区、字符集或权限语句，不是文件坏了，是环境不匹配。
SQL语法版本不兼容：MySQL 8.0导出的文件往5.7上导必报1064
导出文件开头的 CREATE DATABASE 或第一个 CREATE TABLE 里如果出现 JSON 类型、utf8mb4_0900_as_cs 排序规则、WITH 子句或 IF NOT EXISTS（老版本不支持），MySQL 5.7 及更早就会直接崩在第一行。不要等导入失败再排查——打开文件搜前20行，看有没有不认识的关键字。
- 导出时加
--compatible=mysql57或--compatible=ansi强制降级语法（会丢部分特性，但能跑通） - 避免用
mysqldump --skip-extended-insert导出，它让每条INSERT单独成行，出错时能准确定位到哪条数据 - 检查
SET SQL_MODE行是否被 phpMyAdmin 跳过——很多导出文件带这行，但导入页不执行，导致严格模式下空字符串插数字字段失败
SET time_zone = "+00:00" 触发 #1298 错误
phpMyAdmin 导出时自动加的这行，本质是告诉 MySQL “接下来按 UTC 解析时间”，但目标库如果没加载时区表（mysql.time_zone_name 为空），就报 #1298 - Unknown or incorrect time zone: '+00:00'。XAMPP、宝塔默认常不加载时区数据。
- 临时解法：手动删掉 SQL 文件最开头的
SET time_zone = ...行（通常在第3–5行） - 根治法：在目标 MySQL 执行
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql加载系统时区 - 导出时避开：phpMyAdmin 导出页勾选「无」→「添加 SET time_zone 语句」（新版界面叫「导出时包含时区设置」，关掉即可）
max_allowed_packet 和 upload_max_filesize 不同步导致静默中断
看到 Incorrect format parameter 或导入卡住不动？大概率是上传中途被截断。MySQL 的 max_allowed_packet 和 PHP 的 upload_max_filesize 必须同时调大，只改一端没用。
- MySQL 端：在
my.cnf的[mysqld]段加max_allowed_packet = 256M（别写 256MB，旧版解析失败） - PHP 端：在
php.ini改四值：upload_max_filesize = 256M、post_max_size = 256M、memory_limit = 512M、max_execution_time = 1200 - 验证是否生效：登录 MySQL 执行
SHOW VARIABLES LIKE 'max_allowed_packet';，返回值是字节（如 268435456 = 256M），不是你写的字符串
字符集声明错位：文件里是 utf8mb4，建库语句却写 utf8
SQL 文件开头有 /*!40101 SET NAMES utf8mb4 */;，但建库语句是 CREATE DATABASE `db` CHARACTER SET utf8 —— 这会导致 emoji 插入时被截断或报错，且错误可能延迟到 INSERT 阶段才暴露，行号完全不可信。
立即学习“PHP免费学习笔记（深入）”；
- 导出前确认源库字符集：
SHOW CREATE DATABASE your_db;看是否真用了utf8mb4 - 导入前手动改 SQL 文件里的建库语句，把
CHARACTER SET utf8全部替换成CHARACTER SET utf8mb4 - 命令行导入时必须加
--default-character-set=utf8mb4，否则客户端连接层仍按 latin1 解析中文
真正麻烦的不是某一条报错，而是多个问题叠加：比如先因时区失败，你清库重试，结果因字符集不匹配又崩在另一处；或者改了 PHP 限制，但 MySQL 的 max_allowed_packet 还是 1M，导入到一半静默断连，你还以为是文件损坏。动手前先看前三行和第一个 CREATE TABLE，比盲目调参数高效得多。
