升级前必须做完整逻辑备份，而非仅依赖物理快照
容器环境里直接
docker commit或宿主机打卷快照，无法保证 MySQL 数据一致性——InnoDB 的 redo log、buffer pool、binlog 位置可能未刷盘。一旦升级失败回退，极大概率遇到主从断裂、GTID 不连续或表损坏。
正确做法是用
mysqldump或
mydumper执行在线逻辑备份，并显式指定关键参数：
--single-transaction：确保 InnoDB 表一致性（但不适用于 MyISAM）
--master-data=2：记录当前 binlog 文件与 position，方便后续重搭复制
--routines --triggers --events：避免存储过程、事件丢失 备份后务必校验：
mysqlcheck -c检查表结构，
head -n 20 backup.sql | grep "CREATE TABLE"确认导出头正常
使用官方镜像 + 显式版本标签，禁止用 :latest
MySQL 官方 Docker 镜像（
mysql:8.0.33）按语义化版本发布，但
:latest始终指向最新 minor 版，可能跳过中间修复补丁，甚至引入不兼容变更（如 8.0.32 → 8.0.33 默认启用
caching_sha2_password认证插件）。
升级时应：
先在测试容器中拉取目标镜像：docker pull mysql:8.0.33启动时挂载原有
/var/lib/mysql卷，但加
--skip-networking和
--innodb-force-recovery=1（仅诊断用） 观察日志是否出现
InnoDB: Upgrade is required或
Unknown system variable类错误 确认无误后再正式替换生产容器的
image字段
升级后必须运行 mysql_upgrade（8.0.16+ 已弃用，改用 ALTER）
MySQL 8.0.16 起移除了
mysql_upgrade工具，系统表升级由 mysqld 自动完成，但你仍需手动触发元数据兼容性操作： 若从 5.7 升级到 8.0，首次启动会自动执行
ALTER TABLE mysql.user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci等操作；需关注错误日志中是否卡在
Waiting for upgrade to complete检查
performance_schema表是否全部存在：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'performance_schema';（8.0 应返回 87+） 验证 SQL mode 是否符合预期：
SELECT @@sql_mode;，8.0 默认含
STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY，应用可能报错
滚动升级不适用于单节点容器，主从切换才是安全路径
试图对单个 MySQL 容器执行「停旧启新」看似简单，实则风险极高：连接中断期间未落盘事务丢失、应用重连时遭遇
Lost connection to MySQL server、连接池复用旧连接导致认证失败（尤其密码哈希算法变更）。
真正可行的做法是构建最小主从拓扑：
用新版本镜像起一个从库容器，配置CHANGE REPLICATION SOURCE TO指向原主库 等
SHOW REPLICA STATUS\G中
Seconds_Behind_Source为 0 后，执行
STOP REPLICA将应用流量切至新实例（通过 DNS 切换或服务发现更新），再关闭旧主库 旧主库可降级为新集群的从库，或彻底下线
这个过程暴露的问题最真实：比如 8.0 不再支持
query_cache_type参数，配置文件里留着就会导致从库启动失败——这种细节，只有实际跑起来才看得见。
