确认当前 MySQL 版本及部署方式
先搞清你用的是什么版本、什么发行版、怎么装的——mysqld --version 只显示主版本，select VERSION(); 才是真实运行版本。如果是 Percona Server 或 mariadb，不能直接套用 MySQL 官方升级路径；docker 部署的要注意镜像 tag 是否绑定 minor 版本，mysql:8.0 这种写法在后续 docker pull 时可能意外拉到 8.0.34 → 8.0.35 的 patch 升级，虽通常安全，但生产环境建议锁死完整版本号（如 mysql:8.0.33）。
检查不兼容变更和废弃功能
MySQL 5.7 → 8.0 是分水岭，很多默认行为变了：密码认证插件从 mysql_native_password 改为 caching_sha2_password，老客户端连不上；GROUP BY 严格模式默认开启，原来能跑的 SQL 可能报错；sys 库结构重写，依赖旧视图的监控脚本会失效。必须查对应版本的 Changes in MySQL 8.0 官方文档，重点关注 “Incompatible Change” 和 “Removed Features” 章节。特别留意：CREATE table 中未显式指定 ENGINE 时，5.7 默认 MyISAM，8.0 默认 InnoDB，但如果你库中混用了引擎，升级后 SHOW CREATE TABLE 输出可能因隐式转换出问题。
执行升级前验证动作
别跳过这步，很多线上故障源于“本地测了没问题”。操作包括：
- 用
mysql_upgrade --dry-run模拟检查（注意：8.0.16+ 已移除此命令，改用mysqld --upgrade=NONE启动后执行SELECT * FROM information_schema.INNODB_SYS_TABLES等校验表结构） - 导出并重放慢查询日志中的典型语句，在新版本测试实例上跑一遍，观察执行计划是否突变（
EXPLAIN FORMAT=TREE在 8.0 更有用） - 备份
mysql系统库（尤其是user、db、procs_priv表），权限模型在 8.0 有调整，升级失败回滚时需手动还原 - 确认所有连接池配置（如 HikariCP 的
connection-test-query）支持新认证插件，否则应用启动即卡住
备份策略与回滚方案必须可验证
物理备份（mysqldump 或 Percona XtraBackup）不是“做了就行”，要实测恢复流程：备份 → 停旧实例 → 恢复到新版本实例 → 启动 → 连接 → 查询关键业务表。常见坑是字符集不一致：mysqldump --default-character-set=utf8mb4 必须显式加，否则导出的 CREATE database 语句可能带 DEFAULT CHARSET=utf8（已弃用），导入时被自动转成 utf8mb3，导致 emoji 存储异常。另外，如果用了 GTID 复制，升级主从时必须保证 gtid_mode=ON 且 enforce_gtid_consistency=ON 在升级前后一致，否则从库同步中断无法自动修复。