MySQL 8.4.9 是当前唯一仍受官方支持的 8.x 版本，MySQL 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.4 LTS 不是选择题，而是止损需求
MySQL 8.0 已于 2026 年 4 月 30 日正式结束生命周期（EOL），此后不再获得任何安全补丁或关键性 Bug 修复。这也意味着：
- 所有仍在运行的 8.0 实例，从该日期起都处于缺乏最新安全保障的状态
- 审计报告通常会被直接标红，云厂商也可能拒绝续保，甚至暂停相关服务接入
- 即使当前没有明显报错、业务表面运行稳定，也依然属于带风险运行
MySQL 8.4 并不是 MySQL 8.0 的简单功能增强版本，而是重新定义后的 LTS 长期支持基线：功能在 8.4.0 已冻结，后续小版本（如 8.4.9）主要聚焦安全修复和稳定性优化。对于生产环境数据库版本选型，核心判断标准只有一个：是否仍处于官方最新支持周期内。目前满足这一条件的 8.x 版本，只有 MySQL 8.4。
配置参数变化，可能在升级后隐性拖慢数据库性能
升级后 mysqld 能成功启动，并不等于数据库就能稳定高效运行。MySQL 8.4 默认调整了多项 InnoDB 参数，对 NVMe 场景更友好，但如果直接沿用 MySQL 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% 的启动失败类风险
真正困难的部分，从来不是执行升级命令本身，而是确认哪些旧参数配置、哪些备份脚本、哪些监控指标，在 MySQL 8.4 LTS 下已经发生语义变化——这些关键细节通常不会出现在 release note 的标题里，却很可能在生产环境凌晨告警时集中暴露。
