MySQL 8.0结束，8.4.9 LTS、9.7.0上线：一个时代的交接与新生

2026年4月21日，MySQL 官方同时发布了三个重要版本：8.0.46（8.0 线的最后一个版本）、8.4.9 LTS（当前 LTS 线的维护更新），以及 9.7.0 LTS（从创新版本正式转为长期支持版本）。这意味着陪伴我们八年的 MySQL 8.0 正式谢幕，而全新的 LTS 时代正在开启。☕

01. 八年陪伴，正式谢幕：MySQL 8.0 的生命周期回顾

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 从诞生到谢幕的关键节点：

说实话，八年时间对于一个数据库大版本来说已经相当长了。对比一下，MySQL 5.7 从 2015 年 GA 到 2023 年 EOL，也恰好是八年。从第三方视角来看，Oracle 这个生命周期管理还是相当有规律的，给了用户充足的迁移窗口。

不过我要提醒各位小伙伴：8.0 EOL 可不是说着玩的。2026 年 4 月 30 日之后，任何新发现的 CVE 漏洞都不会再为 8.0 提供官方补丁。如果你的系统还在跑 8.0，且处于合规要求严格的环境（比如金融、电信、政务），那这就是一个必须严肃对待的风险信号了。

本文作者：公众号「少安事务所」，由 严少安 主笔，专注于数据 & AI 领域技术传播。个人主页：https://shawnyan.cn/

02. 8.0 EOL 之后的现实影响与应对策略

不再有安全补丁，风险正在累积

从 2026 年 5 月 1 日起，运行 MySQL 8.0 的实例将面临以下现实：

笔者的建议是：尽快安排升级，不要心存侥幸。数据库这玩意儿不像前端框架，可以随便折腾。该升级时就升级，避免长期安全风险。

云厂商给的"缓刑期"

好消息是，如果你跑在公有云的托管数据库上，各大云厂商都给了一定的缓冲期：

不过要提醒各位，这些"缓刑期"只是让你有时间做升级规划，不是让你继续长期停留在 8.0 的理由。笔者的建议是，无论云厂商给多长的缓冲期，都应该在 2026 年内完成向 8.4 LTS 的迁移。

第三方支持方案

如果确实有特殊情况需要继续在 8.0 上运行一段时间，可以考虑第三方支持：

• • Percona：提供最长三年的 EOL 后安全更新和 24x7 支持，最终目标是引导迁移到 Percona Server for MySQL
• • TuxCare：提供 Endless Lifecycle Support (ELS)，覆盖 MySQL 核心组件和所有捆绑的第三方库

但说实话，第三方支持的成本不低，而且终究是个过渡方案。从长远来看，升级到官方支持的 LTS 版本才是正道。

03. 稳扎稳打的守护者：MySQL 8.4.9 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() 函数的场景有影响。

InnoDB 存储引擎修复

MySQL 8.4.9 在 InnoDB 方面修复了几个笔者觉得值得关注的问题：

其中 Bug #38370155 需要注意一下：如果你在生产环境使用了较高的 innodb_parallel_read_threads 值（比如超过 16），并且在 8.4.8 或更早版本上遇到过磁盘空间莫名其妙爆满的情况，这个修复就是为你准备的。建议升级后密切观察磁盘空间使用率的变化。

Atomic DDL 改进

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 在可观测性方面的持续投入。

04. 重磅登场：MySQL 9.7.0 LTS 全面解读

如果说 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 用户来说，绝对是利好消息。🌻

企业版特性逐步下放社区版

这是 MySQL 9.7.0 最让人振奋的变化。以下组件此前仅在 MySQL 企业版中可用，现在逐步向社区版开放：

这些可观测性特性对于正在使用 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 使用 hint
SELECT /*+ SET_VAR(optimizer_switch='hypergraph_optimizer=on') */
    o.order_id, c.customer_name, p.product_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date > '2026-01-01';

笔者建议：Hypergraph Optimizer 对于复杂的多表 JOIN 查询（特别是 4 张表以上的 JOIN）效果最为明显。如果你的业务有这类查询，可以在测试环境先开启对比测试，观察执行计划的变化。但要注意，它不是万能的，对于简单的单表查询或两表 JOIN，传统的优化器可能反而更高效。

JSON Duality Views：关系型与文档型的完美融合

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 View
CREATE OR REPLACE JSON RELATIONAL 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;

-- 通过视图进行 DML 操作
INSERT INTO customer_dv VALUES ( '{ 
       "address": "少安事务所",
       "email": "[email protected]",
       "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.

认证安全增强：PBKDF2 + SHA512

MySQL 9.7.0 在认证安全方面做了一个重要增强：caching_sha2_password 认证插件现在支持 PBKDF2（Password-Based Key Derivation Function 2）存储格式，并且可以使用 SHA512 哈希算法。

PBKDF2 相比于传统的密码哈希方式，通过增加迭代次数大幅提升了暴力破解的难度。而使用 SHA512 替代 SHA256，进一步增强了安全性。最重要的是，这个变化对客户端完全透明，不需要修改任何客户端代码或驱动版本，服务器端升级后自动生效。

安全性和兼容性往往是一对矛盾，但 Oracle 这次做到了"既安全又省心"。对于处理敏感数据的企业（金融、医疗、政务），建议关注一下。

Profile-Guided Optimization (PGO) 构建支持

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.rpm

cgroups 支持增强

MySQL 9.7.0 新增了对 cpuset cgroup 的支持。在容器化和云原生部署越来越普及的今天，这个改进非常实用。

具体来说，MySQL Server 现在能够正确识别并遵守 cpuset-cpus cgroup 控制器设置的 CPU 限制，准确计算分配给 MySQL 的逻辑 CPU 数量。这对于以下场景尤其重要：

• • Kubernetes 部署：设置了 CPU limit 和 request 的 Pod
• • Docker/Podman 容器：使用 --cpuset-cpus 限制的容器
• • systemd 服务：通过 AllowedCPUs 设置了 CPU 亲和性的服务

# 在 Podman 中运行 MySQL 9.7.0，限制使用 CPU 0-3
Podman run -d \
  --name mysql-shawnyan.cn \
  --cpuset-cpus="0-3" \
  --memory="8g" \
  mysql:9.7.0

其他值得关注的改进

Clone 插件升级：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）功能。对于需要严格审计合规的企业，这些功能可以减少运维负担。

05. 三个版本横向对比：该怎么选？

选型建议

根据少安多年的生产环境实战经验，给出以下选型建议：

选择 MySQL 8.4.9 LTS 的场景：

• • 你的业务对稳定性要求极高，不追求新特性
• • 应用代码较老，担心 9.x 的兼容性问题
• • 计划短期内（1-2 年内）完成升级，给团队更多测试时间
• • 当前在 8.0 上跑得好好的，只是想先脱离 EOL 风险

选择 MySQL 9.7.0 LTS 的场景：

• • 你希望获得最新的性能优化和安全特性
• • 正在使用或计划使用 MySQL InnoDB Cluster / Group Replication
• • 有复杂的 JOIN 查询，想尝试 Hypergraph Optimizer
• • 有 JSON 数据处理需求，想使用 Duality Views
• • 云原生部署，需要完善的 cgroup 支持
• • 有充足的测试资源来做升级验证

升级路径：

MySQL 8.0.x → MySQL 8.4.x LTS → MySQL 9.7.0 LTS
     ↑              ↑                  ↑
   当前版本      2026 年目标         最终目标

常见需要提前处理的问题

1. 1. mysql_native_password 用户

-- 查找还在使用旧认证插件的用户
SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'mysql_native_password';

-- 迁移到 caching_sha2_password
ALTER USER 'old_user'@'%'
IDENTIFIED WITH caching_sha2_password
BY 'NewStrongPassword123!';

-- 如果暂时无法迁移，可在 8.4 中临时启用（不建议长期使用）
# 在 my.cnf 中添加：
# [mysqld]
# mysql_native_password = ON

1. 2. 已移除的系统变量

以下变量在 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_capacity

1. 3. 外键约束检查

MySQL 8.4 开始要求外键引用的父表列必须有唯一索引，关联参数 restrict_fk_on_non_standard_key：

-- 检查是否存在非唯一索引的外键引用
SELECT
    rc.TABLE_NAME, rc.CONSTRAINT_NAME, 
    UNIQUE_CONSTRAINT_NAME, REFERENCED_TABLE_NAME
FROM information_schema.REFERENTIAL_CONSTRAINTS rc
JOIN information_schema.TABLE_CONSTRAINTS tc
    ON rc.UNIQUE_CONSTRAINT_NAME = tc.CONSTRAINT_NAME
WHERE tc.CONSTRAINT_TYPE != 'UNIQUE';

07. 写在最后：MySQL 的未来与我们的选择

MySQL 8.0 的谢幕标志着一个时代的结束，但也意味着新的开始。从笔者观察到的趋势来看，Oracle 在 MySQL 9.7 LTS 上展现出了不同以往的开放姿态：大量企业版特性下放、社区版(CE)和企业版(EE)的差距在缩小、对云原生场景的适配越来越完善。

当然，社区也有一些担忧的声音。2025 年秋天 Oracle 对 MySQL 团队的调整，让不少人对 MySQL 的长期发展心存疑虑。2026 年 2 月，MySQL 社区经理 Lefred 出走 MariaDB 基金会 。MySQL 社区版对向量功能支持远不及竞品。

对于企业和开发者来说，笔者的建议是：不要被情绪左右，用脚投票。MySQL 仍然是世界上最成熟、生态最丰富的开源关系型数据库。9.7 LTS 的发布，让我们有充分的理由继续信任它。

最后，还在使用 MySQL 8.0 及之前版本的小伙伴们，真的该动起来为升级做准备了。