mysql 8.0 已于2026年4月30日eol，继续使用将面临合规风险；必须升级至当前唯一受支持的lts版本8.4.9，其参数默认值、权限模型和json行为均有关键变更，需严格校验sql_mode等三项全局变量。
升级不是为了新功能，而是为了“不掉队”
MySQL 8.0 已于 2026 年 4 月 30 日正式 EOL（End of Life），mysql --version 显示为 8.0.46 的实例，从当天起就不再接收任何官方安全补丁或关键 bug 修复。这意味着：只要还在用 8.0，你就已经处于合规风险中——等保测评通不过、审计报告被标红、漏洞扫描器直接报 CVE-2026-XXXXX 高危项。升级到 8.4.9（当前最新 LTS 维护版）不是“锦上添花”，而是“止损刚需”。
看懂版本策略比看功能列表更重要
MySQL 8.4 不是 8.0 的“增强补丁包”，它是全新定义的 LTS 基线。理解这点能避开 90% 的误判：
-
8.0是过渡型版本：自8.0.34起只修 bug、不加功能，生命周期已终结 -
8.4是稳定锚点：功能在8.4.0冻结，后续所有小版本（如8.4.9）只做安全修复与稳定性优化 -
9.0是创新通道：每季度发布、6个月后停更，mysqld启动时可能因参数废弃直接报错
生产环境选型只看一条：是否仍在官方支持周期内。目前唯一满足该条件的 8.x 版本，只有 8.4。
性能参数变化直接影响线上表现
升级后没报错 ≠ 没问题。MySQL 8.4 默认调整了多个 InnoDB 参数，对 SSD/NVMe 环境友好，但若沿用 8.0 的配置，可能引发隐性性能回退：
-
innodb_io_capacity默认值从200提升至2000：适配现代存储 IOPS，但若你的磁盘仍是 SATA SSD，需手动调低，否则刷脏页过激导致写放大 -
innodb_log_file_size默认仍为48MB，但innodb_redo_log_capacity（8.4 新增）默认128MB：两者不匹配时，SHOW ENGINE INNODB STATUS会提示 redo log 循环压力异常 -
max_connections默认值未变，但thread_pool_size在 8.4 中默认启用且行为更激进：高并发短连接场景下，线程池排队逻辑变化可能让Threads_created指标骤降，误判为连接复用率提升
最容易被忽略的兼容性断点
表面兼容不等于无缝迁移。以下三处变更常在灰度阶段才暴露：
-
replication_前缀参数全部废弃：replication_parallel_workers→ 必须改用binlog_transaction_dependency_tracking+transaction_write_set_extraction -
LOCK INSTANCE FOR BACKUP权限独立化：旧备份脚本若用FLUSH TABLES WITH READ LOCK，在 8.4 中需提前授予该新权限，否则ERROR 1227 (42501) - JSON 函数返回类型更严格：
JSON_EXTRACT对无效路径不再静默返回NULL，而是抛出ERROR 3143 (42000)，ORM 层未捕获该错误码会导致批量写入中断
真正决定升级成败的，从来不是“能不能跑起来”，而是“有没有把 sql_mode、character_set_server、collation_server 这三个全局变量在 pre-check 阶段全量比对过”。漏掉任意一项，都可能让凌晨三点的回滚操作变成数据修复。
