phpMyAdmin导出Laravel SQL文件为何生产环境报错？

MySQL导入时遇到#1064错误，很多人第一反应是SQL语法写错了，排查半天也找不到问题。实际上，错误根源往往不是SQL本身，而是导出时带上了生产环境不支持的语法或配置项。

导出文件含 MySQL 8.0+ 特性，但生产库是 5.7 或更低

这是最常见的情况。开发环境使用MySQL 8.0时，导出的SQL可能包含JSON字段、utf8mb4_0900_as_cs排序规则、WITH子句等特性。而MySQL 5.7无法识别这些关键字，直接返回#1064错误。

• 如何自查？打开导出的.sql文件，找到第一个CREATE TABLE语句，检查是否有不常见的关键字。如果存在，基本可判断为版本不匹配。
• 导出时在phpMyAdmin的“格式特定选项”中勾选SQL 兼容模式 → MYSQL40，该选项会自动降级语法，例如去掉IF NOT EXISTS、转义引号，使低版本也能正常导入。
• 如果需要保留特定特性（如JSON字段），建议使用命令行的mysqldump导出，操作更稳定：mysqldump --compatible=mysql40 --skip-extended-insert

SET time_zone = "+00:00" 在目标服务器未加载时区数据

phpMyAdmin默认导出会在文件开头添加一句SET time_zone = "+00:00"。但许多生产环境MySQL（尤其是Docker镜像或云RDS）未执行过mysql_tzinfo_to_sql加载时区表，执行该语句时会报#1298 - Unknown or incorrect time zone。

• 临时解决方案：使用文本编辑器删除SQL文件开头所有SET time_zone = ...行，简单有效。
• 长期修复：登录生产MySQL执行mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql（路径按实际情况调整），一次解决。
• 导出时避免此问题：在phpMyAdmin的“高级选项”中取消勾选“添加SET time_zone语句”（如果存在）；否则选择“无”兼容模式，防止添加额外配置。

字符集声明不匹配导致中文乱码或插入失败

导出文件头部可能包含/*!40101 SET NAMES utf8mb4 */，但生产库连接层未对齐，或建库语句使用CHARACTER SET utf8（而非utf8mb4），插入emoji或四字节中文时会被截断甚至报错。

• 检查导出文件前几行是否有CREATE DATABASE ... CHARACTER SET utf8mb4——如果没有，说明源库未正确设置。
• 导入命令必须显式指定编码：mysql --default-character-set=utf8mb4 -u root -p database_name < dump.sql
• 生产库建库语句应使用utf8mb4，排序规则推荐utf8mb4_unicode_ci（避免使用_0900_as_cs，因为MySQL 5.7无法识别）。

容易被忽略的是：phpMyAdmin导出的SQL并非“原始快照”，它会根据当前界面设置、PHP版本、MySQL版本动态注入兼容性语句。同一份数据库在XAMPP 8.1和宝塔5.7上导出的文件可能完全不同。因此不要认为“能导出就能导入”，拿到文件后先检查第一行CREATE DATABASE和第一个CREATE TABLE是否干净通用，这是避免错误的关键。