必须物理备份/var/lib/mysql/mysql目录，因innodb_index_stats等系统表结构不兼容，mysqldump无法可靠导出；performance_schema和information_schema无需备份；GTID需记录gtid_executed；停机前需read_only+FLUSH TABLES WITH READ LOCK并验证无活跃连接；备份须含--single-transaction --routines --triggers --events；需检查mysql.user插件兼容性及配置文件废弃参数。
必须备份 mysql 系统库、所有业务库的结构与数据，以及 mysqld.cnf（或 my.cnf）配置文件和 mysql.user 表权限快照——漏掉任意一项都可能造成升级后服务不可用或权限丢失。
哪些数据不能只靠 mysqldump 全量导出
MySQL 升级时，mysql 系统库中的部分表（如 innodb_index_stats、innodb_table_stats、slave_master_info 等）在新旧版本间结构不兼容，直接 mysqldump 导入会失败或被忽略。它们依赖 mysql_upgrade 或 mysqld --upgrade=FORCE 重建，但前提是原始 mysql 库文件（ibdata1、系统表空间、mysql/ 目录下的 frm / ibd 文件）本身要保留或完整迁移。
- 必须物理备份
/var/lib/mysql/mysql/整个目录（或对应 datadir 下的mysql子目录），尤其当使用 MySQL 5.7+ 的 InnoDB 系统表时 -
performance_schema和information_schema不需备份——它们是内存视图，重启即重建 - 若启用了 GTID 复制，还需记录当前
SELECT @@global.gtid_executed;输出，用于新实例初始化时对齐
如何安全停机并验证备份可用性
停机不是简单执行 systemctl stop mysql 就完事。关键在于确认所有事务已落盘、无活跃连接、且备份能还原出一致状态。
- 先执行
SET GLOBAL read_only = ON;，再FLUSH TABLES WITH READ LOCK;，阻断写入 - 用
SHOW PROCESSLIST;确认无Query状态的非Sleep连接；有则需人工干预或等待 -
mysqldump必须加--single-transaction --routines --triggers --events，否则存储过程、事件调度器逻辑会丢失 - 备份完成后，立刻用
mysqlcheck -u root -p --all-databases --check验证 dump 文件语法可解析；再选一个非核心库做快速还原测试
配置文件与用户权限的隐性风险点
MySQL 8.0 起默认禁用 old_passwords，废弃 mysql_native_password 插件以外的认证方式；5.7 升 8.0 时若未提前处理，会导致老账号无法登录。
- 备份前运行
SELECT user,host,plugin FROM mysql.user;，重点检查是否含sha256_password或已弃用插件 - 对比新旧版本的默认配置差异：
sql_mode（如 8.0 默认含STRICT_TRANS_TABLES）、default_authentication_plugin、explicit_defaults_for_timestamp等，避免还原后 SQL 报错 - 配置文件中注释掉所有已废弃参数（如
query_cache_type在 8.0 中彻底移除），否则mysqld启动失败
升级不是替换二进制包就结束的事。最常被跳过的一步是：没在旧实例上运行 mysql_upgrade（针对 5.7→5.7.x 小版本）或没用新版本 mysqld --initialize 初始化系统表（针对跨大版本）。一旦跳过，mysql 库元数据损坏，后续任何权限操作或 DDL 都可能静默失败。
