MySQL 版本升级时当然可以保留原有数据，但前提是三件事一项都不能出错：备份必须完整，停机时间要可控，升级路径也必须符合官方规范。使用mysqldump备份时，建议务必带上--single-transaction和--set-gtid-purged=OFF，这样才能同时保证事务一致性与GTID兼容性；如果采用同大版本内的小版本原地升级，旧程序目录绝不能删除，还必须执行--upgrade；等升级完成后，还需要逐项检查存储过程、事件、权限以及GTID状态，做到这些才算真正完成MySQL升级收尾。
MySQL升级可以保留项目数据，但必须把三件关键事项处理正确：备份完整、停机窗口可控、升级路径合规。任何一个环节被忽略，轻则出现数据不一致，重则数据库无法正常使用。
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）可原地替换二进制文件，但必须保留旧目录
对于 MySQL 同一大版本内的小版本升级，目前是明确支持原地升级的，但这里的“替换”并不等于删除旧版后重新安装，而是保留旧目录并存，通过切换软链接或修改配置路径完成版本切换。旧程序目录不能删除，因为它是后续回滚的唯一保障。
- 新版解压完成后，
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 升级，例如系统表结构更新，这一步绝对不能省略
升级后必须验证三类关键对象是否完好
很多 MySQL 升级问题并不会表现为服务启动失败，而是业务功能在后台静默失效，比如存储过程执行报错、事件任务不再触发、账号权限异常等。这些问题不会阻止数据库启动，但业务一旦运行，就可能立刻暴露风险。
- 检查存储过程和函数：执行
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 位置能否顺利衔接。MySQL 升级完成后，如果后续还要继续使用主从复制，就必须重点核对 SHOW MASTER STATUS 中的 Executed_Gtid_Set 是否已经覆盖旧版本产生的全部事务。这一步直接决定后续复制链路能否无缝续接。因此，不要只看 MySQL 服务是否已经启动成功，更要确认新版本是否真正完整识别并接管了原有数据库数据。
