mysql 5.7→8.0无法真正不停机，因数据字典彻底重构、系统表结构不兼容，必须执行阻塞式元数据升级；所谓“低停机”实为主从滚动切换，仅将中断压缩至2–5分钟切主瞬间。
业务不停机的“平滑升级”在 MySQL 5.7 → 8.0 场景下，**本质是伪命题**——官方不支持热升级，也没有跨大版本的在线元数据迁移机制。所谓“低停机”，实际是通过主从滚动切换实现的分钟级中断，而非真正零停机。
为什么不能真正不停机
MySQL 5.7 和 8.0 的数据字典已彻底重构：系统表（如 mysql.user、mysql.tables）结构不兼容，字段名、类型、引擎强制要求均不同；ibdata1 中的元数据格式也已变更。启动 8.0 实例加载 5.7 的数据目录时，必须执行一次阻塞式元数据升级（即重建系统表），这个过程会锁住整个实例，无法接受新连接。
- 试图用
mysqldump导出再导入来绕过，结果只是把停机时间从“升级瞬间”挪到了“导入完成前”，且极易因字符集、认证插件、保留字等问题导致导入失败或后续查询异常 -
mysql_upgrade在 8.0.16+ 已被废弃，手动调用会报错ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded，它不是升级工具，只是旧版本的补丁辅助程序 - 宝塔面板的“一键升级”按钮底层仍是原地替换 +
mysqld自动触发升级流程，仍需停服务，不是魔法
主从滚动升级：最现实的“低停机”路径
核心思路是让新旧版本共存一段时间，通过复制链路将流量逐步切走，总停机窗口控制在 2–5 分钟内（仅最后切主库那一刻）。
- 提前部署一台 MySQL 8.0 实例（同架构、同配置），用物理备份（如
xtrabackup）恢复 5.7 的全量数据，并开启--slave-skip-errors=1062,1032容忍部分 DDL 不兼容导致的复制中断 - 在 5.7 主库上启用
binlog_format=ROW和gtid_mode=ON（若未启用，需先切换并重启） - 8.0 从库启动复制后，重点监控：
SHOW SLAVE STATUS\G中的Seconds_Behind_Master、Retrieved_Gtid_Set与Executed_Gtid_Set是否持续追平 - 切流前，在 8.0 从库执行四条验证 SQL：
SELECT VERSION();、SELECT @@default_authentication_plugin;、SELECT COUNT(*) FROM mysql.user;、SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql','sys','information_schema','performance_schema');—— 确保系统表可读、业务库完整
最容易被忽略的三个实操断点
很多团队卡在“看起来成功了，但第二天就崩”，问题往往藏在细节里：
- 8.0 启动后没改
my.cnf里的default_authentication_plugin=mysql_native_password，老 PHP/Java 应用连不上，报错Client does not support authentication protocol - 没清理 5.7 配置中已废弃项，如
query_cache_type、explicit_defaults_for_timestamp，导致 8.0 启动直接拒绝加载配置文件，日志只显示unknown variable - 忘记重置 root 及业务用户密码：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';—— 因为 8.0 默认用caching_sha2_password，而旧密码哈希值无法自动转换
真正的难点不在操作步骤，而在于对“升级”二字的误判：它不是换二进制包，而是元数据层的不可逆重写。所有声称“完全不停机”的方案，要么掩盖了短暂但关键的写入冻结，要么把风险后移给了上线后的业务逻辑。
