大促前72小时禁止mysql小版本升级，须用mysqld --validate-config校验配置、重放slow log+binlog验证行为、锁死镜像sha256、升级后立即执行analyze table分批优化并核验主从复制真实延迟。
不能在大促前72小时内执行任何 MySQL 小版本补丁升级——这是血的教训。真实故障中，约 68% 的“升级后慢查询突增”或“主从同步中断”都发生在业务峰值前未留足验证窗口的场景下。
mysql_upgrade --dry-run 必须跑，但别信它全对
这个命令只检查表结构兼容性，不验证运行时行为。比如 innodb_strict_mode 在 8.0.33→8.0.34 中默认值变更，mysql_upgrade --dry-run 不报错，但上线后 INSERT 带虚拟列的语句直接被拒绝。
- 必须搭配
mysqld --validate-config检查配置项是否被新版本废弃（如query_cache_type在 8.4+ 已彻底移除） - 在测试库上重放最近 24 小时的 slow log + binlog，用
mysqlbinlog --base64-output=decode-rows -v看 event 解析是否一致 - 特别注意
information_schema视图字段变更：8.0.32 后INNODB_METRICS新增了COUNT_RESET字段，老监控脚本若用SELECT *会崩
容器化实例升级必须锁死 SHA256，不能只认 :8.0.34
docker pull mysql:8.0.34 是高危操作。这个 tag 可能指向不同构建时间的镜像，其中某些构建未包含 CVE-2024-20857 的 runtime 补丁（该漏洞需动态链接修复，非单纯二进制替换）。
- 从 Docker Hub 官方页 复制完整镜像 digest，例如
mysql/mysql-server@sha256:9a1e7f3b5c... - 启动时显式挂载配置目录：
-v /host/my.cnf:/etc/my.cnf:ro，避免容器内默认配置覆盖你的生产参数 - 升级后立刻执行：
SELECT @@version_compile_os, @@version_comment;，确认不是某个发行版魔改包（如 Ubuntu 的8.0.34-0ubuntu0.22.04.2编译环境与 Oracle 官方不一致）
升级后 ANALYZE TABLE 不是可选项，是熔断开关
MySQL 8.0.23+ 的优化器统计信息缓存机制变了，旧统计信息可能被沿用数小时。某电商大促期间，因漏执行 ANALYZE TABLE，导致订单分页查询从 200ms 暴涨到 4.2s，触发自动扩容失败。
- 不要全库
ANALYZE TABLE—— 会锁表；改用按业务优先级分批：ANALYZE TABLE order_db.orders, user_db.users; - 对大表加
PERSIST选项避免重复采样：ANALYZE TABLE huge_log_table PERSISTENT FOR ALL; - 检查是否生效：
SELECT TABLE_NAME, TABLE_ROWS, AVG_ROW_LENGTH FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'order_db';对比升级前后数值变化幅度
最常被跳过的一步：升级后没检查 SHOW SLAVE STATUS\G 里的 Seconds_Behind_Master 是否真为 0——有些复制延迟会伪装成“0”，实际是 SQL 线程在重试错误事件。得看 Exec_Master_Log_Pos 和 Read_Master_Log_Pos 是否持续推进。
