升级前必须做不可跳过的备份：物理备份用xtrabackup需记录binlog位置并验证可恢复性，逻辑备份用mysqldump须加--set-gtid-purged=off和--skip-triggers，同时归档配置文件及启停脚本；小版本升级须让mysqld自动校验数据字典，禁用mysql_upgrade；回滚失败主因是binlog格式、系统表结构及认证插件不兼容，须提前应对。
升级前必须做哪些不可跳过的备份
不备份就升级等于裸奔。MySQL 8.0升级后无法原地降级，回滚唯一可靠路径就是恢复备份——不是“可能用得上”，而是“没它就彻底失败”。
- 物理备份用
xtrabackup：必须记录binlog位置（--slave-info），否则主从同步会断；备份后立即用xtrabackup --prepare验证可恢复性 - 逻辑备份用
mysqldump：务必加--set-gtid-purged=OFF和--skip-triggers，否则 GTID 位点和触发器定义会污染旧环境 - 连同配置文件、启停脚本、
my.cnf路径下的所有文件一起打包存档；新版启动时若找不到旧配置项（如query_cache_type），会直接报错退出
小版本升级（8.0.30 → 8.0.46）怎么避免数据字典损坏
小版本升级看似安全，但 MySQL 8.0 的数据字典是强耦合的，mysqld 启动时自动校验失败就会卡住，不是报错而是静默 hang 住。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 绝对不要依赖
mysql_upgrade：该命令在 8.0.16+ 已被弃用，新版启动时由mysqld自动完成元数据检查 - 启动时显式加
--upgrade=NONE可跳过校验，但仅限测试兼容性；生产环境必须让mysqld自动执行校验，否则后续 DDL 可能写坏字典 - 若启动卡在
Starting data dictionary initialization，立刻查错误日志里是否出现Table 'mysql.component' doesn't exist——说明系统库缺失，需从备份中恢复mysql库（注意：不能只恢复表结构，必须含数据）
回滚失败最常见的三个原因及应对
回滚不是“把旧二进制文件拷回去再启动”那么简单，8.0 的变更已深度渗透到数据文件和 binlog 中。
-
binlog格式不兼容：升级后若产生过ANONYMOUS_GTID_LOG_EVENT类型事件，5.7 或旧版 8.0 的mysqlbinlog无法解析，复制中断。对策：升级前设binlog_format=STATEMENT，且升级窗口内禁止任何 DDL - 系统表结构已变更：比如
performance_schema表新增字段，旧版无法加载。对策：回滚前先用旧版mysqld启动空实例，导出空的performance_schema结构，再导入到待恢复库中 - 用户认证插件不匹配：8.0 默认用
caching_sha2_password，旧客户端连不上。对策：升级后立即运行ALTER USER 'xxx'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';，并确保应用连接串指定defaultAuthenticationPlugin=mysql_native_password
为什么“保留旧程序目录”不是可选项而是强制项
旧程序目录不只是为了回滚，更是应急诊断的唯一入口。一旦新版本启动失败，你无法用新 mysqld 解析旧数据目录的内部格式差异。
- 必须保留完整旧版目录（如
/home/mysql-8.0.30-el7-x86_64），包括bin/、lib/、share/全部内容，删掉任一子目录都可能导致mysqld --help报错 - 回滚时不是简单改 service 文件路径，而是要确保
LD_LIBRARY_PATH指向旧版lib目录，否则加载libmysqlclient.so版本冲突会 Segmentation fault - 哪怕磁盘空间紧张，也不能用软链接替代真实目录——某些启动参数（如
--defaults-file）在符号链接路径下解析异常，导致配置不生效
mysqld 打开过一次，哪怕只读，其内部页格式、字典缓存、事务系统状态就已按新规则重写。这时候再想靠“换回旧程序”启动，大概率是徒劳。
