必须用mysqldump做逻辑备份，因文件拷贝仅支持同版本恢复，5.7 ibd无法被8.0加载；正确命令含--single-transaction、--routines、--events、--triggers、--default-character-set=utf8mb4、--set-gtid-purged=off；还需冷备份物理数据、备份配置文件与用户信息，并严格验证备份完整性。
必须用 mysqldump 做逻辑备份，不能只靠文件拷贝
直接 tar 打包 /var/lib/mysql 或宝塔的 /www/server/data 目录，只能用于同版本恢复，5.7 的 ibd 文件无法被 8.0 正常加载——数据字典结构已重构，强行挂载会报 Tablespace mismatch 或启动卡死。
正确做法是用 mysqldump 导出可移植的 SQL 文本：
- 加
--single-transaction（InnoDB 表无锁导出） - 加
--routines --events --triggers（否则存储过程、事件、触发器全丢） - 显式指定字符集：
--default-character-set=utf8mb4（避免 5.7 的utf8被 8.0 错误转义） - 加
--set-gtid-purged=OFF（若没开 GTID，否则导入时报错）
完整命令示例：mysqldump -u root -p --all-databases --single-transaction --routines --events --triggers --default-character-set=utf8mb4 --set-gtid-purged=OFF > full_backup_$(date +%F).sql
备份后必须额外保存一份物理快照
逻辑备份能还原数据，但无法覆盖升级过程中 mysqld 自动执行的数据字典升级失败场景——比如系统表损坏、权限表迁移中断。此时 error log 只会报 Failed to upgrade data dictionary，无回退路径。
所以必须同步做一次冷备份（停库后）：
- 先
systemctl stop mysqld（或宝塔面板停服务） - 再
tar -czf mysql_data_$(date +%F).tar.gz /www/server/data（宝塔路径）或/var/lib/mysql（通用路径） - 确认 tar 包解压后目录结构完整，尤其检查
mysql/子目录存在且非空
这个压缩包不是用来“导入”的，是升级失败时唯一能回滚到 5.7 的救命备份。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
别漏掉配置文件和用户密码记录
升级后 my.cnf 里很多参数会被拒绝启动（如 query_cache_type），但你得知道原来怎么配的，才能删减重写。同时，mysql.user 表结构在 8.0 已变，旧密码哈希值可能失效。
执行这两件事：
- 备份当前配置：
cp /etc/my.cnf /etc/my.cnf.backup-57 - 导出所有用户明文信息（不含密码哈希）：
mysql -u root -p -e "SELECT host,user,plugin FROM mysql.user;" > user_plugin_$(date +%F).txt - 手动记下 root 和关键业务用户的密码（或用
SELECT authentication_string FROM mysql.user WHERE user='root'备份哈希值，供降级时复用）
备份验证比备份本身更容易被跳过
导出命令没报错 ≠ 备份可用。常见失效情况：磁盘满导致 SQL 文件截断、max_allowed_packet 不足导致大 BLOB 字段丢失、视图定义含 8.0 不兼容语法但 mysqldump 不校验。
验证动作必须做：
- 用
head -n 20 full_backup_*.sql确认开头有CREATE DATABASE和USE语句 - 用
tail -n 20 full_backup_*.sql确认结尾有UNLOCK TABLES和COMMIT - 抽一个业务库，用
grep -A 5 -B 5 'CREATE TABLE.*your_table' full_backup_*.sql检查字段定义是否完整
最硬核验证：找一台测试机，装干净的 MySQL 5.7，导入备份，看能否连上、查出数据、执行存储过程——这步省掉，等于没备。
