MySQL 5.7已终止官方支持，升级必须完成全链路验证；须用mysqlcheck --check-upgrade在只读状态下检测结构兼容性，严禁跳过或强制修复，逻辑升级需显式指定字符集、认证插件并排除系统库导入。
停服不是倒计时结束的信号，而是升级必须已跑通全链路的截止线。MySQL 5.7 官方支持已于 2023 年底终止，现在所有未升级的生产实例都处于无安全补丁、无漏洞响应、无技术支持的状态——这不是“还能用”，而是“出事没人管”。升级方案不能停留在“计划中”，必须以“已验证回滚路径+灰度切流能力”为最低交付标准。
mysqlcheck --check-upgrade 必须在只读状态下执行
这是唯一能提前暴露表结构不兼容的命令，跳过它等于把风险押在凌晨两点的启动日志里。它不检查 SQL 模式或字符集隐式转换，但会精准报出 ENUM 默认值为空、TEXT 字段写了 DEFAULT ''、列名撞上 rank 等 8.0 保留字等问题。
- 必须先将 5.7 实例设为只读：
SET GLOBAL read_only = ON;，再执行mysqlcheck -u root -p --all-databases --check-upgrade - 若报
The table does not comply with the current version of MySQL，不要尝试--fix参数强行修复；应逐库导出建表语句，人工修正后重建表 - 对含
JSON字段的表，额外运行：SELECT * FROM tbl WHERE json_valid(col) = 0;扫描非法 JSON 数据
逻辑升级比原地升级更可控，但导入参数必须显式指定
原地升级看似省事，实则把系统表重构、数据字典升级等不可逆操作压缩进一次启动过程，出错即中断且无日志细节。逻辑升级虽耗时，却能把问题拦在测试环境——前提是导入时不踩字符集、认证插件、系统库三坑。
- 导出时加
--default-character-set=utf8mb4，否则utf8（即 utf8mb3）表会被隐式转成 utf8mb4，但字段长度未扩容，后续插入中文直接截断 - 导入前在 8.0 实例中先执行：
SET GLOBAL default_authentication_plugin = 'mysql_native_password';，避免老 PHP/Java 应用连接报Client does not support authentication protocol -
mysql系统库绝不能导入：8.0 已移除mysql.plugin表，mysql.user字段类型变更，导入会卡死在第 12 张表
回滚不是“恢复备份”，而是验证过的逃生通道
所谓“零风险回滚”根本不存在，只有“可验证、可执行、有窗口”的回滚。回滚唯一可信来源是升级前完成的、经隔离环境恢复测试过的逻辑备份（mysqldump）或物理快照（LVM/ZFS），而非原地升级后的 /var/lib/mysql 目录。
- 备份后立即在隔离环境执行完整恢复 + 连通性测试：
SELECT COUNT(*)、SHOW CREATE TABLE、关键存储过程调用，缺一不可 - 回滚窗口期必须覆盖应用与中间件：数据库切回 5.7 后，需确认 HikariCP/Druid 连接池已清空缓存，MyCat/ShardingSphere 元数据指向旧集群，Prometheus 告警规则已切换
- 双主架构下回滚前，必须在 8.0 实例执行：
STOP REPLICA; RESET REPLICA ALL;，否则残留写入会反向污染 5.7 主库
最常被忽略的一点：升级不是 DBA 的单点任务，而是整个技术栈的协同动作。应用层的 ORM 是否缓存了 8.0 的元数据？监控告警是否还在查已废弃的 performance_schema 表？连接池健康检查是否仍用 5.7 的 SELECT 1 而非 8.0 推荐的 SELECT @@version？这些细节不提前对齐，哪怕备份和导入全成功，业务也可能在切流后五分钟内集体报错。
