MySQL 8.0升级前必须单独备份mysql系统库及数据字典表，因5.7中MyISAM格式的mysql库将重构为InnoDB，并新增tables、columns等字典表；若业务库存在同名表（如mysql.columns）会导致升级失败，需提前重命名；同时须备份my.cnf及include目录配置、导出逻辑权限语句grants_backup.sql、记录binlog位置，严禁复制ib_logfile*等运行时日志文件。
备份 MySQL 8.0 升级前的系统库和数据字典表
MySQL 5.7 升级到 8.0 时，mysql 系统库会从 MyISAM 表结构彻底重构为 InnoDB 表，并新增大量数据字典表（如 columns、tables、schemata）。如果旧环境里存在同名自定义表（比如业务库中建了叫 mysql.columns 的表），升级会失败。所以不能只靠 --all-databases 一锅端。
必须单独导出并检查 mysql 库，同时排查冲突表：
- 用
mysqldump -u root -p mysql --skip-triggers --skip-events > mysql_system_backup.sql导出（跳过触发器/事件，避免 5.7 中不兼容对象干扰） - 运行
SELECT table_schema, table_name FROM information_schema.tables WHERE lower(table_schema) = 'mysql' AND lower(table_name) IN ('columns', 'tables', 'schemata', 'routines');，确认没有用户创建的同名表 - 若查出结果，必须重命名这些表，例如
RENAME TABLE mysql.columns TO mysql.columns_bak_57;
备份 my.cnf 及其 include 目录下的全部配置文件
MySQL 8.0 对配置项极其敏感：默认认证插件变成 caching_sha2_password，sql_mode 移除了 NO_AUTO_CREATE_USER，default_authentication_plugin 必须显式设置才能兼容老客户端。直接复用 5.7 的 my.cnf 很可能让服务启动失败或应用连不上。
备份时不能只拷一个文件：
- 执行
cp /etc/my.cnf /backup/my.cnf.57.bak - 检查是否启用
!include或[mysqld] !includedir /etc/mysql/conf.d/，若有，运行cp -r /etc/mysql/conf.d/ /backup/conf.d_57.bak - 用
mysqld --help --verbose | grep "Default options"确认实际加载路径，避免漏掉隐式配置
验证备份能否真正还原出权限与认证信息
仅导出 mysql 库还不够——5.7 的 mysql.user 表结构和 8.0 完全不同，密码哈希方式也变了。mysqldump --all-databases 不会自动转换字段，导入 8.0 后账号大概率失效。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
安全做法是双轨备份：
- 导出逻辑权限语句：
mysql -u root -p -Nse "SELECT CONCAT('SHOW GRANTS FOR ''',User,'''@''',Host,''';') FROM mysql.user WHERE User != 'mysql.infoschema'" | mysql -u root -p | sed 's/$/;/g' > grants_backup.sql - 记录当前认证插件：
SELECT user, host, plugin FROM mysql.user;，重点看是否含mysql_native_password - 若存在
mysql_native_password用户，升级后需手动执行ALTER USER 'xxx'@'yyy' IDENTIFIED WITH mysql_native_password BY 'zzz';
备份时忽略日志文件但必须保留 binlog 位置
升级过程不要备份 ib_logfile*、mysql-bin.* 这类运行时日志文件——它们无法跨版本复用，强行复制会导致启动报错 InnoDB: Invalid log file size。但二进制日志位置（File 和 Position）必须记下，用于升级后快速比对主从一致性或回滚点。
执行 mysql -u root -p -e "SHOW MASTER STATUS\G" > master_status_$(date +%F).txt，保存输出中的 File 和 Position 值。这个文件虽小，却是故障时定位数据边界的关键依据。
最容易被忽略的是：备份完立刻验证 grants_backup.sql 文件里有没有 GRANT 语句，以及 master_status_*.txt 是否为空——这两个文件一旦损坏或为空，升级后权限丢失或主从断链就很难补救。
