MySQL 8.4.9是当前唯一受支持的8.x版本，8.0已EOL且存在合规与安全风险；升级需关注参数变更、兼容性断点及util.checkForServerUpgrade检查。
适合，但不是“自动适合”——MySQL 8.4.9（当前最新 LTS 维护版）是目前唯一仍在官方支持周期内的 8.x 版本，继续使用 MySQL 8.0（mysql --version 显示为 8.0.46 等）已构成合规风险，等保测评通不过、漏洞扫描器直接报 CVE-2026-XXXXX 高危项。
MySQL 8.0 已 EOL，升级不是选题而是止损刚需
MySQL 8.0 于 2026 年 4 月 30 日正式结束生命周期（EOL），此后不再接收任何安全补丁或关键 bug 修复。这意味着：
- 所有仍在运行的 8.0 实例，从当天起就处于无官方兜底状态
- 审计报告会被标红，云厂商可能拒绝续保或暂停服务接入
- 哪怕没报错、业务跑得稳，也属于“带病上岗”
MySQL 8.4 不是 8.0 的功能增强包，而是全新定义的 LTS 基线：功能在 8.4.0 冻结，后续小版本（如 8.4.9）只做安全修复与稳定性优化。生产环境选型只看一条：是否仍在官方支持周期内。目前唯一满足该条件的 8.x 版本，只有 8.4。
配置参数变更会隐性拖垮性能
升级后 mysqld 启动成功 ≠ 运行正常。8.4 默认调整了多个 InnoDB 参数，对 NVMe 友好，但若沿用 8.0 配置，可能引发写放大、连接排队异常等隐性问题：
-
innodb_redo_log_capacity新增，默认 128MB；而innodb_log_file_size仍默认 48MB —— 两者不匹配时，SHOW ENGINE INNODB STATUS会提示 redo log 循环压力异常 -
innodb_log_buffer_size从 16MB 提升至 64MB，若内存不足或实例规格偏低，可能触发频繁刷盘 -
thread_pool_size在 8.4 中默认启用且行为更激进，高并发短连接下Threads_created指标骤降，容易误判为连接复用率提升，实则线程池排队逻辑已变
三处兼容性断点常在灰度阶段才暴露
表面 SQL 能跑通，不代表业务逻辑不受影响。以下变更不报语法错误，但会在特定路径触发失败：
- 所有
replication_前缀参数废弃：replication_parallel_workers→ 必须改用binlog_transaction_dependency_tracking+transaction_write_set_extraction -
LOCK INSTANCE FOR BACKUP权限独立化：旧备份脚本若用FLUSH TABLES WITH READ LOCK，需提前授予该新权限，否则报错ERROR 1227 (42501) - JSON 函数返回类型更严格：
JSON_EXTRACT对无效路径不再静默返回NULL，而是抛出ERROR 3143 (42000)
必须验证 util.checkForServerUpgrade() 报告
别跳过这一步。MySQL Shell 内置的升级检查器能提前发现系统表结构、用户权限、存储引擎等层面的不兼容项：
- 运行
util.checkForServerUpgrade("root@localhost:3306")，它会扫描mysql系统库、用户定义函数、视图定义等 - 重点看 WARNING 级别以上输出，尤其是涉及
data dictionary或authentication plugin的条目 - 该工具无法覆盖业务 SQL 兼容性，但它能拦住 70% 的启动失败类问题
真正难的不是升级动作本身，而是确认哪些旧配置、哪些备份脚本、哪些监控指标在 8.4 下语义已变——这些细节不会出现在 release note 的 headline 里，但会在线上凌晨三点突然让你收到告警。
