MySQL升级时数据文件不被删除，但需执行mysqld --upgrade=FORCE完成字典迁移，否则系统表不可用、权限失效；推荐逻辑导出+干净安装或主从滚动升级。
升级 MySQL 时数据文件本身通常不会被删除
MySQL 升级（如从 5.7 到 8.0）默认不触碰 datadir 下的表空间文件（ibdata1、.ibd、.frm 或 8.0+ 的 .sdi）和日志文件（ib_logfile*）。只要不手动执行 mysqld --initialize 或勾选“重新初始化数据目录”类选项，原始数据物理上仍保留在磁盘上。
但“不删除”不等于“可直接用”——升级后 MySQL 实例能否正常启动、表能否查询、字符集是否错乱，取决于后续兼容性处理是否到位。
最关键的破坏点：incompatible data dictionary 或系统表结构变更
MySQL 8.0 彻底重构了数据字典（Data Dictionary），将原 MyISAM 系统表（如 mysql.user、mysql.db）转为 InnoDB，并引入原子 DDL 日志。5.7 的系统表结构与 8.0 不兼容，直接替换二进制文件会导致启动失败或权限失效。
- 升级前必须运行
mysql_upgrade（5.7→8.0 时该工具已被弃用，改用mysqld --upgrade=FORCE） - 跳过升级步骤会报错：
Table 'mysql.user' doesn't exist或Unknown table 'mysql.component' -
mysql.system_variables等新视图在未完成字典迁移前不可查 - 若使用 Percona Server 或 MariaDB 分支，其系统表扩展字段可能与官方 8.0 冲突，需提前验证补丁兼容性
容易被忽略的隐性丢失场景
数据没删，但业务读不到，等效于丢失。常见诱因包括：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 字符集降级：8.0 默认
utf8mb4_0900_as_cs排序规则，而 5.7 应用若显式依赖utf8mb4_general_ci，升级后ORDER BY结果可能变化，索引失效导致查询为空 - SQL 模式收紧：8.0 默认启用
STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY，旧 SQL 插入隐式转换值（如空字符串进 NOT NULL INT）会直接报错而非截断，应用未捕获异常即丢数据 - 时间类型精度变更：5.7 的
DATETIME默认无小数秒，8.0 支持DATETIME(6)；若备份时未指定--skip-tz-utc，跨时区恢复可能使NOW()值偏移 - GRANT 权限存储位置迁移：5.7 权限存在 MyISAM 表中，8.0 存于数据字典；未执行升级命令就重启，所有账号变成匿名用户（
''@'localhost'）
真正安全的升级路径只有两条
别信“就地升级最省事”。生产环境只推荐：
-
逻辑导出 + 干净安装：用
mysqldump --all-databases --routines --triggers --set-gtid-purged=OFF导出，再导入到全新 8.0 实例。虽慢，但彻底规避字典/权限/排序规则残留问题 -
主从滚动升级：先部署 8.0 从库，同步完成后提升为主，原 5.7 实例停写并校验。要求 binlog 格式为
ROW，且确认slave_type_conversions兼容旧表结构
任何跳过 mysqld --upgrade、绕过字符集检查、或在升级中修改 my.cnf 的 default_authentication_plugin 参数的行为，都可能让数据处于“存在但不可访问”的灰色状态。
