mysql小版本热升级（如8.0.32→8.0.33）可不停机，仅限同一主版本内补丁更新且满足rpm/deb包升级、未启read_only、无废弃系统表、客户端协议兼容等全部条件；5.7→8.0跨大版本必须停机，因元数据表重构、字符集变更、json存储格式更新等不可在线完成。
MySQL 升级是否需要停机，取决于升级方式和版本跨度——小版本热升级（如 8.0.32 → 8.0.33）通常可在线完成；跨大版本（如 5.7 → 8.0）或启用 innodb_fast_shutdown=0 时，必须停机。
哪些升级场景能不停机？
仅限同一主版本内的补丁更新（如 8.0.30 → 8.0.34），且满足以下全部条件：
- 使用 RPM/DEB 包升级，不替换二进制文件（即不手动拷贝
mysqld） - 实例未开启
read_only=ON或处于主库角色但允许 DDL 暂缓同步 - 未使用已废弃的系统表结构（如
mysql.proc在 8.0 中被移除，5.7 升 8.0 必须停机） - 所有客户端连接兼容新协议（例如 MySQL 8.0 默认启用
caching_sha2_password，旧驱动可能握手失败）
为什么 5.7 升 8.0 一定得停机？
这不是“能不能”的问题，而是“会不会坏”的问题。关键阻断点包括：
-
mysql.system_tables和mysql.system_table_stats等元数据表结构在 8.0 中彻底重构，mysql_upgrade工具必须停机执行并重写系统库 - 字符集默认值从
latin1改为utf8mb4，表定义变更需锁全表（即使ALGORITHM=INPLACE也要求停写） - JSON 字段内部存储格式变更，存量 JSON 值需在启动时逐行解码重序列化，该过程不可中断
升级中业务抖动比停机更危险
有人尝试用主从切换“伪装”不停机，但实际风险更高：
- 主库升级后，从库若未同步升级，复制可能卡在
Unknown system variable 'default_table_encryption'类错误 - GTID 模式下，版本差异导致
gtid_executed集合解析不一致，后续 failover 可能丢事务 - 应用层连接池若未配置
autoReconnect=true（MySQL Connector/J）或重连超时过短，会批量抛Communications link failure
真正影响业务的往往不是停机窗口本身，而是升级后隐性不兼容：比如 8.0 中 GROUP BY 严格模式默认开启，原来能跑的报表 SQL 突然报 Expression #1 of SELECT list is not in GROUP BY clause —— 这类问题必须在停机窗口内完成验证，不能留到上线后暴露。
