必须备份 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 都可能静默失败。
