在线升级只适用于小版本平滑迭代
MySQL 官方只保证同一大版本内的小版本在线升级可行，比如
8.0.33 → 8.0.34；跨大版本（如
5.7 → 8.0）或含
MyISAM表的实例，
mysqld --upgrade会直接失败，甚至损坏元数据。这是因为 8.0 彻底重构了数据字典，
mysql系统库中
user、
db等表已移除，全部由内部 dictionary 管理，5.7 的系统表空间无法识别。 必须使用相同构建方式：都是官方二进制包，或都是源码编译，混用会导致 ABI 不兼容 启用插件（如
audit_log、
keyring）前需确认新版是否支持对应 ABI 版本，否则启动即报错 在线升级后仍需手动验证：字符集默认值变化（
utf8mb4_0900_as_cs）、JSON 索引行为、慢日志字段新增、
sql_mode默认收紧等
离线升级是跨版本和生产环境的唯一稳妥路径
所谓“离线”，本质是停服 + 替换二进制 + 重初始化数据目录 + 迁移配置，不是简单覆盖安装。很多人跳过关键检查点，结果
service mysql start启动失败，排查半天才发现是配置项残留或初始化未完成。 备份前务必运行：
mysqlcheck --all-databases --check-upgrade，它会明确指出哪些表需
ALTER TABLE ... UPGRADE PARTITIONING替换
mysqld二进制后，先别急着启动服务，用测试命令验证初始化：
mysqld --initialize-insecure --datadir=/var/lib/mysql --basedir=/usr/local/mysql-8.0
my.cnf中必须清理废弃参数，例如
query_cache_type、
explicit_defaults_for_timestamp，否则 8.0 启动直接报
unknown variable
主从集群下如何最小化升级窗口
高可用环境不能全量停机，得靠角色切换实现“伪在线”：先升级从库 → 提升为新主 → 再升级原主。但 GTID 和复制过滤器的兼容性稍有不慎就会中断复制。
若原主启用了gtid_mode=ON，升级后必须保持
enforce_gtid_consistency=ON，否则从库 IO 线程拉取 binlog 时拒绝连接
replicate-ignore-db在 8.0 已被移除，必须改写为
replication-filter语法，并重启 mysqld 才生效 升级从库前，在主库执行
STOP SLAVE IO_THREAD，等
Seconds_Behind_Master = 0再停服务，避免 relay log 断层导致数据不一致
组复制（Group Replication）必须滚动升级
组内成员不能同时升级，必须逐个进行，否则新旧版本间特性不兼容——比如旧节点不支持 8.0 新增的
binlog_transaction_compression，或新节点依赖已弃用的
group_replication_recovery_complete_at参数，都会导致组通信异常甚至分裂。 滚动升级期间，组中可存在混合版本（如
8.0.17和
8.0.34），但要严格按 MySQL 文档规定的兼容顺序操作 升级前查当前组状态：
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_VERSION FROM performance_schema.replication_group_members;升级过程中禁止执行 DDL 或大事务，避免因版本差异导致 group commit 失败或 XA 锁等待超时
最容易被忽略的是插件兼容性和配置清理——哪怕只多留了一行
skip-external-locking，8.0 启动就卡住；哪怕 audit_log 插件没更新，mysqld 就静默退出。升级不是替换二进制那么简单，而是对整个运行时契约的重新校准。
