MySQL不支持真正在线升级进程，零停机本质靠主从切换实现，前提是严格满足复制兼容性：5.7→8.0可行但需提前调整sql_mode等配置，8.0→5.7或5.6→8.0均不被官方支持；必须验证GTID、binlog_format、认证插件及lower_case_table_names等关键配置一致性，并通过SHOW SLAVE STATUS等确认同步状态。
不能真正“在线”升级 MySQL 进程本身，所谓零停机，本质是靠主从切换把流量从旧版本实例切到已同步好的新版本实例——切换窗口可压至秒级，但必须满足复制兼容性前提。
主从复制升级前必须验证 replication compatibility
MySQL 不支持反向或任意跨版本复制。例如：
-
5.7 → 8.0可行，但需提前在 5.7 主库关闭sql_mode中已移除的项（如NO_AUTO_CREATE_USER） -
8.0 → 5.7不可行：8.0 的 binlog event 类型（如ANONYMOUS_GTID_LOG_EVENT）5.7 无法解析，启动从库即报错Unknown binlog event type -
5.6 → 8.0不被官方支持：中间缺失 5.7 兼容层，GTID、密码认证插件、数据字典结构差异都会导致同步中断或数据损坏
验证方式：在目标从库上启动 mysqld 后执行 SHOW SLAVE STATUS\G，重点观察 Seconds_Behind_Master 是否持续为 0，以及 Slave_SQL_Running_State 是否稳定为 Slave has read all relay log。
搭建新版本从库时的关键配置差异
新版本（如 8.0）从库不能直接复用旧版（如 5.7）的配置模板，以下几项必须显式校准：
-
binlog_format必须设为ROW：5.7 默认是STATEMENT，而 8.0 对STATEMENT复制支持更弱，易出现函数/UUID/时间相关不一致 -
enforce_gtid_consistency=ON和gtid_mode=ON强烈建议启用：避免切换时因 binlog position 漂移导致数据丢失；若原主库未开 GTID，需先升级主库开 GTID（需全量锁表一次），再配从库 -
default_authentication_plugin=mysql_native_password（8.0.4+ 默认是caching_sha2_password）：否则应用连接旧账号会报Client does not support authentication protocol -
lower_case_table_names=1必须与主库严格一致：否则表名大小写敏感差异会导致Table doesn't exist错误，尤其在 Windows→Linux 迁移时极易踩坑
切换流量时最容易被忽略的三个动作
主从角色切换不是只执行 STOP SLAVE; CHANGE MASTER TO ...; START SLAVE; 就完事。真实生产中失败多发生在收尾环节：
- 切主前，必须在旧主库上执行
FLUSH TABLES WITH READ LOCK;并记录SHOW MASTER STATUS输出——这是确保从库追平最后一条事务的唯一可靠依据，仅靠Seconds_Behind_Master = 0不够（可能 SQL 线程卡在锁等待） - 新主库启动后，立刻执行
SELECT @@read_only;确认值为OFF；若仍为ON，写请求会被拒绝，现象是应用报The MySQL server is running with the --read-only option - 切流后，必须验证新主库的
gtid_executed是否包含旧主库最后的 GTID（SELECT @@gtid_executed;对比），否则后续再加从库会因 GTID gap 导致同步失败
为什么 pt-online-schema-change 或 gh-ost 不能替代主从升级
这两款工具只解决 DDL 锁表问题，和 MySQL 服务进程升级完全无关：
- 它们不替换
mysqld二进制文件，也不触碰mysql系统库表结构（如mysql.user、mysql.role_edges） - 若在 5.7 主库用
gh-ost迁移完一张业务表，再直接把该实例升级到 8.0 —— 启动时会因mysql.user表字段缺失（如password_last_changed）而崩溃，报错Table 'mysql.user' doesn't have column 'password_last_changed' - 跳过
mysql_upgrade直接启动 8.0 读取 5.7 数据目录，必然失败，错误信息是Table 'mysql.role_edges' doesn't exist（该表 8.0 新增，5.7 无对应结构）
真正的零停机升级，核心不在工具多炫酷，而在对版本边界、系统表演进、复制机制的理解是否扎实——漏掉任一隐性约束，切换瞬间就可能变成故障现场。
