MySQL不支持不停机安装安全补丁；所有CVE修复仅随新minor版本发布，必须停服替换二进制并重启，强行热替换会导致崩溃、数据损坏；mysqld --upgrade=FORCE仅在启动时执行且依赖停服前提，主从切换等方案属架构层规避，并非MySQL自身支持热补丁。
MySQL 安全补丁不能“不停机安装”——所谓“不停机升级”，本质是通过架构层切换规避单点停机，而非 MySQL 本身支持热补丁。所有 CVE 修复（如 CVE-2025-1234）只随新 minor 版本发布，必须替换二进制并重启进程；强行在运行中替换 mysqld 或插件会触发 segfault、事务中断甚至数据页损坏。
为什么 mysqld --upgrade=FORCE 不能跳过重启
从 8.0.16 起，mysql_upgrade 已弃用，改用 mysqld --upgrade=FORCE 启动时自动校验系统表。但该操作仅在服务启动阶段执行，且依赖完整加载数据字典与 InnoDB buffer pool —— 这意味着：必须先停止旧实例，再以新二进制启动。即使你用 systemd 控制服务启停，systemctl restart mysqld 仍会产生秒级连接中断，这不是“不停机”，只是停机时间短。
主从切换式升级的实操前提
这是生产中最常用、风险相对可控的“伪不停机”方案，但有硬性约束：
- 主从复制延迟必须稳定 ≤ 100ms（
SHOW SLAVE STATUS\G中Seconds_Behind_Master接近 0） -
binlog_format必须为ROW，gtid_mode必须为ON，否则切换后可能丢事务或无法回切 - 从库升级前需先执行
STOP SLAVE SQL_THREAD，避免升级过程中写入脏数据 - 新版配置中必须移除已废弃参数（如
innodb_locks_unsafe_for_binlog），否则启动失败 - 升级后必须立即在新主库上执行
ANALYZE TABLE，否则优化器沿用旧统计信息会导致慢查询突增
容器化环境里“滚动升级”的真实限制
Docker/K8s 场景下，docker pull mysql:8.0 或 kubectl rollout restart 看似平滑，实则隐含三重陷阱：
- 镜像 tag 不稳定：
mysql:8.0可能指向 8.0.46，也可能突然变成 8.0.47 —— 若中间跳过带关键修复的 8.0.46.1，漏洞仍在 - 必须显式绑定 patch 版本和 SHA256（如
mysql:8.0.46@sha256:abc...），否则无法审计补丁落地情况 - 挂载的
/etc/mysql/my.cnf和/var/lib/mysql必须与新版本兼容；若旧配置含default_authentication_plugin= mysql_native_password，而 8.0.46 默认要求caching_sha2_password，新 Pod 将卡在启动阶段 - StatefulSet 滚动升级时，K8s 的 readiness probe 若只检查端口连通性（不执行
SELECT 1），可能将流量导至尚未完成--upgrade=FORCE的实例，导致报错Table 'mysql.component' doesn't exist
真正容易被忽略的点是：安全补丁生效 ≠ 版本号更新。有些发行版（如 Ubuntu）会对上游包做 backport，mysql --version 显示 8.0.33，但实际已包含 CVE-2024-20857 修复 —— 此时你查 Oracle Security Alerts 会误判“需升级”。正确做法是比对 SELECT VERSION(), @@version_comment; 和官方 Release Notes 中的构建标识，再交叉验证 error log 开头的编译时间戳。
