主从复制环境下升级 MySQL 会中断复制吗？
不会自动中断，但操作不当必然导致复制中断甚至数据不一致。关键不在“会不会”，而在于你是否按顺序停服务、是否校验位置、是否处理好 GTID 或 binlog 坐标。MySQL 本身允许主从版本不一致（
slave_version >= master_version），但官方强烈反对——因为
binlog_format = 'ROW'虽兼容性好，可一旦主库用 5.7 写出的 event 被 8.0 从库解析时遇到新字段（如
mysql.innodb_table_stats结构变更），SQL Thread 就会报错停止。 必须在升级前执行
STOP SLAVE;，不能只靠 kill 进程 升级后首次启动 8.0，
mysqld会自动运行字典升级，期间不可连入复制链路 若启用 GTID，升级前后必须确认
SELECT @@GLOBAL.gtid_executed;是否连续，否则
START SLAVE可能跳过事务
为什么必须先升从库、再升主库？
这是唯一能验证新版本稳定性又不伤写入的路径。从库升级失败，你只需切回原从库；主库升级失败，整个业务写入就卡死。而且 8.0 对系统表结构改动大（如
mysql.user表新增
account_locked字段、认证插件默认改为
caching_sha2_password），这些变更在从库上先跑一遍，能提前暴露应用连接层或备份脚本的兼容问题。 从库升级后，立刻执行
SELECT COUNT(*) FROM mysql.user;并与主库比对，确认权限表未因升级被意外清空 检查错误日志中是否有
Failed to open the existing table mysql.role_edges类警告——这是 5.7→8.0 字典升级未完成的典型信号 若应用仍用老版 JDBC（
mysql-connector-java 5.1.x），连接 8.0 从库会直接报
Unknown system variable 'caching_sha2_password'，得加参数
?serverTimezone=UTC&allowPublicKeyRetrieval=true&useSSL=false
主库升级时能不能不切换角色？
能，但代价是停写窗口 + 高风险。如果你选择直升主库，必须满足三个硬条件：所有从库
Seconds_Behind_Master = 0、主库无正在执行的 DDL、且已关闭业务写入（不是只读，是彻底断连）。否则哪怕只差一个 binlog event，重启后主库的
SHOW MASTER STATUS位置就和从库记录的
Relay_Master_Log_File对不上，复制无法自动续上。 升级前务必用
mysqldump --all-databases --single-transaction --routines --events --triggers做逻辑备份，别只信物理备份——xtrabackup 在跨大版本时可能无法还原 8.0 系统表 8.0.16+ 已废弃
mysql_upgrade命令，若误执行会提示
mysql_upgrade is deprecated，应直接启动 mysqld，由其自动完成字典升级 启动后立刻查
SHOW VARIABLES LIKE 'default_authentication_plugin';，若为
caching_sha2_password但旧客户端连不上，临时改回：
SET PERSIST default_authentication_plugin='mysql_native_password';
升级后最容易被忽略的三件事
第一是复制延迟监控没切到新指标：8.0 的
performance_schema.replication_applier_status_by_coordinator替代了旧版
Seconds_Behind_Master的粗粒度判断，它能告诉你具体哪个 channel 卡在哪个事务；第二是慢查询日志格式变了，默认不再记录锁等待时间，需显式开
log_output = 'TABLE'并查
performance_schema.events_statements_history_long；第三是字符集——5.7 默认
latin1，8.0 默认
utf8mb4_0900_as_cs，若建表没显式指定，老应用插入 emoji 可能直接报错。
升级不是替换二进制文件就完事，真正花时间的是验证每条 SQL 在新环境是否还走原来执行计划、每个监控项是否还在上报、每个备份恢复脚本是否还能跑通。这些细节不卡在升级当时，而藏在第二天凌晨三点的告警里。
