在线升级仅限同大版本小版本间（如8.0.33→8.0.34），跨大版本（如5.7→8.0）或含MyISAM表时必须离线升级；需校验插件兼容性、清理废弃参数、执行mysqld --upgrade，并验证字符集、JSON索引、慢日志及权限模型变化。
在线升级是否可行，取决于 MySQL 版本跨度和存储引擎
MySQL 官方只保证 GA（General Availability）版本之间的**小版本在线升级**（如 8.0.33 → 8.0.34），且要求使用相同构建方式（如都是官方二进制包或都用源码编译）。跨大版本（如 5.7 → 8.0）或混合引擎（尤其含 MyISAM 表）时，mysqld --upgrade 会失败或产生不兼容元数据。
-
InnoDB表在 8.0+ 中默认启用innodb_file_per_table=ON和新数据字典格式，5.7 的系统表空间无法直接识别 -
mysql系统库结构在 8.0 彻底重构，user、db等表被移除，依赖data dictionary，离线迁移时必须执行mysql_upgrade（8.0.16+ 已弃用，改由mysqld --upgrade自动触发） - 若实例启用了
audit_log或keyring插件，插件 ABI 不兼容会导致启动失败，需提前确认插件版本支持情况
离线升级的标准操作流程与关键检查点
离线升级是跨大版本或生产环境的推荐路径，核心是「停服 → 替换二进制 → 初始化数据目录 → 迁移配置」。容易被跳过的检查点往往导致启动失败。
- 备份前先运行
mysqlcheck --all-databases --check-upgrade，它会报告具体哪些表需ALTER TABLE ... UPGRADE PARTITIONING或修复 - 替换
mysqld二进制后，不要直接service mysql start；应先用mysqld --initialize-insecure --datadir=/var/lib/mysql --basedir=/usr/local/mysql-8.0验证初始化是否成功（仅测试用，生产环境用--initialize） -
my.cnf中废弃参数如query_cache_type、explicit_defaults_for_timestamp必须删除，否则 8.0 启动报错unknown variable
mysqld --defaults-file=/etc/my.cnf --datadir=/var/lib/mysql --basedir=/usr/local/mysql-8.0 --upgrade=FORCE
主从架构下如何最小化升级窗口
对高可用集群，可利用主从角色切换实现“伪在线”升级：先升级从库，再提升为新主，最后升级原主。但要注意 GTID 和复制过滤器的兼容性。
- 5.7 开启了
gtid_mode=ON，8.0 升级后必须保持enforce_gtid_consistency=ON，否则复制中断 - 若从库配置了
replicate-ignore-db，8.0 中该参数已被移除，需改用replication-filter语法并重启生效 - 升级从库前，先在主库执行
STOP SLAVE IO_THREAD，等Seconds_Behind_Master = 0后再停服务，避免 relay log 断层
升级后必须验证的三项实际行为
很多团队只检查 SELECT VERSION() 就认为完成，但以下三类问题常在业务高峰暴露：
- 字符集隐式转换：5.7 默认
utf8mb4但排序规则是utf8mb4_general_ci，8.0 改为utf8mb4_0900_as_cs，ORDER BY结果可能变化，需重跑关键查询对比 - JSON 字段索引失效：5.7 建的
VIRTUAL列索引在 8.0 中仍可用，但若字段定义含AS (json_extract(...)) STORED，需确认INFORMATION_SCHEMA.STATISTICS中索引状态为active - 慢日志格式变更：8.0 的
slow_query_log_file默认用新格式（含 query_time 微秒精度），旧解析脚本会丢字段，建议用mysqldumpslow -s t而非自定义 awk 脚本
最易被忽略的是权限模型变化：8.0 的 CREATE USER 不再隐式赋权，所有账号需显式 GRANT，升级后应用连不上时，先查 SELECT user,host,account_locked FROM mysql.user 确认账号未被锁且权限完整。
