MySQL恢复失败主因是sql_mode、max_allowed_packet、character_set_server三变量不匹配；其中max_allowed_packet过小会导致ERROR 1153或断连，需同步调大服务端与客户端值至512MB并重启生效。
MySQL恢复失败，十次里有三次是系统变量不匹配——尤其是sql_mode、max_allowed_packet、character_set_server这几个变量在导出/导入两端不一致时，会直接中断执行，报错却未必明确提示变量名。
sql_mode 不兼容：高版本导出的备份在低版本或旧配置下直接报错
MySQL 5.7.12+ 移除了 NO_AUTO_CREATE_USER，但很多旧my.cnf或 phpEnv 自带的配置仍保留它。恢复时 mysqld 启动失败，或导入中途卡住并静默退出。
- 检查当前实例的
sql_mode：执行SELECT @@sql_mode;，对比备份文件头部注释里的导出环境（如-- MySQL dump 10.13 Distrib 8.0.33） - 若备份来自 8.0+，目标为 5.7 或更早，必须在导入前临时禁用严格模式干扰：
SET SESSION sql_mode = '';（仅对当前连接生效） - 永久修复需改配置文件：把
[mysqld]段下的sql_mode值中删掉NO_AUTO_CREATE_USER，替换成目标版本支持的组合，例如STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION - 注意：修改
my.cnf后必须重启mysqld，且任务管理器里残留的旧进程要手动杀掉，否则配置不生效
max_allowed_packet 太小：大文件恢复时断连或报 ERROR 1153
备份 SQL 文件超过默认 4MB，客户端或服务端任一端max_allowed_packet不足，就会在读取某条长 INSERT 时直接断开，错误日志里只显示“Got an error reading communication packets”。
- 临时调大（无需重启）：
SET GLOBAL max_allowed_packet = 536870912;（512MB），再执行恢复命令 - 但客户端工具（如 mysql 命令行）也有自己的限制，需同步设置：
mysql --max-allowed-packet=512M -u root -p db_name - 永久生效必须双写：在
[mysqld]段加max_allowed_packet = 512M，同时在[client]或[mysql]段也加同一行，否则命令行工具仍按默认值走
字符集与 collation 不一致：中文乱码或报 ERROR 1273
备份时用utf8mb4导出，但目标库默认latin1，恢复时遇到 emoji 或四字节 UTF-8 字符就停在CREATE TABLE那行，报Unknown character set: 'utf8mb4'或Unsupported collation。
- 先确认目标实例是否真正支持：
SHOW CHARSET LIKE 'utf8mb4';和SHOW COLLATION WHERE Charset = 'utf8mb4'; - 若不支持（如极老版本），只能降级导出：
mysqldump --default-character-set=utf8 ...（注意是 utf8，不是 utf8mb4） - 若支持但未设为默认，导入前强制指定连接字符集：
mysql --default-character-set=utf8mb4 -u root -p db_name - 更稳妥的做法：在恢复命令前加
SET NAMES utf8mb4;，或确保备份文件开头有SET NAMES utf8mb4;语句
系统变量问题最麻烦的点在于：它不像语法错误那样立刻报错，而是在某个隐式转换、隐式创建或隐式校验环节才暴露，且错误信息往往不指向变量本身。所以恢复前务必用SELECT @@variable_name;比对两端关键变量，而不是只盯着备份文件和日志里那几行报错。
