MySQL 5.7 迁移至 8.0 要实现业务不停服且保证数据一致性，推荐采用基于主从复制的滚动升级方案，先搭建 MySQL 8.0 从库同步数据，验证无误后再切换应用连接，避免原地升级导致的长时间停机。
先说结论：跨大版本升级无法做到绝对零停机，但通过主从复制切换可将停机窗口控制在秒级，核心在于同步延迟监控与兼容性预检。
- 适合：生产环境高可用架构，要求业务中断时间最短的场景。
- 先准备：确认所有表引擎为 InnoDB，备份全量数据，检查保留字与语法兼容性。
- 验收：对比主从行数与 GTID 集合，执行应用功能回归测试，确认无报错。
命令速用版
以下命令用于快速检查版本、同步状态及数据一致性，需在 MySQL 客户端执行。
检查当前版本与引擎：
SELECT VERSION(); SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db' AND engine != 'InnoDB';
查看主从同步延迟与 GTID：
SHOW SLAVE STATUS\G（关注 Seconds_Behind_Master 与 Executed_Gtid_Set）
导出业务数据（逻辑备份）：
mysqldump -uroot -p `--single-transaction` `--routines` `--triggers` `--databases` db_name > backup.sql
为什么会这样
原地升级必须停机且不可逆，而主从复制方案允许新旧版本并行运行，提供回滚余地。
MySQL 5.7 到 8.0 涉及数据字典重构、默认字符集变更（utf8 到 utf8mb4）及认证插件调整（mysql_native_password 到 caching_sha2_password），直接原地升级若失败会导致数据目录不可用。通过搭建 8.0 从库，可以在不影响主库写入的前提下验证兼容性，切换瞬间仅需修改应用配置指向新库，实现业务感知最低。
分步处理
按以下顺序执行迁移，每步完成后需确认状态再进入下一步。
1. 前置兼容性检查
使用 MySQL Shell 工具扫描实例，识别不兼容对象。命令：util.checkForServerUpgrade()。重点检查是否有 MyISAM 表，8.0 不再支持 MyISAM 系统表，需提前转换为 InnoDB。
2. 搭建 8.0 从库
在新服务器安装 MySQL 8.0，配置为 5.7 主库的从库。确保 binlog 格式为 ROW 或 MIXED，开启 GTID 模式以便精确追踪同步位点。
3. 等待数据追平
监控从库同步状态，直到Seconds_Behind_Master为 0。记录主库当前 GTID 集合，在从库执行SELECT WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()确保事务完全执行。
4. 切换应用连接
停止应用写入，确认从库无延迟后，修改应用数据库连接地址指向 8.0 实例。启动应用，观察日志无连接报错。
怎么验证是否生效
数据一致性需通过数量比对与业务功能双重确认，不能仅依赖同步状态。
1. 数据行数比对
对核心表分别在 5.7 和 8.0 执行SELECT COUNT(*)，确保数值一致。若存在差异，检查是否有未同步的事务。
2. 字符集与权限验证
检查 8.0 实例默认字符集是否为 utf8mb4，确认旧用户能否登录。若出现Client does not support authentication protocol报错，需将用户认证插件改回 mysql_native_password 或升级客户端驱动。
3. 业务功能回归
执行核心业务流程，特别是涉及特殊字符插入、复杂 SQL 查询及存储过程调用的场景，确认无语法报错。
常见坑
以下问题在迁移中高频出现，需提前干预避免中断。
1. 认证插件不兼容
MySQL 8.0 默认使用 caching_sha2_password，旧版 PHP 或 Java 驱动可能不支持。解决方法是在 8.0 中执行ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';。
2. 字符集截断风险
5.7 默认 utf8 最多 3 字节，8.0 默认 utf8mb4 为 4 字节。若导入时未指定字符集，旧表字段长度可能不足导致中文截断，建议建表时显式指定 CHARSET=utf8mb4。
3. 保留字冲突
8.0 新增了保留字（如 RANK、SYSTEM），若表名或列名与之冲突，查询会报错。需使用反引号包裹标识符或重命名对象。
常见问题
迁移过程中需要停机多久？
采用主从切换方案，停机时间仅取决于应用重连速度，通常为秒级。
如何确保迁移后数据完全一致？
除对比行数外，建议使用 pt-table-checksum 工具校验数据指纹，并核对 GTID 执行集合。
升级失败能否回滚到 5.7？
若采用主从方案，直接切回 5.7 主库即可；若原地升级，需依赖升级前的物理备份恢复，耗时较长。
参考来源
1. CSDN 博客：大数据量的迁移，MySQL 5.x → 8.0 升级设计实施
2. CSDN 博客：MySQL5.7 升级到 MySQL8.0 并进行数据迁移
3. CSDN 博客：mysql 迁移数据时如何保证数据一致性_mysql 一致性保证方法
4. CSDN 博客：宝塔面板 MySQL 5.7 平滑升级到 8.0 怎么做_全量备份与参数迁移方案
5. CSDN 博客：第 08 篇:MySQL 5.7 → 8.0 升级实战全指南：新特性 · 破坏性变更 · 零停机迁移手册