In-Place升级失败主因是未先用5.7完整启动即直接启8.0，导致mysql.role_edges等新系统表缺失；逻辑迁移需注意密钥、排序规则、认证插件兼容性及performance_schema表结构变更。
MySQL 5.7 升级到 8.0：In-Place 升级失败的典型表现
直接执行 mysqld --upgrade 或替换二进制后启动失败，常见报错是 Table 'mysql.role_edges' doesn't exist 或 Unknown table 'mysql.global_grants'。这不是权限问题，而是 8.0 新增系统表未被创建——In-Place 升级要求先用旧版本完整启动一次，再用新 mysqld 启动并自动运行 mysql_upgrade（8.0.16+ 已移除该命令，改由服务启动时内建处理）。
- 必须确保原实例能正常启动且
datadir可读写，否则升级流程卡在元数据校验阶段 - 跳过
mysql_upgrade等价于跳过系统表结构迁移，后续任何 DDL 或账户操作都可能崩溃 - 5.7.29+ 到 8.0.21+ 是官方支持的最小安全跨度，跨太多小版本（如 5.7.12 → 8.0.33）建议分步升到 5.7 最新版再跃迁
mysqldump 逻辑备份迁移：哪些表不能只靠导出 SQL 恢复
mysqldump --all-databases 看似完整，但会漏掉 8.0 关键元数据：加密密钥、密码历史策略、角色绑定关系、资源组定义。更隐蔽的问题是字符集处理——若源库用 utf8mb4_0900_as_cs 排序规则，而 dump 文件里没显式声明 COLLATE，导入后默认变成 utf8mb4_0900_as_cs 的弱等价规则，导致唯一索引冲突或 ORDER BY 结果异常。
- 务必加
--skip-triggers --routines --events参数，否则存储过程里的DEFINER用户可能不存在，导入时报Access denied for user ''@'' - 导出前执行
SET GLOBAL default_authentication_plugin = 'caching_sha2_password';，否则 8.0 默认插件会导致老账号登录失败 - 用
mysqlpump替代mysqldump更稳妥，它原生支持并行导出和更细粒度的对象控制
升级后连接中断：caching_sha2_password 插件引发的兼容性断层
8.0 默认认证插件从 mysql_native_password 切换为 caching_sha2_password，但 Java 8u181 之前的 Connector/J、PHP 7.2 以下的 mysqlnd、以及所有 Python 2 的 MySQL 驱动都不支持。现象是应用日志里反复出现 Authentication plugin 'caching_sha2_password' cannot be loaded，而非简单的密码错误。
- 临时方案：启动时加
--default-authentication-plugin=mysql_native_password，但仅限过渡，不解决长期安全合规问题 - 永久修复需逐个更新客户端驱动，并在创建用户时显式指定插件：
CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p'; - 检查现有用户：查询
mysql.user表的plugin字段，批量更新用ALTER USER 'x'@'y' IDENTIFIED WITH mysql_native_password;
performance_schema 表结构变更：升级后监控脚本突然报错
8.0 重写了 performance_schema，删掉了 events_waits_summary_by_thread_by_event_name 这类表，新增了 events_statements_summary_by_digest 和 prepared_statements_instances。如果你的巡检脚本或 Grafana 数据源还硬编码查旧表名，会直接返回空结果或报 Table doesn't exist。
- 不要依赖表名不变，改用
performance_schema.setup_consumers和setup_instruments动态开关采集项 - 关键指标迁移对照：
events_waits_current→events_waits_history_long；file_summary_by_instance→file_instances+file_summary_by_event_name - 升级后首次登录立刻执行
SELECT * FROM performance_schema.replication_connection_configuration\G，确认主从相关表已就位，避免误判复制中断
真正麻烦的不是步骤多，而是每个环节的隐式依赖：比如 In-Place 升级要求 innodb_fast_shutdown=1，而线上常设为 0；又比如逻辑迁移时忘记导出 sys schema，导致后续无法用 ps_helper 分析性能。这些点不报错，但会让升级后的系统处于“看似正常、实则脆弱”的状态。
