不能原地升级，必须停机走逻辑导出/导入或物理复制重建字典——这是架构级不兼容，不是配置或权限问题。MySQL 8.4启动时校验数据字典版本号，8.0仍用MyISAM/InnoDB混合系统表结构，8.4已切换为原子化、事务性字典（全内嵌mysql.ibd），强行启动报MY-013178错误；逻辑迁移需加--routines、--events、--set-gtid-purged=OFF三参数，物理迁移要求xtrabackup版本严格匹配（备份端percona-xtrabackup-80，恢复端percona-xtrabackup-84）；升级后须升级客户端驱动、清理废弃参数、手动ANALYZE TABLE。
不能原地升级，必须停机走逻辑导出/导入或物理复制重建字典——这是架构级不兼容，不是配置或权限问题。
为什么 mysqld --upgrade 在 8.0 → 8.4 时必然失败
MySQL 8.4 启动时会校验数据字典版本号，而 8.0 的 mysql.ibd 仍用旧式 MyISAM/InnoDB 混合系统表结构，8.4 已切换为原子化、事务性字典（全部内嵌在 mysql.ibd 中）。强行用 8.4 二进制启动 8.0 数据目录，会在初始化阶段直接报错退出：
2026-10-01T09:05:22.112987Z 0 [ERROR] [MY-013178] [Server] Failed to initialize DD Storage Engine
这不是临时配置可绕过的错误，是官方文档明确定义的「跨LTS大版本迁移」，强制要求逻辑或物理方式重建字典。
mysqldump 导出必须加的三个参数
选逻辑迁移（最通用）但漏掉任一关键参数，恢复后会出现存储过程失效、事件静默丢失、GTID 冲突等生产级故障：
-
--routines：不加则所有PROCEDURE/FUNCTION不会被导出 -
--events：不加则所有定时EVENT全丢，业务调度中断 -
--set-gtid-purged=OFF：8.0 若未开启 GTID，该参数默认注入SET @@GLOBAL.GTID_PURGED，导致 8.4 恢复时报错GTID_PURGED can only be set when GTID_MODE = ON
正确命令示例：
mysqldump -u root -p --all-databases --routines --events --set-gtid-purged=OFF --single-transaction > mysql_80_full.sql
物理迁移中 xtrabackup 版本必须严格匹配
物理方案快但敏感，xtrabackup 对 MySQL 主版本强绑定。混用会导致 ibdata1 校验失败或页格式无法识别：
- 备份端必须用
percona-xtrabackup-80（如 8.0.35），用于备份 8.0 实例 - 恢复端必须用
percona-xtrabackup-84（如 8.4.11），用于--prepare并还原到全新 8.4 实例 - 用
percona-xtrabackup-80直接还原到 8.4 目录，大概率启动失败
实测中，仅上述组合能稳定通过 xtrabackup --apply-log 和后续 mysqld 启动验证。
升级后最容易被忽略的三件事
很多团队导完数据就认为完成，结果上线后连不上、查不出、慢得离谱：
- 客户端驱动必须升级：
caching_sha2_password是 8.4 默认认证插件，老 JDBC/ODBC 驱动（如 MySQL Connector/J 5.x 或更早）会直接拒绝连接 - 配置文件里要显式关闭已移除参数：例如
query_cache_size、sql_mode中的NO_AUTO_CREATE_USER，否则mysqld --validate-config会报错退出 - 必须手动执行
ANALYZE TABLE：8.4 优化器统计信息缓存机制变更，旧统计可能沿用数小时；对核心表分批执行（如ANALYZE TABLE order_db.orders, user_db.users），避免锁表阻塞
字符集、权限模型、系统视图字段（如 INNODB_METRICS 新增 COUNT_RESET）这些底层变化，不会在日志里高亮提醒，但会静默影响监控脚本和业务 SQL 行为。
