MySQL 8.0.21+ 小版本升级支持在线二进制替换，但需满足 innodb_fast_shutdown=1 且 innodb_version 兼容；实际为短时停写而非停服务，替换前须检查 InnoDB 格式、废弃参数及 glibc 版本。
MySQL 8.0.x 小版本升级必须停机吗？
不用。8.0.21 及之后的小版本（如 8.0.33 → 8.0.34）支持在线二进制替换，前提是满足两个硬性条件：innodb_fast_shutdown=1（默认值），且升级前后 innodb_version 兼容（小版本间通常兼容）。但「在线」仅指不中断连接——升级过程仍需执行 mysql_upgrade 或等价操作，而该步骤要求所有客户端断开、无活跃事务，实际是短时停写（非停服务）。
二进制替换前必须验证哪些兼容性？
直接替换 mysqld 二进制文件前，漏掉这些检查大概率导致启动失败：
- 确认当前
datadir下mysql.ibd和ibdata1的物理格式版本与新二进制兼容：运行SELECT VERSION(), @@innodb_version;，比对新包 Release Notes 中的InnoDB version支持范围 - 检查
my.cnf中是否含已废弃参数（如query_cache_type在 8.0.33+ 被彻底移除），否则mysqld --validate-config会报错退出 - 确认系统 glibc 版本 ≥ 新二进制编译环境要求（MySQL 官方二进制通常要求 glibc ≥ 2.28）
替换后 mysqld 启动失败，常见自修复路径
启动卡在 Starting MySQL... ERROR! The server quit without updating PID file，多数因元数据不一致触发自动修复机制失败。按顺序排查：
- 先看错误日志末尾是否出现
InnoDB: Database page corruption on disk—— 这说明需要强制恢复，临时加--innodb-force-recovery=1启动，导出关键数据再重建 - 若报
Table 'mysql.func' doesn't exist，是插件元数据未同步，执行mysql_upgrade --force --skip-sys-schema（注意：8.0.16+ 已弃用该命令，改用mysqld --upgrade=FORCE） - 遇到
Unknown table engine 'InnoDB'，通常是plugin_dir路径变更或ha_innodb.so文件权限不对（需与mysqld同属 mysql 用户，且不可被 selinux 拦截）
为什么 mysqld --upgrade=FORCE 有时不生效？
这个参数只触发系统表结构校验与补丁，不处理存储引擎层不一致。真正起作用的是启动时的隐式检查逻辑：
- 当
mysqld发现mysql.innodb_table_stats表结构版本低于当前innodb_version，才会触发重建 - 若你手动删过
mysql系统库下的统计表，或之前用过mysql_upgrade --skip-sys-schema，会导致该检查跳过 - 安全做法是：升级前备份
mysql库（mysqldump --single-transaction --routines --triggers mysql > mysql_sys_backup.sql），替换后对比SHOW CREATE TABLE mysql.innodb_table_stats是否含STATS_PERSISTENT=1
最易被忽略的一点：小版本升级后，performance_schema 表结构可能滞后，表现为查询 events_statements_history_long 报错。这不是数据损坏，而是表定义缓存未刷新——只需执行一次 FLUSH TABLES 即可，无需重启。
