导出时必须手动设phpMyAdmin语法兼容性为MYSQL40并勾选“添加SET SQL_MODE语句”，否则跨版本导入会因JSON、utf8mb4_0900排序规则、DEFINER等高版本特性报错；需全局替换排序规则、降级utf8mb4、删除8.0专属注释及不兼容定义。
导出时选对语法兼容性模式
phpmyadmin 默认按当前 mysql 版本导出，不自动适配目标环境。跨版本迁移（比如从 8.0 导出、往 5.7 导入）必须手动干预。
- 进入 phpMyAdmin 右上角「设置」→「导出」→「格式」选项卡
- 把「语法兼容性」下拉菜单设为
MYSQL40（覆盖 5.0–8.0 基础语法，够用；极老环境才选MYSQL323） - 务必勾选「添加 SET SQL_MODE 语句」——它会在文件开头插入类似
SET SQL_MODE = 'NO_AUTO_VALUE_ON_ZERO'的行，避免因模式差异报错 - 如果已导出但导入失败，别急着重导，先看错误关键词：比如
JSON、utf8mb4_0900_as_cs、ENCRYPTION='Y'，这些是高版本专属，低版本根本不认
替换或删掉不兼容的排序规则
报错 Unknown collation: 'utf8mb4_0900_as_cs' 或 Unknown collation: 'utf8mb4_0900_ai_ci' 是最常见现象，根源是 MySQL 8.0+ 默认排序规则在 5.7 及更早版本里不存在。
- 用 VS Code 或 Notepad++ 打开 SQL 文件，全局搜索替换：
utf8mb4_0900_as_cs→utf8mb4_unicode_ci，utf8mb4_0900_ai_ci→utf8mb4_general_ci - 注意两种写法都要覆盖：
COLLATE utf8mb4_0900_as_cs和DEFAULT COLLATE utf8mb4_0900_as_cs - 若目标库是 MySQL 5.6 或更早，还得把所有
utf8mb4降级为utf8（会丢 4 字节 emoji 支持，但能跑通） - 顺手删掉文件开头形如
/*!80013 DEFAULT HISTOGRAM_TYPE = 'singleton' */这类 MySQL 8.0+ 专属注释，它们可能干扰解析器
处理 DEFINER 和高版本表定义
DEFINER 报错不是语法问题，而是权限元数据冲突；JSON、ROW_FORMAT=DYNAMIC 等则是纯语法不识别，两者都得动手改。
- 导出前，在「导出方法」→「自定义」→「对象创建选项」中，取消勾选「添加 DEFINER 和 SQL SECURITY」
- 若已导出，用正则全局替换：
DEFINER=`[^`]+`@`[^`]+`→ 空（注意触发器里的 DEFINER phpMyAdmin 不自动处理，得手动删） - 删掉或改写不支持的列定义：比如
data JSON DEFAULT (JSON_OBJECT())→data TEXT；ROW_FORMAT=DYNAMIC在 5.6+ 是可选，但若目标实例禁用了innodb_file_format，就得整段删掉 - 检查是否有
CREATE FUNCTION或存储过程，MySQL 8.0 要求必须声明DETERMINISTIC或对应特性，否则直接拒绝
绕过上传限制和连接层乱码
很多“导入失败”根本不是版本问题，而是被 PHP 或 Nginx 拦在了半路，或者编码没对齐导致解析错位。
- 宝塔用户必须同步改三处：
upload_max_filesize、post_max_size（建议设为前者的 1.5 倍）、client_max_body_size（Nginx 配置里加），缺一不可 - SQL 文件编码是 GB2312 却被 Navicat 当 UTF-8 解，中文字段名全变乱码进而引发语法错误——VS Code 里看底部编码，是 GBK 就转存为 UTF-8（无 BOM）；或在 Navicat 导入时手动选编码
20936（GB2312） - extended insert（一条 INSERT 插几百行）生成的单条语句可能超
max_allowed_packet，Navicat 或 phpMyAdmin 都会静默中断；临时解决可改用命令行：mysql -u root -p --max-allowed-packet=512M db_name < file.sql
SHOW CREATE TABLE 对比结构，再抽样查几条带特殊字符或 JSON 的记录。 
