17370845950

必须用mysqldump做逻辑备份而非直接拷贝文件，因跨大版本物理文件不兼容；恢复时需禁用外键与唯一性校验；8.0.16前须运行mysql_upgrade，之后自动升级；默认字符集变为utf8mb4、排序规则更严格，需逐库验证。

升级前必须用 mysqldump 做逻辑备份，而非直接拷贝文件

MySQL 版本跨大版本升级（如 5.7 → 8.0）时，datadir 下的物理文件结构、系统表格式、字符集默认行为都可能不兼容。直接复制 ibdata1 或 .ibd 文件极大概率导致启动失败或数据损坏。必须使用 mysqldump 导出为 SQL 文本——它能自动适配源版本语法，并在恢复时由目标版本的 MySQL Server 解析执行。

实操建议：

• 用 --

  

  single-transaction --routines --triggers --events 参数保证一致性与完整性
• 显式指定字符集：--default-character-set=utf8mb4，避免 5.7 默认 utf8（即 utf8mb3）在 8.0 中被拒绝
• 排除 mysql 系统库：--ignore-table=mysql.user --ignore-table=mysql.db...，升级后应由 mysql_upgrade（8.0.16+ 已移除）或初始化流程重建权限表
• 若库多、数据大，分库导出：mysqldump -u root -p --databases db1 db2 > backup.sql

mysql 客户端恢复时要禁用外键检查和唯一性校验

导入 dump 文件时，尤其是含大量关联表的场景，直接执行会因外键约束或唯一索引冲突中断。必须在恢复前临时关闭校验，否则常见错误如：ERROR 1215 (HY000): Cannot add foreign key constraint 或 ERROR 1062 (23000): Duplicate entry。

实操建议：

• 在 SQL 文件开头插入：

  SET FOREIGN_KEY_CHECKS=0;
  SET UNIQUE_CHECKS=0;
  SET AUTOCOMMIT=0;

• 导入完成后手动执行：

  SET FOREIGN_KEY_CHECKS=1;
  SET UNIQUE_CHECKS=1;
  COMMIT;

• 不要依赖 mysqldump --skip-extended-insert 来规避问题——它只影响 INSERT 格式，不解决约束冲突
• 若用 source 命令导入，确保客户端连接时已设置 --init-command="SET NAMES utf8mb4"，否则中文可能乱码

升级后首次启动必须运行 mysql_upgrade（仅限 8.0.16 之前）或检查系统表兼容性

MySQL 5.7 升级到 8.0.15 及更早版本时，mysql_upgrade 是强制步骤：它会检查并更新 mysql 系统库中的表结构（如 user 表字段变更）、修复权限视图、刷新帮助表。但自 8.0.16 起该工具已被移除，升级逻辑内建到服务启动流程中。

实操建议：

• 对 8.0.15 及以下版本：停掉旧实例 → 替换二进制 → 启动新 mysqld → 运行 mysql_upgrade -u root -p
• 对 8.0.16+ 版本：启动时若检测到旧系统表，会自动执行升级并写入日志，需确认 error log 中出现 Upgrading system tables. 和 Finished upgrading system tables.
• 无论哪个版本，升级后务必验证：SELECT VERSION();、SELECT COUNT(*) FROM mysql.user;、SHOW GRANTS FOR CURRENT_USER;
• 注意：8.0 默认认证插件变为 caching_sha2_password，老客户端（如 MySQL 5.7 客户端或旧版 JDBC）可能连不上，需在用户创建时显式指定 IDENTIFIED WITH mysql_native_password

字符集与排序规则迁移最容易被忽略的三个细节

MySQL 8.0 将默认字符集从 latin1（5.7）改为 utf8mb4，默认排序规则从 latin1_swedish_ci 改为 utf8mb4_0900_ai_ci。这不是简单配置变更，会影响索引长度、比较行为、JSON 字段解析等。

实操建议：

• 检查所有表的 CREATE TABLE 语句，确认是否显式声明了 CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci；未声明的会继承库级设置，而库级设置又继承 server 级，容易层层覆盖出错
• utf8mb4_0900_ai_ci 对大小写不敏感且忽略重音，但比旧排序规则更严格——例如 'a' = 'A' 仍为 true，但某些特殊字符组合的比较结果可能不同，业务有精确匹配逻辑的需回归测试
• 若应用依赖 utf8mb4_unicode_ci（如 PHP 的 mb_strtolower() 行为），需在建表或连接时显式指定，不能依赖默认值
• 升级后执行：SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME='your_db'; 逐库确认

实际升级最耗时的环节往往不是执行命令，而是验证每个业务查询在新版本下的执行计划是否变化、JSON 字段是否仍可被正确解析、触发器是否还按预期触发——这些没法靠一键脚本覆盖，得靠你盯着慢查询日志和应用日志看。