MySQL 8.4还是9.7 LTS？8.0 EOL后升级怎么选

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

六月中旬，巡检系统弹了一条预警，测试库的MySQL 8.0.46停更了。我查了下，8.0系列2026年4月正式结束生命周期。群里炸了锅，好几个同事的库还停在8.0，都在讨论升不升、升哪个。没人想当那个拍板的人。我的答案很直接，升，但选哪个版本得好好算账。今天把8.4 LTS和9.7 LTS的差别，加上我的升级决策过程，完整讲一遍。希望帮你少走弯路少踩坑。

一、8.0 EOL，到底意味着什么

先说结论，EOL不是"用不了了"，是"官方不再修了"。MySQL的版本策略是双轨制。LTS版本，长期支持，修bug、补安全漏洞，维护年限长。Innovation版本，创新版，出新功能快，支持期短。8.0属于上一代，2026年4月停更后，安全漏洞不再有官方补丁。合规审计、等保测评，都会卡这个。

我见过有人觉得，停更就停更，我又不联网。数据库有安全漏洞，不等于一定会被攻击，但风险摆在那，真出事就是大事。尤其金融、政务类系统，EOL版本过不了等保。这个坑，踩一次就够呛。

现在的选择其实有三条路。留下来硬扛、升8.4 LTS、直接上9.7 LTS。每条路都有代价，也各有适用场景。我把它们拉了个表，风险、收益、适合谁，一目了然。

路线	维护状态	风险	适合谁
留在8.0	2026年4月EOL	安全漏洞无官方补丁，合规过不了	临时过渡，不能长期
升8.4 LTS	正常维护中	升级动作小，功能保守	求稳，生产压力大
升9.7 LTS	2026年新LTS	新优化器新特性，需回归测试	想吃新能力，能排期

其实还有第四条路，如果升级改造的工作量超出预期，也可以评估迁移到兼容MySQL的国产数据库。不过这条路涉及选型评估和全量迁移，和升级是两套不同的方案，不在本文讨论范围内，感兴趣的朋友可以进我主页看往期文章。

二、8.4 和 9.7，差在哪

8.4 LTS是2024年发布的，8.0的直接延续，参数、行为最接近。如果你的库8.0跑了好几年，一堆自定义配置，升8.4改动最小。它的定位是稳，升级窗口也短，很多人一个周末就能完成。对于排期紧张的生产团队，这是最现实的选择。

9.7 LTS是2026年发布的新长期支持版，带来一批新东西。其中最影响DBA的，是Hypergraph优化器和JSON Duality Views。一个管查询性能，一个管JSON建模，都值得摸一遍。下面拆开讲。

Hypergraph优化器，很多人不熟。传统优化器处理大表JOIN，经常选错执行计划。Hypergraph用图模型搜索JOIN顺序，复杂查询下能找到更好的方案。但它不是默认开启，开了之后执行计划可能变，慢SQL可能变快也可能变慢，必须回归对比。

sql 复制代码

-- 会话级开启Hypergraph优化器
SET SESSION optimizer_switch='hypergraph_optimizer=on';

-- 同一条复杂JOIN，对比开和不开的执行计划
EXPLAIN FORMAT=TREE
SELECT c.cust_id, SUM(o.amount)
FROM customers c
JOIN orders o ON o.cust_id = c.cust_id
JOIN order_items oi ON oi.order_id = o.order_id
WHERE o.order_date >= '2026-01-01'
GROUP BY c.cust_id;

我拿生产库最慢的三条SQL测过，两条变快了，一条反而慢了。慢的那条是嵌套子查询，优化器换了个路径，代价估算偏了。这说明什么？新特性不是开了就好，要一条条验证。别听宣传说得天花乱坠。

JSON Duality Views，简单说，一张JSON视图可以同时映射多张关系表，读写都走视图，不用来回转换。对现在大量用JSON的应用，省事很多。还有动态数据脱敏，查询结果按权限自动打码，对做合规很友好。（注：动态数据脱敏为MySQL企业版功能，社区版不包含。）审计日志也组件化了，可以单独开关，不用整个实例都记。

三、升级前，先做这几件事

特性再好，落地才是关键。我最怕的是有人拿到新版本直接覆盖安装。升级不是装个包，是要先体检。这次升级我走了四步，每一步都踩过坑。

第一步，跑升级预检。MySQL Shell自带的检查工具，能把不兼容项都列出来。命令很简单，结果要一条条过。下面是我跑预检的命令。

bash 复制代码

mysqlsh --uri root@localhost:3306 \
  -- util.checkForServerUpgrade \
  --target-version=9.7.0

我跑完预检，列出来28条告警。大部分是废弃参数，8.0还在用的，9.x直接移除了。比如有几个SQL mode相关的配置，改了默认值，不改的话升级后行为直接变。这些都要在升级窗口前处理掉。

第二步，逐个确认不兼容项。废弃参数能改的改，改不了的要评估影响。我遇到一条"8.0还在用但9.x移除"的，是一个很久以前的存储过程依赖的参数。改完参数，整个存储过程要重新测一遍。

第三步，备份。逻辑备份加物理备份双保险，升级失败能回滚。别嫌麻烦，真出问题的时候，备份就是命。我这次先做了全量，又导了一份逻辑备份。

第四步，灰度。先升测试环境，再升预发，最后才动生产。我在测试环境升完，跑了一周，才敢排生产的窗口。这一步省不了，也别想省。

四、8.4 还是 9.7，我的答案

给结论之前，先说我怎么判断的。如果库是8.0跑得稳、改动越少越好，也没有特别想要的新功能，那就升8.4。改动最小，风险最低，参数行为接近，上线快。这是我们大多数生产库的真实处境。

如果库吃复杂查询的亏、想用JSON Duality Views、或者要赶等保的脱敏要求，值得上9.7。但前提是有时间做回归测试。Hypergraph不是默认开，要自己一条条验证。没有这个时间预算，就别硬上。

我自己最后选了9.7。原因很实际，8.4是2024年发布的，总支持周期到2032年；9.7是2026年发布的，支持周期到2034年。如果想把下次升级的时间拉得更长，9.7更有优势。9.7是新LTS，能撑更久，一次到位。而且我们确实被几条复杂JOIN的慢查询折磨过，想试试新优化器。

但我要强调，这是我们的场景。如果你的生产库没人排期做回归，直接上9.7风险不小，8.4更稳。别为了追新，把生产搞挂。版本不是越新越好，合适才重要。

避坑清单

升级预检一定要跑，别跳过。我见过有人图省事，直接覆盖安装，升级后一堆参数不兼容，业务直接报错。mysqlsh的checkForServerUpgrade会把坑都列出来，一条条处理，比上线后救火划算得多。真出了事，回滚又是一场折腾。

Hypergraph优化器别全局开。它是好东西，但会改变执行计划，不是每条SQL都变快。我的做法是会话级开，对比慢SQL开与不开，确认后再考虑实例级开启。生产环境没跑完整回归之前，别全局开。

9.x删掉的8.0功能，先查官方文档再决定升级。插件、存储过程、SQL mode默认值，都可能变。升级窗口前，把预检清单、回归脚本、回滚方案都准备好，再动生产。我上次升级前专门列了个清单，一条条过，心里才有底。

最后说一句题外话。如果升级过程中发现8.0到9.7的兼容性改造量超出预期，或者团队正在做信创规划，也可以把国产数据库纳入评估，KingbaseES这类对MySQL兼容度高的产品，在某些场景下是另一种选择。升级和迁移是两条路，各有适用场景，没有绝对的好坏。

你会给生产库升8.4还是9.7？或者你们还在8.0上硬扛？欢迎评论区聊聊你的版本计划。我猜不少团队还在观望，这很正常。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋