不能靠mysqldump导出再导入实现平滑升级，因会导致字符集错乱、认证失败、系统表损坏；mysql_upgrade在8.0.16+已废弃，启动时由mysqld自动执行元数据升级，手动运行易报错且无效。
不能靠 mysqldump 导出再导入来“平滑升级”——这会导致字符集错乱、认证失败、系统表损坏，不是平滑，是埋雷。
为什么 mysql_upgrade 在 8.0.16+ 版本里根本不能用
MySQL 8.0.16 起，mysqld 启动时会自动检测数据目录版本并执行元数据升级（比如重建 mysql.component、mysql.role_edges），mysql_upgrade 已被标记为废弃。此时手动运行它，大概率报错：
-
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded—— 因为它试图用旧客户端协议连已升级的实例 - 或直接退出，不提示任何信息
你看到的“升级成功”只是假象；真正触发升级的是首次用 8.0 的 mysqld 启动并带上 --upgrade=FORCE 参数。
必须用 mysqlsh 的 util.checkForServerUpgrade() 做兼容性扫描
mysqlcheck 只能查表是否损坏，对跨大版本的语义变更（如 utf8mb3 字符集、caching_sha2_password 插件、保留字 rank）完全无感。唯一靠谱的前置检查是官方工具：
- 下载匹配目标版本的
mysql-shell（例如 8.0.27），不要混用 5.7 的 shell - 确保 5.7 实例正在运行，且 root 有
SUPER和全库SELECT权限 - 执行：
./mysqlsh -uroot -p -S /tmp/mysql.sock -e "util.checkForServerUpgrade()"
报告里出现 ERROR 级别条目必须处理完才能继续，比如：
-
Usage of utf8mb3 charset→ 批量转utf8mb4 -
Column name 'rank' is a reserved keyword→ 改列名 -
caching_sha2_password plugin not supported by client→ 检查应用驱动版本（如mysql-connector-java ≥ 8.0.13）
原地升级时 mysqld 启动失败的三个高频原因
替换二进制、停旧服务、启新 mysqld 后卡在 “Starting MySQL”，通常不是配置写错，而是底层不兼容：
- 残留已废弃参数：删掉或注释掉
query_cache_type、innodb_file_format、explicit_defaults_for_timestamp - 没设
default_authentication_plugin=mysql_native_password→ 老 PHP/Java 客户端连不上，报错Client does not support authentication protocol - 存在 MyISAM 表：8.0 默认禁用 MyISAM 引擎，启动直接失败；要么删表，要么加
skip-grant-tables启动后导出再重建
Windows 下还要额外确认：服务名是否用 sc delete MySQL 清理干净，否则 mysqld --install 仍指向旧路径和 my.ini。
备份必须分层，只 dump SQL 不够回滚
MySQL 8.0 的数据字典已改为事务型（存于 mysql.ibd），redo/undo 格式也变了。单靠 mysqldump 无法还原物理一致性：
- 逻辑备份：
mysqldump -u root -p --all-databases --single-transaction --routines --events --set-gtid-purged=OFF - 物理备份：停机后完整打包
datadir（含ibdata1、ib_logfile*、mysql/子目录） - 特别注意：
mysql系统库绝不能直接导入 8.0 —— 字段结构已重构，plugin表也被移除
最易被忽略的一点：升级前必须执行 SET GLOBAL innodb_fast_shutdown = 0 再停服务，否则 ib_logfile* 未刷盘，8.0 启动时可能拒绝加载旧日志并崩溃。
