MySQL 8.0 不支持热打补丁，必须停服务或通过主从滚动升级实现低影响升级；因二进制、系统表、数据字典、redo log 格式等均随版本变化，mysqld 进程必须重启才能加载新逻辑，官方无运行时 patch 机制。
MySQL 8.0 没有“打补丁”这个概念，所谓补丁就是升级到一个带修复的新小版本（如从 8.0.32 升级到 8.0.45），且必须停服务或切换流量——不存在热打补丁、不重启、不影响业务的方案。真正能“低影响”的只有主从滚动升级。
为什么不能原地热升级？
MySQL 的二进制文件、系统表结构、数据字典、InnoDB redo log 格式等都随版本变化。哪怕只是小版本更新，mysqld 进程也必须重启才能加载新逻辑；未重启时旧进程仍按老规则解析请求，可能触发崩溃或数据不一致。官方从未提供运行时 patch 注入机制。
主从滚动升级：唯一可行的低停机路径
适用于主从架构（一主一从或 MHA/Orchestrator 等高可用环境），目标是单节点停机时间控制在秒级，整体业务无感知。
- 先升级从库：停
mysqld→ 替换二进制 → 启动 → 自动触发--upgrade=AUTO（8.0.16+不再需要手动跑mysql_upgrade）→ 等待 SQL 线程追平 → 验证SELECT VERSION()和关键查询结果 - 执行主从切换：将应用流量切到刚升级的从库（新主），原主库变从库
- 再升级原主库：此时它已不承接写流量，停服升级风险极低
- 切回（可选）：若需保持原主库角色，再切一次；否则维持新主即可
⚠️ 注意：read_only=ON 必须在切换前对旧主显式设置，避免切流间隙写入；所有中间件（ProxySQL、ShardingSphere、应用连接池）必须支持自动重连和读写分离路由更新。
升级前必须验证的三项硬条件
跳过任何一项，滚动升级大概率失败或引发数据错乱：
-
glibc版本兼容：新版本 MySQL 二进制包要求的glibc版本 ≥ 当前系统版本（ldd --version查看），CentOS 7 默认2.17，但某些8.0.4x包依赖2.28+，强行运行会报GLIBC_2.x not found -
my.cnf参数废弃检查：8.0.34+废弃query_cache_type、innodb_log_file_size（改由innodb_redo_log_capacity控制），旧配置会导致启动失败 - 字符集与排序规则兼容性：若库表用了
utf8mb4_0900_as_cs，而旧应用未适配，升级后可能出现隐式转换错误或索引失效
离线环境升级最容易踩的坑
没有网络时，依赖全靠人工搬运，出错点集中在路径和权限：
- 解压后不要直接
cp -r bin/* /usr/local/mysql/bin/，要保留原mysqld的属主和执行权限（chown mysql:mysql+chmod 755），否则启动报Permission denied - RPM 包强制安装（
--force --nodeps）后，若未卸载旧mysql-community-server，会导致systemd启动脚本冲突，systemctl start mysqld静默失败 - 用
rsync覆盖时漏掉share/目录，缺失english/errmsg.sys，导致错误码翻译异常，日志里全是Got error 1234 from storage engine这类无意义提示
真正麻烦的从来不是操作步骤，而是升级后才发现某个凌晨三点跑的报表脚本，因为 JSON_CONTAINS 行为变更或默认事务隔离级别提升，开始返回空结果——这类问题只会在业务调用链路里暴露，备份和版本号都查不出。
