说个很多团队还没当回事的事：MySQL 官方 Release Notes 已确认，MySQL 8.0 随最后一个版本 8.0.46，在2026年4月30日正式到达生命周期终点——不再有功能更新，更重要的是，不再有安全补丁。知乎
其实信号早就出现过。今年1月就有媒体报道，MySQL Server 的 GitHub 官方仓库一度超过3个月没有任何代码提交；再往前，2025年9月 Oracle 那轮全球裁员里，MySQL 核心开发团队约70名资深工程师和核心开发者被裁，社区当时就在担心这个项目的维护节奏。知乎如今 8.0 停更落地，轮到生产环境面对现实了。
但现实是，按 Percona PMM 监控的实例口径，目前仍有约 58% 的实例跑在 MySQL 8.0 上，还有 18.8% 停留在更早就退役的 5.7。知乎也就是说，大半个生产圈都还停在"官方已经不管"的版本上。最近知乎和数据库社区里，"升不升、升哪个"的帖子密集冒出来，没人想当那个拍板的人。今天我把官方说明和近几个月全网实测文章翻了一遍，把这个决策拆成3个问题，帮你在拍板前把账算清楚。
先说清楚：EOL 到底意味着什么
EOL 不是"数据库用不了了"，而是"官方不再修了"。以后曝出新漏洞，8.0 不会再有补丁，只能自己扛或者花钱买延长支持。对金融、政务类系统，等保测评和合规审计会直接卡 EOL 版本。
社区里有句话说得挺实在：数据库有安全漏洞，不等于一定会被攻击，但风险摆在那，真出事就是大事。所以"停更了还能跑"不是不升级的理由，只是说你现在还有选择权——越往后，选择越少，代价越大。
摆在面前的三条路
第一条：原地不动，硬扛。 成本为零，但等于把安全响应外包给运气。适合临时过渡，不适合当策略。
第二条：升 8.4 LTS。 8.4 是 MySQL 历史上第一个长期支持（LTS）版本，2024 年发布，官方支持周期到 2032 年。它是 8.0 的直接延续，参数和行为最接近，改动最小，有实测作者一个周末就完成了升级窗口。小红书一家第三方数据库服务商做过实测评估：从 8.0 升到 8.4 的变动和影响，远小于当年 5.7 升 8.0，“更像同一条主干道上的版本迭代”。知乎而且 8.4 不只是"稳"：InnoDB 并行查询是实打实的性能提升，有笔记作者实测 1 亿行订单表 COUNT(*) 从 1.82 秒降到 0.22 秒，提速 8.3 倍，还不用改业务 SQL。小红书对排期紧张、库上堆满自定义配置的生产团队，这是最现实的选择。
第三条：直接上 9.7 LTS。 这是 2026 年发布的新长期支持版，支持周期到 2034 年，"一次到位"撑得更久。知乎4月底已有社区作者发出完整的安装实测。新东西不少：Hypergraph 优化器、JSON Duality Views、复制可观测性，还有动态数据脱敏（注意，脱敏是企业版功能，社区版不含）。
但 Hypergraph 默认不开，开了会改变执行计划——有实测作者拿生产库最慢的三条 SQL 测试，两条变快，一条反而变慢，慢的那条是嵌套子查询，优化器换了路径、代价估算偏了。小红书新特性不是开了就好，得一条条回归验证。
路径 | 支持周期 | 改动量 | 主要风险 | 适合谁 |
|---|---|---|---|---|
原地不动 | 无官方支持 | 无 | 安全漏洞无补丁、合规卡点 | 只适合短期过渡 |
升 8.4 LTS | 到2032年 | 小，行为最接近8.0 | 少量废弃参数 | 排期紧、求稳的大多数团队 |
上 9.7 LTS | 到2034年 | 较大，新优化器需回归 | 执行计划变化、9.x移除部分8.0功能 | 有回归时间预算、想吃新特性的团队 |
问题一：你用的是云 RDS，还是自建？
这决定了升级这事主要由谁来干。
用云数据库的，云厂商一般会自己维护补丁，你主要跟厂商的节奏走。比如阿里云已经在5月正式发布了 RDS MySQL 8.4，从 8.0 到 8.4 的平滑升级能力还在开发中，现阶段可以用 DTS 迁移。知乎但这里有个今年8月的真实案例值得所有上云团队看一眼：有用户发现阿里云 RDS MySQL 8.0（AliSQL 私有分支）的 explicit_defaults_for_timestamp 参数默认值和官方 MySQL 8.0 不一致，导致建表时 timestamp 字段行为不同，产生了脏数据。知乎评论区有知情人解释，AliSQL 为了兼容大量沿用 5.7 习惯的客户，保留了不少私有扩展参数。这件事的教训不是"别用云"，而是：在本地用官方版本测好的东西，上云后要重新核对参数默认值，尤其是从自建迁云、或者跨版本切换的时候——切换前后各跑一遍 SHOW VARIABLES 对比关键参数，别靠感觉。
自建的，没人替你扛，继续往下看。
问题二：你的版本欠账有多大？
这决定了你要走几步。
还在 8.0 的：运气不错，8.4 和 9.7 两条路都开着。官方支持三类升级方式：原地升级、逻辑导出导入、复制迁移。注意"路径受支持"不等于"你的业务可以直接执行"——选哪条取决于停机窗口、数据量、是否顺带换系统换硬件，后面细说。
还在 5.7 的（按 Percona 口径还有近两成）：先别纠结 8.4 还是 9.7，5.7 到 8.0 这一跳才是最难的坎。默认字符集从 latin1 换成 utf8mb4、默认认证插件从 mysql_native_password 换成 caching_sha2_password、SQL mode 默认值也有变化，每一步都可能踩坑。知乎先把 5.7 升到 8.0，再谈 LTS 选择题。
还在 5.6 或更老的：这已经不是升级项目，是迁移项目，建议直接立项评估，别想一步到位。
问题三：你有多少回归测试的时间预算？
这是 8.4 和 9.7 之间真正的分水岭。
没有预算：直接选 8.4。改动最小、风险最低，生产库没人排期做回归的话，硬上 9.7 风险不小。版本不是越新越好，合适才重要。顺带说一句，社区也有声音提醒别神话新版本：有统计称在写密集型负载下，9.5 的吞吐量比 8.0 低，知乎"如何看待MySQL版本越高，性能越差"问题下也在吵这件事。知乎新版本的优化器红利要吃，回归测试的学费也得交。
有预算：9.7 值得考虑，支持周期更长，还能解决一些复杂 JOIN 慢查询的老毛病。但前提是把回归做扎实，Hypergraph 建议会话级开启、逐条对比慢 SQL，确认后再考虑实例级打开。
顺带说第四条路：如果你们单位已经有信创改造要求，那升级和迁移应该放在同一张桌上评估——升级和国产数据库迁移是两套方案，没有绝对好坏，但别等升完级，再从头评估一遍替代方案，两份工作量叠加最亏。
不管升哪个，先做这4件事
这是近几个月多位实测作者踩坑后的高度共识，顺序别乱：
第一步，跑升级预检。 MySQL Shell 自带的 checkForServerUpgrade 会把不兼容项列出来。有作者跑出 28 条告警：大部分是废弃参数、SQL mode 默认值变化，还有一条"8.0 还在用但 9.x 已移除"的参数，被一个老存储过程依赖着，改完整套存储过程要重新测。知乎告警要一条条过，别只看数量。
第二步，逐项确认不兼容项。 每个问题要有负责人、修复动作和复测结果，不能停留在"检查器报没报红"。
第三步，双备份加恢复演练。 逻辑备份加物理备份双保险，而且必须在隔离副本上真刀真枪演练一次恢复。有备份专题作者提醒：不管用哪种方案，都要定期测试恢复流程，很多人备份了一堆文件，真到要恢复时才发现备份文件损坏。知乎只有"备份成功"、没有验证过"恢复成功"的，不能算可回退。
第四步，灰度。 测试环境升完跑一周，再动预发，最后才是生产。这一步省不了，也别想省。
再补两个社区反复强调的提醒：Upgrade Checker 全绿不等于可以直接升级，它覆盖不了恢复演练、应用联调和关键查询基线。知乎
原地升级也不一定比并行迁移快，如果同时要换操作系统、硬件或拓扑，并行迁移的总成本可能更低——比较的是完整的执行、验证和失败恢复成本，不是命令运行时间。知乎
全网踩坑清单，建议收藏
9.x 移除了部分 8.0 还在用的功能和参数，升级前先翻官方文档，重点排查老存储过程依赖的参数；
Hypergraph 优化器别全局开，先会话级对比慢 SQL，没跑完回归别动实例级开关；
外键被引用列必须有完全匹配的唯一索引、非整数类型的 AUTO_INCREMENT 列（比如 FLOAT/DOUBLE 上的）8.4 起不再支持，预检会被点名，提前整改；
云厂商私有分支的参数默认值可能与官方不一致，像前面那个 timestamp 建表字段的案例，问题就出在 explicit_defaults_for_timestamp 这类默认行为差异上，跨环境切换必须逐项核对；
动态数据脱敏是企业版功能，社区版没有，别指望升完级就有。知乎
最后说两句
EOL 不会在你看到这篇文章的当天爆炸，但没有补丁的日子，每多一天，安全事件时的响应空间就小一分。如果今年实在排不出升级窗口，至少做三件事：把 MySQL 相关 CVE 纳入监控、冻结老实例的变更、备好一份验证过能恢复的备份。
接下来值得持续盯的信号：各云厂商 8.0 到 8.4 平滑升级能力的上线节奏、MySQL 官方 8.4.x 小版本的发布内容、以及社区对 9.7 Hypergraph 的回归案例——这些会直接改变"什么时候升、升哪个"的答案。
你们的生产库现在停在哪个版本？是已经升完了，还是还在观望？评论区聊聊你的版本计划。
