迁移后 max_allowed_packet
突然报错
新服务器默认值常为 4MB，而旧库可能设为 64MB 或更高。若应用执行大 BLOB、长 INSERT 或导出导入操作，会直接触发
Packet too large错误。 检查旧库：登录原 MySQL，执行
SHOW VARIABLES LIKE 'max_allowed_packet';新库需同步该值，修改
my.cnf中的
max_allowed_packet = 64M（注意单位是
M，不是
MB） 必须重启 MySQL 生效，仅
SET GLOBAL无法突破启动时上限
sql_mode
不一致导致 INSERT 失败
MySQL 5.7+ 默认启用严格模式（如
STRICT_TRANS_TABLES），而老环境可能是空或宽松模式。迁移后常见报错：
Incorrect integer value: '' for column 'id' at row 1。 导出旧库当前模式：
SELECT @@sql_mode;新库配置中显式设置
sql_mode = "..."，不要依赖默认值 若业务依赖宽松行为（如隐式类型转换），不建议直接照搬旧值；应优先修复 SQL，再逐步收紧模式
时区和 timestamp
行为差异
旧服务器可能设为
SYSTEM（即系统本地时区），新服务器若未配置，
DEFAULT CURRENT_TIMESTAMP字段可能按 UTC 写入，造成时间偏移。 确认旧库时区：
SELECT @@time_zone, @@system_time_zone;新库应在
my.cnf中设置
default-time-zone = '+08:00'（或
'Asia/Shanghai'） 注意：修改后新建连接才生效；已有连接仍用旧时区，需重连
字符集与排序规则未对齐
即使表定义声明了
utf8mb4，若服务端
character_set_server是
latin1，新建表/临时表/函数内部字符串仍会降级，引发乱码或索引失效。 比对关键变量：
character_set_server、
collation_server、
init_connect推荐统一设为：
character_set_server = utf8mb4，
collation_server = utf8mb4_unicode_ci注意
init_connect若含 SET 语句，需确保其语法兼容新版本（如 8.0+ 不允许 SET @var 在 init_connect 中） 实际迁移时最容易被跳过的，是
lower_case_table_names和
innodb_file_per_table这类影响元数据行为的参数——它们不报错，但会导致后续备份、表拷贝、跨平台恢复失败。务必在初始化实例前就定好，而不是等出问题再调。
