宝藏大战
102.45M · 2026-04-23
2026年4月21日，MySQL 官方同时发布了三个重要版本：8.0.46（8.0 线的最后一个版本）、8.4.9 LTS（当前 LTS 线的维护更新），以及 9.7.0 LTS（从创新版本正式转为长期支持版本）。这意味着陪伴我们八年的 MySQL 8.0 正式谢幕，而全新的 LTS 时代正在开启。☕
MySQL 8.0 于 2018 年 4 月 19 日正式 GA，至今已经走过了整整八个年头。作为 MySQL 历史上最为成功的一个大版本，8.0 带来了太多值得铭记的变革：窗体函数、CTE（公用表表达式）、InnoDB 集群、JSON 数据类型的全面增强、以及默认认证插件从 mysql_native_password 切换到 caching_sha2_password 等等。
2026 年 4 月 21 日发布的 MySQL 8.0.46，是这个伟大版本的"最后一舞"。从这一天起，MySQL 8.0 正式进入 Oracle 的 Sustaining Support 阶段，说白了就是：Oracle 不再为它提供任何新的安全补丁、bug 修复或功能更新。
笔者梳理了一下 MySQL 8.0 从诞生到谢幕的关键节点：
| 时间节点 | tt版本/事件 | tt意义 | t
|---|---|---|
| 2016 年 9 月 | tt8.0.0 DM | tt首次亮相，开发里程碑 | t
| 2018 年 4 月 | tt8.0.11 GA | tt正式生产可用 | t
| 2023 年 7 月 | tt8.0.34+ | tt仅修复 bug，不再加新功能 | t
| 2023 年 10 月 | ttMySQL 5.7 EOL | tt上一代生命周期结束 | t
| 2024 年 4 月 | tt8.4.0 LTS GA | tt新的 LTS 线诞生 | t
| 2026 年 4 月 | tt8.0.46 EOL | tt8.0 产品线正式谢幕 | t
说实话，八年时间对于一个数据库大版本来说已经相当长了。对比一下，MySQL 5.7 从 2015 年 GA 到 2023 年 EOL，也恰好是八年。从第三方视角来看，Oracle 这个生命周期管理还是相当有规律的，给了用户充足的迁移窗口。
不过我要提醒各位小伙伴：8.0 EOL 可不是说着玩的。2026 年 4 月 30 日之后，任何新发现的 CVE 漏洞都不会再为 8.0 提供官方补丁。如果你的系统还在跑 8.0，且处于合规要求严格的环境（比如金融、电信、政务），那这就是一个必须严肃对待的风险信号了。
从 2026 年 5 月 1 日起，运行 MySQL 8.0 的实例将面临以下现实：
| 风险维度 | tt具体表现 | tt影响程度 | t
|---|---|---|
| 安全漏洞 | tt新发现的 CVE 无官方补丁 | ttuD83DuDD34 极高 | t
| 合规审计 | ttPCI DSS 4.0.1、等保 2.0 等可能不通过 | ttuD83DuDD34 极高 | t
| 第三方依赖 | ttOpenSSL、cURL、zlib 等库 CVE 同样无补丁 | ttuD83DuDFE0 高 | t
| 技术支持 | ttOracle 官方不再提供技术支持 | ttuD83DuDFE1 中 | t
| 功能缺失 | tt无法使用 9.x 的新特性 | ttuD83DuDFE2 低（对稳定运行而言） | t
笔者的建议是：尽快安排升级，不要心存侥幸。数据库这玩意儿不像前端框架，可以随便折腾。该升级时就升级，避免长期安全风险。
好消息是，如果你跑在公有云的托管数据库上，各大云厂商都给了一定的缓冲期：
| 云厂商 | tt标准支持截止日期 | tt扩展支持截止日期 | tt备注 | t
|---|---|---|---|
| Oracle MySQL HeatWave | tt2026 年 4 月 | tt2027 年 4 月 | tt自动升级到 8.0.46 | t
| AWS RDS | tt2026 年 7 月 31 日 | tt2029 年 7 月 31 日 | tt建议尽快升级 | t
| AWS Aurora v3 | tt2028 年 4 月 30 日 | tt2029 年 7 月 31 日 | tt最长的缓冲期 | t
| Google Cloud SQL | tt2027 年 1 月 1 日 | tt2029 年 7 月 1 日 | tt标准支持延长了半年 | t
| Azure Database for MySQL | tt2026 年 12 月 31 日 | tt2029 年 5 月 31 日 | tt微软给到了年底 | t
不过要提醒各位，这些"缓刑期"只是让你有时间做升级规划，不是让你继续长期停留在 8.0 的理由。笔者的建议是，无论云厂商给多长的缓冲期，都应该在 2026 年内完成向 8.4 LTS 的迁移。
如果确实有特殊情况需要继续在 8.0 上运行一段时间，可以考虑第三方支持：
但说实话，第三方支持的成本不低，而且终究是个过渡方案。从长远来看，升级到官方支持的 LTS 版本才是正道。
MySQL 8.4 是 Oracle 新发布模型下的第一个 LTS 版本，于 2024 年 4 月 30 日 GA。按照 Oracle 的承诺，8.4 LTS 将获得 5 年的 Premier Support + 3 年的 Extended Support，也就是说支持到大约 2032 年 4 月。对于追求稳定的企业用户来说，这是一个非常可靠的选择。
2026 年 4 月 21 日发布的 MySQL 8.4.9 是 8.4 LTS 线的第九个维护版本。虽然是个维护版，但内容相当扎实。
OpenSSL 升级到 3.5.5：对于捆绑 OpenSSL 的平台，这次更新把 OpenSSL 库升级到了 3.5.5 版本。OpenSSL 3.5 系列带来了不少安全修复和性能改进，具体可以参考 OpenSSL 官方的 CHANGES.md。在企业环境中，OpenSSL 的版本直接关系到 TLS 连接的安全性和合规性，所以这个更新非常重要。
zlib 升级到 1.3.2：压缩库的小版本升级，包含了一些压缩相关的 bug 修复。对于使用压缩连接或者 COMPRESS() 函数的场景有影响。
MySQL 8.4.9 在 InnoDB 方面修复了几个笔者觉得值得关注的问题：
| Bug 编号 | tt问题描述 | tt影响 | t
|---|---|---|
| Bug #39040128 | tt多值索引（multi-value indexes）相关问题 | tt使用 JSON 多值索引的查询可能返回错误结果 | t
| Bug #39033858 | tt并行读取器（parallel reader）问题 | tt并行查询场景下的稳定性 | t
| Bug #39040226 | tt大型表 FTS 索引构建时的内存优化 | tt减少全文索引构建的内存占用 | t
| Bug #38370155 | ttCREATE INDEX + 高 innodb_parallel_read_threads 导致磁盘空间耗尽 | tt严重时可导致实例故障 | t
| Bug #38169053 | ttTRUNCATE TABLE 相关问题 | ttDDL 操作的正确性 | t
| Bug #85060 | tt计算最大索引记录大小时可能触发 assertion failure | tt特定 schema 下的稳定性 | t
其中 Bug #38370155 需要注意一下：如果你在生产环境使用了较高的 innodb_parallel_read_threads 值（比如超过 16），并且在 8.4.8 或更早版本上遇到过磁盘空间莫名其妙爆满的情况，这个修复就是为你准备的。建议升级后密切观察磁盘空间使用率的变化。
MySQL 8.4.9 修复了一个长期存在的问题：在包含虚拟生成列的表上，使用 LOCK=NONE 删除列之前会失败（Bug #83557 / Bug #24962142）。这个修复使用了 Online DDL 的伙伴来说是个好消息，意味着更多的表结构变更可以在线完成，减少对业务的停机影响。
MySQL 8.4.9 新增了一个比较有意思的小特性：现在可以在命令行或配置文件中通过 performance-schema-meter 参数来启用或禁用 Telemetry meters 了。虽然 Telemetry 在 8.4 中还是企业版功能，但这个配置层面的改进说明 Oracle 在可观测性方面的持续投入。
如果说 MySQL 8.4.9 是"稳扎稳打"的维护更新，那 MySQL 9.7.0 就是这次发布中的"主角光环"。2026 年 4 月 21 日，MySQL 9.7.0 正式从 Innovation Release 转变为 LTS（Long-Term Support）版本，这意味着它将成为未来数年 MySQL 生态的核心支柱。
笔者对 MySQL 9.7.0 的评价是：这是 MySQL 近两年来最重要的一个版本。不是因为某一个炸裂的新特性，而是因为 Oracle 在这个版本上展现出了不同以往的开放态度：大量原本只存在于 Enterprise Edition 的功能，现在被下放到了 Community Edition。这对于广大 MySQL 用户来说，绝对是利好消息。uD83CuDF3B
这是 MySQL 9.7.0 最让人振奋的变化。以下组件此前仅在 MySQL 企业版中可用，现在逐步向社区版开放：
| 组件名称 | tt功能描述 | tt适用场景 | t
|---|---|---|
| Replication Applier Metrics Component | tt复制应用器指标收集 | tt主从复制监控、延迟诊断 | t
| Group Replication Flow Control Statistics Component | tt组复制流控统计 | ttMGR/InnoDB Cluster 性能调优 | t
| Group Replication Resource Manager Component | tt组复制资源管理器 | tt自动检测资源耗尽、保护集群稳定 | t
| Group Replication Primary Election Component | tt组复制主节点选举 | tt基于数据新鲜度的智能选主 | t
| Telemetry Component (OpenTelemetry/OTLP) | tt可观测性数据采集 | tt现代云原生监控体系集成 | t
这些可观测性特性对于正在使用 MIC 或者组复制的小伙伴来说，这简直就是幸福时刻。
在 MySQL 9.7.0 社区版中，这些组件可以通过以下方式安装：
-- 安装复制应用器指标组件INSTALL COMPONENT 'file://component_replication_applier_metrics';-- 验证安装状态mysql> SELECT * FROM mysql.component;+--------------+--------------------+----------------------------------------------+* component_id * component_group_id * component_urn *+--------------+--------------------+----------------------------------------------+* 1 * 1 * file://component_validate_password ** 2 * 2 * file://component_replication_applier_metrics *+--------------+--------------------+----------------------------------------------+2 rows in set (0.000 sec)Hypergraph Optimizer 是 MySQL 近年来在查询优化器方面最重要的创新之一。它采用超图模型来探索更广泛的连接计划空间，包括 Bushy Tree 连接方式，并支持基于代价的 Hash Join 选择和 Interesting Order 优化。
在 MySQL 9.7.0 之前，Hypergraph Optimizer 只在企业版中提供。现在，社区版用户也可以免费使用了。
启用方式非常灵活：
-- 会话级启用SET optimizer_switch='hypergraph_optimizer=on';-- 全局启用（需 SUPER 权限）SET GLOBAL optimizer_switch='hypergraph_optimizer=on';-- 持久化到配置文件SET PERSIST optimizer_switch='hypergraph_optimizer=on';-- 针对单条 SQL 使用 hintSELECT /*+ SET_VAR(optimizer_switch='hypergraph_optimizer=on') */ o.order_id, c.customer_name, p.product_nameFROM orders oJOIN customers c ON o.customer_id = c.customer_idJOIN order_items oi ON o.order_id = oi.order_idJOIN products p ON oi.product_id = p.product_idWHERE o.order_date > '2026-01-01';笔者建议：Hypergraph Optimizer 对于复杂的多表 JOIN 查询（特别是 4 张表以上的 JOIN）效果最为明显。如果你的业务有这类查询，可以在测试环境先开启对比测试，观察执行计划的变化。但要注意，它不是万能的，对于简单的单表查询或两表 JOIN，传统的优化器可能反而更高效。
JSON Duality Views 是 MySQL 9.x 系列引入的一个非常有意思的特性。它允许你在同一个底层数据上，既使用传统的 SQL 关系查询，又使用层级化的 JSON 文档模型，实现了关系型完整性与 JSON 灵活性的统一。
熟悉 Oracle AI Database 26ai 的小伙伴可能一下就想到了 Oracle 数据库的新增特性：JSON 二元视图。
是的，如出一辙，但是 MySQL 中更像是简化版本。
在 MySQL 9.7.0 之前，社区版只支持对 JSON Duality Views 的 DDL 操作（创建、修改视图结构）。而现在，完整的 DML 操作（INSERT、UPDATE、DELETE）也向社区版开放了。此外，还新增了对自增列（auto-increment）在 DML 操作中的支持。
这个特性的实际意义在于：你不再需要为了同时满足关系查询和 JSON 访问而维护两份数据，也不需要写复杂的 ORM 映射代码。一张表，一个视图，两种访问方式。
-- 创建示例表CREATE TABLE customers ( customer_id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100), email VARCHAR(100), address VARCHAR(100));-- 创建 JSON Duality ViewCREATE OR REPLACE JSON RELATIONAL DUALITY VIEW customer_dv ASSELECT JSON_DUALITY_OBJECT( WITH(INSERT, UPDATE, DELETE) -- 权限声明放在对象内部 '_id' : customer_id, -- MySQL 要求必须定义一个 _id 作为主键映射 'name' : name, 'email' : email, 'address' : address)FROM customers;-- 通过视图进行 DML 操作INSERT INTO customer_dv VALUES ( '{ "address": "少安事务所", "email": "aaa@shawnyan.cn", "name": "ShawnYan", "_id": 1 }');-- 查询数据SELECT * FROM customer_dv;SELECT * FROM customers;
需要注意的是，在当前实现中，JSON DUALITY VIEW 还不支持直接投影类型为 JSON 的原始列，否则会报错。
mysql> CREATE TABLE customers ( -> customer_id INT PRIMARY KEY AUTO_INCREMENT, -> name VARCHAR(100), -> email VARCHAR(100), -> address JSON -- 还不支持 -> );Query OK, 0 rows affected (0.009 sec)mysql> CREATE JSON DUALITY VIEW customer_dv AS -> SELECT JSON_DUALITY_OBJECT( -> WITH(INSERT, UPDATE, DELETE) -- 权限声明放在对象内部 -> '_id' : customer_id, -- MySQL 要求必须定义一个 _id 作为主键映射 -> 'name' : name, -> 'email' : email, -> 'address' : address -> ) -> FROM customers;ERROR 6466 (HY000): Invalid JSON duality view definition: Object "Root Node" projecting "shawnyan.customers" includes column "address" of type "JSON". This type of projection is not supported.MySQL 9.7.0 在认证安全方面做了一个重要增强：caching_sha2_password 认证插件现在支持 PBKDF2（Password-Based Key Derivation Function 2）存储格式，并且可以使用 SHA512 哈希算法。
PBKDF2 相比于传统的密码哈希方式，通过增加迭代次数大幅提升了暴力破解的难度。而使用 SHA512 替代 SHA256，进一步增强了安全性。最重要的是，这个变化对客户端完全透明，不需要修改任何客户端代码或驱动版本，服务器端升级后自动生效。
安全性和兼容性往往是一对矛盾，但 Oracle 这次做到了"既安全又省心"。对于处理敏感数据的企业（金融、医疗、政务），建议关注一下。
PGO 是一种编译器优化技术，它通过收集程序运行时的实际执行剖面数据，来指导编译器生成更优化的二进制代码。简单说就是：用真实的工作负载来告诉编译器"哪里该优化"，从而生成跑得更快的程序。
MySQL 9.7.0 现在支持使用 PGO 构建 MySQL。对于 RPM 包构建，在 SLE/openSUSE 和 Fedora 平台上，可以通过以下方式启用：
# 使用 rpmbuild 构建启用 PGO 的 MySQL RPM 包rpmbuild --rebuild --define="with_pgo 1" mysql-9.7.0-*.src.rpmMySQL 9.7.0 新增了对 cpuset cgroup 的支持。在容器化和云原生部署越来越普及的今天，这个改进非常实用。
具体来说，MySQL Server 现在能够正确识别并遵守 cpuset-cpus cgroup 控制器设置的 CPU 限制，准确计算分配给 MySQL 的逻辑 CPU 数量。这对于以下场景尤其重要：
--cpuset-cpus 限制的容器AllowedCPUs 设置了 CPU 亲和性的服务# 在 Podman 中运行 MySQL 9.7.0，限制使用 CPU 0-3Podman run -d \ --name mysql-shawnyan.cn \ --cpuset-cpus="0-3" \ --memory="8g" \ mysql:9.7.0Clone 插件升级：9.7.0 的 Clone 插件现在支持连续 LTS 版本之间的克隆（比如从 9.7.0 克隆到未来的 10.x LTS）。这对于大版本升级场景非常实用，可以显著减少停机时间。
新增 replica_allow_higher_version_source 变量：这个变量控制是否允许从高版本源复制到低版本副本。在某些滚动升级场景下可能有用，但默认值是 OFF，需要谨慎使用。
Audit Log 增强：新增了基于时间自动轮转（audit_log.rotate_on_time）和无效过滤器自动恢复（audit_log.filter_recovery_mode）功能。对于需要严格审计合规的企业，这些功能可以减少运维负担。
| 对比维度 | ttMySQL 8.0.46 | ttMySQL 8.4.9 LTS | ttMySQL 9.7.0 LTS | t
|---|---|---|---|
| 发布日期 | tt2026-04-21 | tt2026-04-21 | tt2026-04-21 | t
| 版本定位 | ttEOL（生命周期结束） | tt当前 LTS 维护版 | tt新一代 LTS | t
| 支持截止 | tt已结束（2026-04-30） | tt约 2032-04 | tt约 2034-04 | t
| Hypergraph Optimizer | tt❌ 无 | tt❌ 无（企业版 有） | tt✅ 社区版 可用 | t
| JSON Duality Views DML | tt❌ 无 | tt❌ 无 | tt✅ 社区版 可用 | t
| PBKDF2 认证 | tt❌ 不支持 | tt❌ 不支持 | tt✅ 支持 | t
| cgroups cpuset | tt❌ 不支持 | tt❌ 不支持 | tt✅ 支持 | t
| caching_sha2_password 默认 | tt✅ 是 | tt✅ 是（更严格） | tt✅ 是（+PBKDF2） | t
| mysql_native_password | tt默认启用 | tt默认禁用 | tt已移除 | t
| 升级路径 | tt- | tt可直接升级 | tt需先从 8.0→8.4 | t
根据少安多年的生产环境实战经验，给出以下选型建议：
选择 MySQL 8.4.9 LTS 的场景：
选择 MySQL 9.7.0 LTS 的场景：
升级路径：
MySQL 8.0.x → MySQL 8.4.x LTS → MySQL 9.7.0 LTS ↑ ↑ ↑ 当前版本 2026 年目标 最终目标-- 查找还在使用旧认证插件的用户SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';-- 迁移到 caching_sha2_passwordALTER USER 'old_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'NewStrongPassword123!';-- 如果暂时无法迁移，可在 8.4 中临时启用（不建议长期使用）# 在 my.cnf 中添加：# [mysqld]# mysql_native_password = ON以下变量在 8.4/9.7 中已被移除或改名，需要提前清理 my.cnf：
# 检查配置文件中是否有已废弃的变量grep -E "expire_logs_days*query_cache*innodb_log_files_in_group*innodb_log_file_size" /etc/my.cnf# 替换方案：# expire_logs_days → binlog_expire_logs_seconds# query_cache_* → 已完全移除（8.0 开始）# innodb_log_files_in_group / innodb_log_file_size → innodb_redo_log_capacityMySQL 8.4 开始要求外键引用的父表列必须有唯一索引，关联参数 restrict_fk_on_non_standard_key：
-- 检查是否存在非唯一索引的外键引用SELECT rc.TABLE_NAME, rc.CONSTRAINT_NAME, UNIQUE_CONSTRAINT_NAME, REFERENCED_TABLE_NAMEFROM information_schema.REFERENTIAL_CONSTRAINTS rcJOIN information_schema.TABLE_CONSTRAINTS tc ON rc.UNIQUE_CONSTRAINT_NAME = tc.CONSTRAINT_NAMEWHERE tc.CONSTRAINT_TYPE != 'UNIQUE';MySQL 8.0 的谢幕标志着一个时代的结束，但也意味着新的开始。从笔者观察到的趋势来看，Oracle 在 MySQL 9.7 LTS 上展现出了不同以往的开放姿态：大量 Enterprise 特性下放、Community 和 Enterprise 的差距在缩小、对云原生场景的适配越来越完善。
当然，社区也有一些担忧的声音。2025 年秋天 Oracle 对 MySQL 团队的调整，让不少人对 MySQL 的长期发展心存疑虑。2026 年 2 月，MySQL 社区经理 Lefred 出走 MariaDB 基金会 。MySQL 社区版对向量功能支持远不及竞品。
对于企业和开发者来说，笔者的建议是：不要被情绪左右，用脚投票。MySQL 仍然是世界上最成熟、生态最丰富的开源关系型数据库。9.7 LTS 的发布，让我们有充分的理由继续信任它。
最后，还在使用 MySQL 8.0 及之前版本的小伙伴们，真的该动起来为升级做准备了。
Have a nice day ~ ☕
uD83CuDF3B 往期内容 ▼
uD83CuDF3B 其他内容 ▼
uD83DuDC49 这里有得聊
如果对国产基础软件（操作系统、数据库、中间件）、AI、Vibe Coding、OpenClaw 、Hermes Agent 等感兴趣，可以加群一起聊聊。关注微信公众号：(少安事务所)，后台回复[群]，即可看到入口。如果这篇文章为你带来了灵感或启发，请帮忙『点赞、推荐、转发』吧，感谢！ღ( ´･ᴗ･` )~
,
