MySQL迁移报错主因是环境差异导致兼容性问题，需重点核查版本差异、字符集与排序规则、SQL模式及存储引擎四方面。
MySQL迁移后报错，核心原因通常是环境差异导致的兼容性问题。不是所有SQL语法、配置参数或数据类型在不同版本或部署环境中都能无缝运行。快速定位需从服务端版本、字符集、SQL模式、存储引擎等关键维度切入。
检查MySQL版本差异
新旧环境MySQL主版本（如5.7 vs 8.0）不一致时，常见报错包括：“Unknown system variable”（如sql_mode中已移除的NO_AUTO_CREATE_USER）、“This function is deprecated”（如PASSWORD()函数在8.0中被移除）、“Authentication plugin 'caching_sha2_password' cannot be loaded”（8.0默认认证插件不被旧客户端支持）。
- 执行 SELECT VERSION(); 确认两边版本号
- 查阅MySQL官方升级指南，重点关注“Removed Features”和“Incompatible Change”章节
- 若为8.0+迁移，建用户时显式指定插件：CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';
核对字符集与排序规则
迁移后出现乱码、索引失效或WHERE条件不匹配，大概率是character_set_server、collation_server或表/列级字符集不一致。例如旧库用utf8（实际是utf8mb3），新库默认utf8mb4，但未同步修改表结构。
- 对比两边全局设置：SHOW VARIABLES LIKE 'character\_set\_%'; SHOW VARIABLES LIKE 'collation\_%';
- 检查具体表：SHOW CREATE TABLE tbl_name; 关注DEFAULT CHARSET和COLLATE子句
- 批量修正建议：ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
验证SQL模式（sql_mode）是否兼容
严格模式变化最易引发报错，比如新环境开启STRICT_TRANS_TABLES后，插入超长字符串、零日期、空自增字段会直接报错，而旧环境可能仅警告。
- 执行 SELECT @@sql_mode; 查看当前模式
- 常见冲突项：STRICT_TRANS_TABLES、ONLY_FULL_GROUP_BY、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO
- 临时调整（不推荐长期使用）：SET GLOBAL sql_mode = 'modes_without_strict';
- 更稳妥做法：在应用层适配，或在my.cnf中按需配置sql_mode，避免依赖宽松模式
确认存储引擎与特性支持
若原库使用MyISAM，新环境禁用该引擎（如MySQL 8.0默认不加载），或启用了不可用的特性（如全文索引在某些字符集下受限），会导致建表或查询失败。
- 检查引擎状态：SHOW ENGINES; 确认MyISAM/InnoDB是否ACTIVE
- 查看表引擎：SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name';
- 迁移前统一转为InnoDB：ALTER TABLE tbl_name ENGINE=InnoDB;
- 注意8.0中InnoDB表空间管理、隐藏主键行为等细微变更
不复杂但容易忽略。把版本、字符集、SQL模式、引擎这四点逐一对齐，90%的迁移报错都能快速定位并解决。
