MySQL 升级后发现数据丢失，先确认是不是真的丢了
升级本身不会主动删除数据，但常见误操作或兼容性问题会导致「看起来丢了」：比如
mysql_upgrade未执行导致系统表结构不匹配、新版本默认字符集变更让旧数据读取乱码、或者升级前没停写入导致
binlog或
relay log断点错乱。先别急着回滚，用
SHOW TABLES和
SELECT COUNT(*)快速验证库表是否存在、行数是否明显异常；再查
information_schema.TABLES确认
table_rows和
data_length是否为 0。
有备份时优先用物理/逻辑备份恢复，不是靠回滚事务
MySQL 的
ROLLBACK只对当前未提交的事务有效，升级过程已提交的数据无法靠它撤回。真正可用的恢复路径只有两类： 若升级前做了
mysqldump（逻辑备份）：用
mysql -u root -p db_name 导入，注意加上 <code>--default-character-set=utf8mb4避免编码冲突 若保留了完整的
datadir（物理备份）：必须停掉新实例，替换整个
data目录，再用原版本的
mysqld启动（新版二进制可能无法读旧版表空间格式） 若启用了
binlog且格式为
ROW：可用
mysqlbinlog --base64-output=DECODE-ROWS -v解析出 DML 语句，人工筛选并重放关键时间段的操作
没备份又启用了 GTID，回退到旧版本极大概率失败
MySQL 5.7+ 默认启用 GTID 后，主从复制和实例间状态强绑定。直接降级到低版本会触发
GTID_MODE = OFF_PERMISSIVE不兼容错误，
mysqld甚至无法启动。此时唯一可行路径是： 在升级前导出
SELECT * FROM mysql.gtid_executed记录原始 GTID 集合 用
RESET MASTER清空新实例 GTID 状态（仅限单机、无从库场景） 手动编辑
auto.cnf恢复旧
server-uuid（否则复制关系彻底断裂） 仍需配合物理备份还原数据，单纯改配置不能找回数据
下次升级前必须做三件事，否则恢复成本翻倍
很多团队卡在「恢复慢」不是技术问题，而是准备缺失。最常被跳过的其实是这三项：
升级前用mysqlcheck --all-databases --check-upgrade扫描不兼容表结构 确认
innodb_file_per_table = ON且每个表
.ibd文件可独立拷贝（便于按需恢复单表） 把
my.cnf中所有显式配置项（尤其
collation-server、
sql_mode）单独存档，新版本默认值变化极大，漏配会导致查询结果突变而非报错
没有备份的「回滚」本质是数据抢救，不是功能开关。真正决定成败的，永远是升级窗口前那十分钟的检查清单。
