能保留数据，但必须做对三件事：备份完整、停机窗口可控、升级路径合规；mysqldump需加--single-transaction和--set-gtid-purged=off确保事务一致与gtid兼容，小版本原地升级须保留旧程序目录并运行--upgrade，升级后须验证存储过程、事件、权限及gtid状态。
能保留数据，但必须做对三件事：备份完整、停机窗口可控、升级路径合规。跳过任一环节，轻则数据错乱，重则库不可用。
mysqldump 备份必须加 --single-transaction 和 --set-gtid-purged=OFF
不加这两个参数，备份出来的 SQL 很可能在导入时报错或丢数据。前者保证事务一致性（尤其对 InnoDB），后者避免 GTID 冲突——MySQL 8.0 默认启用 GTID，而旧版本 dump 若带 GTID 信息，新实例启动会拒绝加载。
-
--single-transaction仅对 InnoDB 有效，确保导出期间数据快照一致；若库中混用 MyISAM 表，需额外加--lock-all-tables -
--set-gtid-purged=OFF是 MySQL 5.6+ 引入的必需项，否则导入时提示ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty - 字符集务必显式指定：
--default-character-set=utf8mb4，避免源库是utf8（实际为 utf8mb3）导致 emoji 存储异常
小版本升级（如 8.0.30 → 8.0.46）可原地替换二进制文件，但必须保留旧目录
官方明确支持同大版本内小版本原地升级，但“替换”不是删旧装新，而是并存双目录 + 切换软链接或配置路径。旧目录不能删，这是回滚唯一依据。
- 新版解压后，
chown -R mysql:mysql权限必须与旧版一致，否则启动报Can't open the mysql.plugin table - 配置文件
my.cnf中的basedir和datadir路径不能动，只改basedir指向新程序目录，datadir必须指向原数据目录（即不动） - 首次启动前运行
/home/mysql-8.0.46/bin/mysqld --upgrade，让 MySQL 自动执行 schema 升级（如系统表结构变更），不可跳过
升级后必须验证三类关键对象是否完好
很多问题不是启动失败，而是功能静默失效：存储过程调用报错、事件没触发、权限丢失。这些不会阻断启动，但业务一走就崩。
- 检查存储过程/函数：运行
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');，确认数量与升级前一致 - 验证事件调度器：
SELECT * FROM information_schema.EVENTS WHERE EVENT_SCHEMA NOT IN ('mysql', 'information_schema');，再手动SET GLOBAL event_scheduler = ON;测试能否触发 - 核对用户权限：对比升级前后
SELECT User,Host,authentication_string FROM mysql.user;，特别注意mysql_native_password插件是否被强制切换为caching_sha2_password，应用连接字符串需同步更新
最易被忽略的是 GTID 状态和 binlog 位置衔接。升级后若开启主从，必须确认 SHOW MASTER STATUS 的 Executed_Gtid_Set 是否包含旧版本所有事务——这直接决定后续复制能否接续。别只看服务起来没，得看它是不是真的“认得”原来的数据。
