8.0→8.4升级本身不强制停机，但方式决定停机时长：主从切换最稳（≤30秒）、clone插件实际停机5–15秒、就地升级必须停机且风险高；核心是提前完成数据迁移与校验，停机仅做原子切换。
直接结论：8.0 → 8.4 升级本身不强制停机，但“升级操作”是否停机，取决于你用哪种方式执行——就地升级必须停机，主从切换可压到 30 秒内，Clone 插件实际停机 5–15 秒。
主从复制切换是当前最稳、停机最短的方案
这不是理论推荐，而是大量生产环境已验证的路径。核心逻辑是：数据迁移和校验全部提前完成，停机窗口只做原子切换。
- 源库（8.0）必须开启
log_bin且binlog_format = ROW，server_id唯一且非 0 - 目标库（8.4）先初始化空实例，再执行
CHANGE REPLICATION SOURCE TO指向源库；若已有同名库表，加replica_skip_errors = DDL_EXISTING_TABLE避免建表冲突 - 启动复制后持续观察
Seconds_Behind_Source，稳定 ≤5 秒才算可用；期间用pt-table-checksum分块校验关键表一致性 - 停机窗口内只做四件事：
SET GLOBAL read_only = ON（源库）、SELECT MASTER_POS_WAIT()等追平、切 DNS/VIP、目标库SET GLOBAL read_only = OFF - 整个切换过程实测耗时通常 ≤45 秒；超时基本是因为长事务没清理或 DDL 正在执行，不是工具问题
Clone 插件适合单实例快速重建，但要注意重启停机
CLONE 不是零停机，是物理拷贝 + 自动重启，实际停机点就是 recipient 重启那几秒。它适合替换旧硬件、重建故障节点，不适合在线流量切换。
- 必须确保插件已永久加载：
plugin-load-add = mysql_clone.so和clone = FORCE_PLUS_PERMANENT写进my.cnf，重启 MySQL 后查INFORMATION_SCHEMA.PLUGINS确认状态为ACTIVE - 远程克隆需 donor 开放
BACKUP_ADMIN + REPLICATION SLAVE，recipient 用户要有CLONE_ADMIN（隐含SHUTDOWN权限） - 克隆完成后 recipient 会自动退出并重启——这是不可跳过的停机点，Linux 下一般 5–15 秒，取决于磁盘 I/O 和 buffer pool 初始化速度
- 克隆完必须手动删除
auto.cnf并重置server_uuid，否则后续配主从必失败；server_id和gtid_mode也得按新拓扑校准
就地升级（in-place）必须停机，且风险集中在字典表升级阶段
所谓“就地升级”，就是停掉 8.0 进程，换上 8.4 的二进制，再启动。MySQL 会自动运行 mysql_upgrade（8.4 中已由服务启动时内置触发），升级数据字典表结构。
- 停机时间 = 关闭 8.0 进程耗时 + 替换二进制 + 启动 8.4 + 字典表升级耗时；其中字典表升级不可跳过，500GB 实例可能卡住 2–8 分钟，取决于
innodb_buffer_pool_size和 SSD 性能 - 升级前必须用
mysqlcheck --check-upgrade和util.checkForServerUpgrade()扫描兼容性问题，比如GROUP BY隐式排序取消、mysql_native_password插件弃用等，否则启动失败或查询结果异常 - 千万别在升级过程中 kill 掉正在升级字典表的 mysqld 进程，大概率导致
mysql.ibd损坏，只能从备份恢复
真正决定停机长短的，从来不是选哪个命令，而是复制链路有没有提前跑稳、长事务有没有清干净、校验有没有在停机前做完。8.0 到 8.4 的升级动作本身很轻量，麻烦的是那些“以为没问题”的历史包袱——比如某个凌晨三点还在跑的报表事务，或者一个用了 7 年、名字撞上 8.4 保留字的视图。
