MySQL 8.0 EOL 之后的路线:留在 8.4 LTS 还是评估 9.x

更新日期：2026-10-05

先把一个容易误判的事实钉住:MySQL 8.0 的 Extended Support 已于 2026 年 4 月 结束——按 Oracle 官方生命周期表,8.0 的 Premier 支持到 2025 年 4 月、Extended 支持到 2026 年 4 月,此后进入 Sustaining Support:不再有新的维护版本与补丁,仅保留既有内容的服务。也就是说,今天还在 8.0 上的生产库,已经跑了半年「无补丁」状态;站内 MySQL 8.0 EOL 迁移实战:升级到 8.4 LTS 的兼容检查、停机窗口与回滚 解决的是「怎么迁」,本文解决的是「迁到哪」——而 2026 年的这个决策,比去年复杂了也清晰了。

复杂在于版本体系发生了两件大事:9.7 已于 2026 年 4 月 21 日 GA,是顺序版本号的最后一个 LTS(官方文档明确 9.7 之后改用年.月日历版本号,如 26.7 = 2026 年 7 月);官方下载页现在并排提供 26.7.0、9.7.2 LTS、8.4.11 LTS、8.0.46 四个系列。清晰在于:9.7 的支持期(Extended 到 2034 年 4 月)比 8.4(到 2032 年 4 月)再长两年,「8.0 → 8.4 → 9.7」的两步升级路径被官方明确支持——目标选择从「升不升 9.x」变成了「停在 8.4 还是走到 9.7,以及要不要碰日历版本」。

适用范围:自建或托管在 RDS/自管 MySQL 上的 8.0 生产库(8.0.37 及以上可走官方就地升级路径),以及刚刚完成 8.4 迁移、在评估要不要继续走一步的团队。不适用场景:还在 5.7 的——官方升级路径明确不允许 5.7 直跳 8.4/9.7,必须先到 8.0,你的路线图比本文多一章;使用云厂商托管 MySQL(RDS/Cloud SQL 等)的——大版本可用性与升级工具由云厂商控制,本文的路径与支持期是社区版口径,云上以厂商公告为准;HeatWave/企业版专有功能的评估——本文只覆盖社区版事实。

先看结论

1. 8.0 已在 Sustaining Support:Oracle 官方口径下不再有新补丁。「EOL 是明年/后年」的认知需要更新,合规审计问起来,「2026 年 4 月」是标准答案。
2. 8.4 LTS:Premier 到 2029 年 4 月,Extended 到 2032 年 4 月;8.0.37+ 可直接就地升级。这是最稳的目标,站内既有迁移文完整覆盖。
3. 9.7 LTS:Premier 到 2031 年 4 月,Extended 到 2034 年 4 月,是顺序版本号的最后一条 LTS 线;但 8.0 不能直跳 9.7,官方升级路径要求 8.0 → 8.4 → 9.7 两步走。
4. 9.7 之后是日历版本(26.7、27.7……):Innovation 轨,只支持到下一个 Innovation 发布,官方定位是「提前验证」。生产主力库不该出现在这条轨上。
5. 升 8.4 最大的坑是认证插件:mysql_native_password 自 8.4.0 默认禁用(可参数开启),9.0 起服务端直接移除——老应用账号的兼容检查是第一步,不是最后一步。
6. 8.4 的 InnoDB 默认值变化是性能特性也是行为变化:adaptive_hash_index 默认 OFF、change_buffering 默认 none、io_capacity 默认 10000 等,升级后基准测试要重跑,不能沿用 8.0 的调优结论。
7. 9.x 的 VECTOR 类型与 JavaScript 存储程序是真实的差异化能力(AI 应用场景),但它们不构成生产库迁移的理由——为「以后可能用」支付双倍升级停机,不划算;正确姿势是先到 8.4,窗口期到了再评估 9.7。
8. 留在 8.0 没有免费选项:Oracle 侧无补丁,第三方(如 Percona)提供付费的后 EOL 支持——它可以是过渡期的保险,不是终点方案。

版本全景:四个系列与生命周期

官方下载页与 Oracle 生命周期政策(2026-10-05 核实)拼出的全景:

发布模型上,官方手册的定义:LTS 与 Innovation 双轨都是生产级、都含安全修复;LTS 遵循 Oracle 政策(5 年 Premier + 3 年 Extended,文档另一处表述为 8 年以上支持);Innovation 只支持到下一个 Innovation 发布。26.7.0(2026-07-28)作为首个日历版本,还引入了 compatibility-lineage validation——版本血统校验,配合日历版本防止「26.7 直接升 27.7 跳过中间线」这类事故。

这张表给出的决策骨架:8.0 的下一站只能先是 8.4(路径约束决定),真正的问题是从 8.4 再往前走到 9.7,还是停在 8.4 收工。

路线 A:升到 8.4 LTS——最短路径,但默认值要先吃透

8.0.37 及以上可以直接就地升级(logical/replication 路线亦可),这是最短、被验证最充分的路径。但 8.4 相对 8.0 的默认值变更不是「无害优化」,官方手册的变更表里有几项会直接改变行为:

同时移除的选项:default_authentication_plugin、--ssl/--admin-ssl(及 have_ssl/have_openssl)、binlog_transaction_dependency_tracking、--no-dd-upgrade、--old/--new——还在用这些参数的 my.cnf,升级时会起不来,这是升级窗口里最常见的「第一分钟事故」。

认证插件的检查放在升级评估的第一步:

-- 谁还在用 mysql_native_password?升级 8.4 前必须清零或专项处理
SELECT user, host, plugin FROM mysql.user WHERE plugin NOT IN ('caching_sha2_password');

命中的账号,要么升级应用驱动支持 caching_sha2_password,要么制定专项改造——--mysql-native-password=ON 是给改造期的缓冲,不是长期方案,因为 9.0 起服务端直接移除了它。升级流程、停机窗口与回滚的完整操作,站内 MySQL 8.0 EOL 迁移实战 已逐步写过,本文不重复;只强调一个被默认值变化放大的点:升级后在预生产重跑基准,8.4 的 InnoDB 新默认值是为现代硬件调的,你基于 8.0 默认值做的调优参数表需要重新评估,而不是原样搬过去。

路线 B:走到 9.7 LTS——为支持期与能力多付一步

9.7 的两块吸引力,一块是账面的:Extended 支持到 2034 年 4 月,比 8.4 多两年,「下一次大迁移」的时间点从 2032 推到 2034;一块是能力的:9.0 引入、9.7 延续的 VECTOR 类型(4 字节浮点、默认长 2048、最大 16383,不能作主键/外键/分区键)与 JavaScript 存储程序(需安装 MLE 组件,含 JS SQL API 与 GenAI API)——前者是 MySQL 正式回应 AI 应用内嵌向量检索的需求,后者把存储过程的语言生态拉开了代差。

但成本面也要看清:路径上,8.0 → 9.7 不被允许,必须 8.0 → 8.4 → 9.7。官方升级路径表写得很清楚:LTS 可以直跳下一个 LTS,跨过下一个 LTS 的升级必须两步。对正在 8.0 的团队,这意味着「一步到 8.4 然后收工」与「一步到 8.4 然后再走到 9.7」的区别只是第二个升级窗口的排期,而不是路径选择——你可以把 9.7 的决策推迟到 8.4 之后,这是本路线最务实的部分。另外 9.7 手册里的移除项(如 replica_parallel_type)与默认值调整(log_writer_threads 按 CPU/log_bin 动态判定)在第二个窗口同样要过一遍升级检查。

给 9.x 的采用建议:为明确的需求走 9.x——应用已经在别处维护向量库(pgvector/Elasticsearch)且希望收敛组件、或确实要 JS 存储程序的团队,把 9.7 列入 8.4 之后 12–18 个月内的计划;否则停在 8.4,把 VECTOR 当成「下次再评估」的条目。为「以后可能用」支付第二个停机窗口,是数据库迁移里最常见的伪需求。

路线 C:26.7+ 日历版本——生产不碰,但要知道它是什么

日历版本(Innovation 轨)的定位官方说得很直白:提前验证新特性,支持到下一个 Innovation 发布。26.7.0 引入的 compatibility-lineage validation 也说明了这轨道的实验属性——版本血统校验本质是防止追新用户跳级出错。生产主力的位置不在这条轨上;合理的用法是:测试环境跟一版日历版本,把你要的特性(或修复)提前验证,把发现的问题提前喂给官方。运维日历里给测试环境留一个「日历版本试用季」,是这套双轨制的正确打开方式。

EOL 之后的安全与合规账

8.0 留守的代价要按官方口径算:Oracle 的 Sustaining Support 明确不再提供维护版本、Bug 修复与安全补丁。这意味着 8.0 上发现的任何新漏洞,社区版的修复不会到来——这是与「运行得很好所以不用动」直接矛盾的硬事实。合规视角同样硬:等保、行业审计对「数据库版本已停止安全维护」的问询,答案只有「迁移计划已在执行」才过得去。

第三方的后 EOL 支持是过渡选项:Percona 公开提供 8.0 的 post-EOL 支持服务(其 5.7 时代有 EOL 后继续发关键安全补丁的先例),商业支持的团队可以买时间,但要清楚这是买迁移时间,不是买永久安全——它不改变「8.0 是技术终点」的事实。开源替代(MariaDB、Percona Server)的分叉评估是另一个话题,迁移成本不亚于升 8.4,除非有明确的生态理由,不建议作为默认路线。

升级窗口的执行与回滚要点

无论目标是 8.4 还是(经由 8.4 的)9.7,窗口里的动作骨架一致:

# 1. 升级前体检(官方 best practices 的最小集)
mysqlcheck -u admin -p --all-databases --check --check-upgrade
mysqldump -u admin -p --single-transaction --all-databases --routines --triggers > full-backup.sql

# 2. 确认没有已移除的参数在配置里(8.4 移除清单见官方 nutshell)
grep -nE "default_authentication_plugin|no-dd-upgrade|binlog_transaction_dependency_tracking|--old|--new|ssl\b" /etc/my.cnf /etc/my.cnf.d/*.cnf

# 3. 就地升级(8.0.37+ → 8.4.x,以官方 upgrade 文档为操作依据)
# 4. 升级后:mysqlcheck --all-databases --check-upgrade 再跑一遍 + 应用冒烟

回滚的两条铁律:就地升级的回滚等于恢复备份——MySQL 的就地升级不可逆(数据字典升级),回滚方案就是「备份 + 二进制切换」,所以备份的可恢复性验证是窗口的前置条件,不是计划里的一行字;逻辑复制路线的回滚是反向切流——旧主保留到观察期结束,流量能切回就有一切余地,这是停机窗口敏感的业务该选的路线,代价是双倍的资源与更长的工程量。站内迁移文的回滚章节对两条路线都有展开,执行前逐条对一遍。

决策检查表

• 已确认当前版本与升级路径合法性(SELECT VERSION();;8.0.37+ 才可直跳 8.4)。
• mysql.user 里无 mysql_native_password 账号,或有专项改造计划与缓冲参数的使用截止日。
• my.cnf 无 8.4 已移除参数;应用驱动与连接池对 caching_sha2_password 兼容已验证。
• 8.4 InnoDB 默认值变更影响评估完成,基准测试在预生产重跑并留档。
• 备份可恢复性演练通过(升级窗口前 72 小时内);逻辑复制路线则验证反向切流。
• 目标已定:8.4 收工,或 8.4 后 12–18 个月内再评估 9.7(带明确的 VECTOR/JS 需求判据)。
• 合规问询口径准备好:「8.0 于 2026 年 4 月 EOL,迁移至 X 已完成/已排期」。
• 云托管用户:大版本升级由厂商工具执行,本文路径仅作对照,以云厂商公告为准。

常见升级故障与处置

8.0 → 8.4 窗口里最常撞到的问题,按出现顺序:

这张表的第一条经验:启动失败几乎全部来自「配置文件里的化石参数」。升级前用第一节第 2 步的 grep 扫一遍配置目录,能把窗口里最狼狈的十分钟省掉。

决策速查:三种典型团队的路线

把前文收敛成三条默认路线,对号入座后再按自身情况调整:

社区版自建、无特殊需求:8.0.37+ → 8.4 LTS,收工。VECTOR/JS 出现真实需求时,再评估 8.4 → 9.7 的第二个窗口(支持期到 2034,不急于这一两年)。

AI 应用团队,向量检索有明确规划:8.0 → 8.4(先解决 EOL 合规),把 9.7 的 VECTOR 评估写进下一个半年度计划;在 9.7 落地前,向量需求由外部组件(pgvector、专用向量库)承接,不要为「即将有的能力」改变当前架构。

有第三方商业支持合同的:评估 Percona post-EOL 支持作为 8.0 留守的过渡保险,同时启动 8.4 迁移项目——保险的价值是把迁移做扎实,而不是把迁移取消。

升级窗口的操作脚本,把前文的检查项串成可执行的顺序:

#!/usr/bin/env bash
# mysql-84-precheck.sh:8.0 → 8.4 升级前体检(在源库执行)
set -euo pipefail

echo "== 1. 版本与升级路径"
mysql -N -e "SELECT VERSION();"   # 需 ≥ 8.0.37 才可直跳 8.4

echo "== 2. 认证插件清单(native_password 必须清零或专项处理)"
mysql -e "SELECT user, host, plugin FROM mysql.user WHERE plugin NOT IN ('caching_sha2_password');"

echo "== 3. 配置文件里的已移除参数"
grep -nE "default_authentication_plugin|no-dd-upgrade|binlog_transaction_dependency_tracking" /etc/my.cnf /etc/my.cnf.d/*.cnf 2>/dev/null || echo "  (clean)"

echo "== 4. 表结构与状态一致性检查"
mysqlcheck -u admin -p --all-databases --check --check-upgrade 2>&1 | grep -v "OK$" || echo "  (all OK)"

echo "== 5. 备份(升级窗口前 72 小时内,并做恢复演练)"
mysqldump -u admin -p --single-transaction --all-databases --routines --triggers > "full-backup-$(date +%F).sql"
ls -lh full-backup-*.sql | tail -1

脚本的每一段输出都对应升级变更单的一栏:版本行贴进「路径合法性」、插件清单贴进「迁移动作」、grep 结果决定配置修改项、mysqlcheck 与备份是窗口准入条件。体检脚本进 CI 定时任务后,还能在日常就发现「新账号又在用 native_password」这类回潮。

• 云托管用户:厂商的大版本升级工具与本文社区版路径的差异已过目,升级窗口按厂商文档排期。
• 8.4 InnoDB 新默认值的基准对比已在预生产完成,显式覆盖项与理由写入配置注释。
• 9.7(如选路线 B)的两步升级窗口各自有独立变更单与回滚点。
• Sustaining 期间的 8.0 资产清单已冻结:不再有新业务接入 8.0,存量只出不进。

# 升级完成后的验证清单(在目标版本实例上执行)
mysql -N -e "SELECT VERSION();"                       # 确认目标版本
mysqlcheck -u admin -p --all-databases --check-upgrade # 全库一致性复查
mysql -e "SHOW REPLICA STATUS\G" | grep -E "Replica_(IO|SQL)_Running:|Seconds_Behind:" || true
mysql -e "SELECT user,plugin FROM mysql.user WHERE plugin NOT IN ('caching_sha2_password');" # 应为空

官方资料与继续阅读

外部官方链接:

• Oracle 生命周期支持政策(含 MySQL 版本表,2026-10-02 生效版):https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf
• MySQL 发布模型:LTS 与 Innovation:https://dev.mysql.com/doc/refman/9.7/en/mysql-releases.html
• MySQL 8.4 相对 8.0 的变更(nutshell):https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html
• MySQL 9.7 升级路径:https://dev.mysql.com/doc/refman/9.7/en/upgrade-paths.html
• MySQL 9.0.0 发布说明(VECTOR、JS 存储程序、native_password 移除):https://dev.mysql.com/doc/relnotes/mysql/9.0/en/news-9-0-0.html
• Oracle MySQL 支持阶段定义:https://www.mysql.com/support/
• Percona MySQL 8.0 后 EOL 支持(第三方,商业服务):https://www.percona.com/mysql-8-0-eol-support/

站内相关文章:

• MySQL 8.0 EOL 迁移实战:升级到 8.4 LTS 的兼容检查、停机窗口与回滚——本文「怎么迁」的完整前置篇
• PostgreSQL 14 EOL 迁移指南:升级到 17/18 的停机、验证与回滚——另一条数据库线的平行决策
• 阿里云 RDS MySQL 8 使用指南——托管场景的版本管理差异
• Percona Server for MySQL——分支与商业支持的背景

事实与日期边界:本文版本号、生命周期日期与特性描述截至 2026-10-05,来自 Oracle 官方生命周期政策与 MySQL 官方文档;8.0 EOL 的官方口径为「2026 年 4 月」(政策文件精确到月);日历版本的演进(26.8 及以后)以官方发布说明为准。