零停机迁移实为秒级停机，依赖主从切换；原地升级必停服且高危；mysqldump --all-databases 会导出不兼容的5.7系统库，导致8.0启动失败或root无法登录；须仅导业务库并手动剔除mysql库相关内容；8.0的mysql库必须全新初始化；主从复制需对齐sql_mode、认证插件及时区/大小写设置；clone实际停机5–15秒，recipient重启后需清理auto.cnf并重置server_uuid；gtid切换须先在5.7启用再建从，否则gtid_purged设置不安全。
零停机迁移不是“不切流”，而是把停机窗口压缩到秒级，靠主从切换实现。原地升级（直接替换二进制）一定会停服，且风险极高，不能用于生产。
为什么不能用 mysqldump --all-databases 直接导入？
它会把 5.7 的 mysql 系统库一并导出，而 8.0 的 user 表结构已变更：password 字段被移除，改用 authentication_string；引擎强制为 InnoDB；权限模型重构。一旦导入，mysqld 启动失败或 root 登不进去是常态。
- 只导业务库：
mysqldump --databases myapp shop --default-character-set=utf8mb4 -u root -p > business.sql - 若误含
mysql，手动删掉所有CREATE DATABASE mysql、USE mysql及INSERT INTO mysql.行 - 目标 8.0 实例的
mysql库必须是全新初始化的，不能复用 5.7 的数据目录
主从复制搭建时最关键的兼容性控制点
5.7 → 8.0 复制可行，但默认配置下极易中断。核心要对齐三处隐性策略：
-
sql_mode必须关闭已移除项：启动前在 8.0 配置中显式清除NO_AUTO_CREATE_USER，否则 IO 线程报错退出 - 认证插件需统一：5.7 默认用
mysql_native_password，8.0 默认是caching_sha2_password；若应用驱动未升级，必须在 8.0 的my.cnf中设default_authentication_plugin=mysql_native_password - 时区和大小写敏感性必须一致：检查
system_time_zone、lower_case_table_names，不一致会导致表找不到或同步卡住
克隆插件（CLONE）的真实停机成本是多少？
CLONE 不是零停机，而是“极短停机”——recipient 完成克隆后自动退出并重启，这个重启过程就是实际停机点，通常 5–15 秒。它适合对停机容忍度极低但能接受秒级中断的场景。
- donor 加的是轻量备份锁，DML 不受影响，但任何 DDL 都会阻塞克隆
- recipient 克隆完成后强制重启，必须手动清理
auto.cnf并重置server_uuid，否则无法加入集群或启动主从 - 插件必须永久加载：
plugin-load-add = mysql_clone.so+clone = FORCE_PLUS_PERMANENT，动态INSTALL PLUGIN重启即失效
最易被忽略的其实是 GTID 模式切换时机：如果目标端已启用 GTID，而源 5.7 未开启，就不能直接挂从；必须先在 5.7 上启用 GTID（在线操作可行），再建从，否则 SET GLOBAL gtid_purged 无法安全设置，后续切换必然丢事务。
