回滚必须是经过实测、可验证且15分钟内完成的灾备流程，唯一可信来源为升级前的逻辑备份（mysqldump全库+参数）或物理快照（LVM/ZFS/云盘），并需校验备份有效性及在隔离环境完成闭环恢复验证。
回滚不是“以防万一”的选项，而是升级前必须跑通的逃生路径；没有真正零风险的回滚，只有经过实测、可验证、能在15分钟内完成的灾备流程。
回滚必须用逻辑备份或物理快照，不能依赖原地升级后的数据目录
MySQL 5.7 原地升级到 8.0 启动时会自动重写 mysql 系统库、重构数据字典、迁移权限表——这个过程不可逆，且不记录到 slow_log。一旦失败，/var/lib/mysql 或 /www/server/data 目录大概率已损坏，mysqld5.7 进程根本无法加载它。
所以回滚唯一可信来源只有两类：
- 升级前在 5.7 实例上执行的、带
--single-transaction和--set-gtid-purged=OFF的mysqldump全库备份（含--routines --events --triggers） - 升级前打的 LVM/ZFS/云盘快照（需确认快照时间点与备份一致，并在隔离环境验证过恢复可行性）
备份文件本身要校验：md5sum full_backup.sql 留底；解压后用 head -n 100 full_backup.sql | grep -i "create table" 快速确认头部有效。
回滚前必须实测恢复流程，不能只存文件不验证
很多团队备份做了，但没真恢复过——结果回滚时发现字符集错位、存储过程语法报错、甚至 mysql.user 表字段类型不兼容直接中断导入。
必须在独立环境（非生产、非测试）做一次完整闭环验证：
- 用干净的 MySQL 5.7 实例启动，导入备份：
mysql -u root -p - 执行关键检查：
SELECT COUNT(*) FROM information_schema.tables、SHOW CREATE TABLE查看中文字段是否仍为utf8mb3、调用一个典型存储过程 - 用应用同版本驱动连上去，执行一条简单
SELECT和带事务的INSERT
任何一步失败，都要回到备份环节查原因：是不是导出时漏了 --default-character-set=utf8mb4？是不是用户密码被 validate_password 策略拦截？
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
回滚窗口期要覆盖应用、中间件、监控全链路
数据库切回 5.7 只是第一步，应用连得上 ≠ 业务能跑通。
常见断点：
- PHP/Java 应用仍缓存着 8.0 的
caching_sha2_password认证状态，连接池（如HikariCP）复用旧连接导致报错Access denied，需重启应用或清空连接池 - MyCat/ShardingSphere 等 Proxy 未清除元数据缓存，流量继续发往 8.0 实例，造成双写污染
- Prometheus 告警规则还在查
performance_schema.table_io_waits_summary_by_table（8.0 已改名），持续误报 - 配置中心里数据库地址已指向 8.0，回滚时没同步切回，应用实际连的还是新实例
所有这些，都得在回滚预案里写明操作顺序和验证命令，比如 Proxy 清缓存命令是 reload @@metadata，而不是“检查配置”。
双主架构下回滚必须阻断复制环路，否则数据会交叉污染
若原为 A（5.7）↔ B（8.0 升级中）双主，B 升级失败后切回 A，但没停 B 的复制线程，B 上残留的 8.0 写入会通过 replica 反向同步到 A，引发主键冲突、GTID 跳变、甚至覆盖 A 的正常数据。
回滚前务必在两台机器上分别执行：
- 在 B（8.0 实例）：
STOP REPLICA;→RESET REPLICA ALL;（彻底清空中继日志和复制位点） - 在 A（5.7 实例）：
SHOW REPLICA STATUS\G确认Replica_IO_Running: No且无Last_IO_Error
这个步骤常被跳过，却是回滚后数据一致性最脆弱的一环——哪怕只漏掉一条 INSERT，后续就可能演变成难以追溯的数据漂移。
