MySQL升级需系统性操作，核心是“先验证、再灰度、后推广”；须评估兼容性、保障数据安全、设计回退路径、适配新版本配置，并上线后持续监控。
MySQL升级不是简单替换二进制文件，而是涉及兼容性评估、数据安全、服务连续性和应用适配的系统性操作。一次稳妥的升级，核心在于“先验证、再灰度、后推广”，避免直接在生产环境执行一键升级。
明确升级目标与兼容性边界
升级前必须确认两个关键点：目标版本是否仍在官方支持周期内（如MySQL 5.7已停止维护，8.0.32+是当前稳定主力）；现有SQL语法、字符集、认证插件、复制方式是否与新版本兼容。例如MySQL 8.0默认启用caching_sha2_password认证，老版本客户端可能连接失败；又如utf8mb4_0900_as_cs排序规则在5.7中不存在，含显式指定该collation的建表语句会报错。
- 用mysql_upgrade工具仅适用于5.7→8.0的就地升级，且要求实例已启动并能访问；它不负责版本切换，只修复系统表结构
- 推荐使用mysqld --upgrade=NONE启动新版本实例，跳过自动升级流程，改为人工逐项校验
- 用mysqlcheck -c检查所有库表一致性，比依赖mysql_upgrade更可控
设计可回退的数据迁移路径
停机升级风险高，建议采用逻辑导出+重放或主从切换方式。若业务允许短时只读，优先用mysqldump --set-gtid-purged=OFF导出（避开GTID冲突），导入到新实例后，用pt-table-checksum比对主从数据一致性。
- 对于大库（>100GB），避免单线程dump，改用mydumper多线程导出，配合myloader并发导入
- 升级期间保留旧实例至少72小时，确保binlog保留足够长（expire_logs_days=7），便于快速切回
- 提前在测试环境模拟“升级后回滚”操作，验证备份可用性——很多团队只测升级，不测回退
绕过常见陷阱的实操细节
升级后常出现性能下降或连接异常，多数源于配置未适配新版本默认值。MySQL 8.0默认关闭query_cache_type，而5.7默认开启；innodb_buffer_pool_dump_pct从100降为25，影响重启后缓存预热效率。
- 升级前导出当前所有SHOW VARIABLES结果，对比新版本默认值差异，手动覆盖关键项（如sql_mode需显式保留STRICT_TRANS_TABLES等）
- 禁用performance_schema相关采集器（如events_statements_history_long），避免8.0中因默认开启导致内存飙升
- 应用层连接字符串追加allowPublicKeyRetrieval=true&useSSL=false（仅限内网），解决8.0+默认SSL握手失败问题
上线后必须做的三件事
升级完成不等于结束。真实压力往往在第二天凌晨批量任务跑起后才暴露。
- 监控Aborted_connects和Connection_errors_xxx指标突增，定位认证或超时问题
- 用sys.schema_table_statistics查慢表，重点关注io_read_requests异常升高，可能是索引统计信息未更新（执行ANALYZE TABLE）
- 检查error log中是否有[Warning] InnoDB: Table xxx is marked as crashed，8.0对表损坏更敏感，需及时REPAIR TABLE
