MySQL 新技术系列第八期（最终期）

📢 MySQL 新技术系列第八期（最终期）

各位数据库同行、开发者朋友们，大家好！

欢迎回到「MySQL 新技术」系列。今天，我们迎来了这个系列的最后一期。

从第一期「告别 MySQL 8.0 时代，全景解读 9.x 创新版」开始，我们一路走过了向量检索、JavaScript 存储程序、Group Replication 高可用、安全加固、云原生实践、备份与恢复等七个专题。每一期都试图从一个特定维度，剖析 MySQL 9.x 系列的技术演进与生产实践。

作为收官之作，本期不再聚焦单一主题，而是将前七期尚未覆盖的重要技术方向进行汇总梳理——包括 JSON 能力的跨越式增强、InnoDB 存储引擎的深度优化、分区表的重大改进、字符集与排序规则的现代化、以及查询性能调优的实战指南。最后，我们将对整个系列进行系统总结，回顾 MySQL 9.x 时代的技术全景，并展望未来的演进方向。

让我们开始吧。

一、JSON 能力的跨越式增强

在第二期我们重点讨论了向量检索，但 JSON 作为现代应用开发的核心数据类型，在 9.x 系列中也经历了深刻的变革。

1.1 JSON 优化器重写（9.0）

MySQL 9.0 对 JSON 优化器进行了完全重写，改变了 JSON_EXTRACT() 等函数的执行路径。这一变更带来了性能的双面性：部分查询获得显著加速，但也有查询出现了性能回退。

典型案例：某开发者在 8.0 中运行良好的 JSON_EXTRACT 查询，升级到 9.0 后执行时间从 0.3 秒变成了 2.1 秒。分析发现，优化器的新成本模型在某些 JSON 路径表达式上选择了次优的执行计划。

应对策略：

• 升级前对涉及 JSON 函数的核心查询进行充分的性能回归测试
• 使用 EXPLAIN FORMAT=JSON 分析执行计划变化
• 必要时通过 OPTIMIZER_SWITCH 或 JSON_OPTIMIZER_SWITCH 调整优化器行为

1.2 多值索引对 JSON 数组的支持（9.0）

长期以来，在 JSON 数组中检索特定值需要全表扫描或依赖全文索引。MySQL 9.0 引入了对 JSON 数组的多值索引支持，彻底解决了这一痛点。

-- 创建多值索引
CREATE TABLE articles (
    id INT PRIMARY KEY,
    metadata JSON,
    INDEX idx_tags ((CAST(metadata->'$.tags' AS CHAR(50) ARRAY)))
);

-- 高效检索包含特定标签的文章
SELECT * FROM articles WHERE 'mysql' MEMBER OF (metadata->'$.tags');

性能对比：在 10 万行数据中，8.0 的 MEMBER OF 查询耗时约 450ms（全表扫描），9.0 使用多值索引后降至约 12ms，提升近 40 倍。

多值索引的限制：

• 仅支持 InnoDB 引擎
• 只能在一个 JSON 数组列上创建
• 数组元素类型必须一致（可通过 CAST 统一）

1.3 JSON Duality Views（9.7 LTS 社区版开放）

JSON Duality Views 是 MySQL 将关系型数据以 JSON 文档形式呈现的视图机制，允许应用程序通过 JSON 文档接口访问关系数据，同时底层仍保持关系模型的 ACID 事务和约束完整性。

在 9.7 LTS 之前，该功能仅限企业版。9.7 LTS 将其开放至社区版，使开发者能够：

• 将关系表映射为 JSON 文档集合
• 通过标准的 HTTP REST 接口或 CRUD 操作读写 JSON 文档
• 底层自动转换为 SQL 操作，无需修改现有关系模式

这一特性对希望采用「文档数据库」体验但又不想放弃关系数据库 ACID 保证的应用场景尤为实用。

1.4 JSON 聚合函数增强（9.x 持续演进）

9.x 系列还增强了多个 JSON 聚合函数：

• JSON_ARRAYAGG()：支持更灵活的空值处理和排序
• JSON_OBJECTAGG()：支持动态键名生成
• JSON_MERGE_PATCH()：符合 RFC 7396 标准的 JSON Merge Patch 语义

二、InnoDB 存储引擎的深度优化

InnoDB 作为 MySQL 的默认存储引擎，在 9.x 系列中获得了多项底层优化。

2.1 原子 DDL 的完善（9.1）

9.1 版本将原子 DDL 的支持范围扩展至 CREATE DATABASE 和 DROP DATABASE 操作。此前，这些操作在崩溃时可能导致部分完成的状态；9.1 之后，整个操作要么完全成功，要么完全回滚，确保了数据字典的完整性。

2.2 跳过未使用页面（Skip Unused Pages）

在企业版备份工具中，该特性允许备份时只拷贝实际包含数据的页面，跳过未初始化的空间，大幅减少备份时间和存储空间。对于分配了巨大表空间但实际使用率较低的场景尤其有效。

2.3 InnoDB 临时表空间优化

9.x 系列优化了临时表空间的分配策略，减少了在高并发临时表创建/销毁场景下的内部锁竞争。同时，innodb_temp_tablespace_dir 允许将临时表空间放置于更快的存储设备（如 NVMe），提升复杂查询的排序和哈希聚合性能。

2.4 自适应哈希索引（AHI）的改进

自适应哈希索引在 9.x 中获得了更智能的启用/禁用策略，减少了在高写入负载下的维护开销。相关监控指标 Innodb<em>ahi</em>* 系列状态变量也得到了增强。

2.5 并行读取线程（Parallel Read Threads）

InnoDB 在 9.0 中引入了对 SELECT COUNT(*) 等聚合查询的并行扫描支持，通过 innodb_parallel_read_threads 变量控制并行度。在大型表上，该特性可将全表扫描类查询的性能提升数倍。

三、分区表的重大改进

分区表是管理超大规模表的重要工具，9.x 系列在多方面加强了分区能力。

3.1 分区裁剪优化（9.2）

9.2 优化了分区裁剪算法，使其能够处理更复杂的 WHERE 条件，包括涉及 BETWEEN、IN 列表以及部分函数表达式的情况。裁剪效率的提升直接减少了查询需要扫描的分区数量。

3.2 分区管理操作的原子性

ALTER TABLE ... REORGANIZE PARTITION、ALTER TABLE ... TRUNCATE PARTITION 等操作现在具备原子性，中途崩溃不会留下部分完成的分区状态。

3.3 分区交换（Exchange Partition）的增强

分区交换（ALTER TABLE ... EXCHANGE PARTITION）现在支持更严格的数据一致性检查，并允许在交换前自动执行验证，避免将不符合分区约束的数据引入分区表。

3.4 分区表的 DDL 性能

9.6 版本优化了在分区表上执行 ADD COLUMN、DROP COLUMN 等 DDL 操作的性能，减少了元数据锁的持有时间，提升了并发 DDL 的可用性。

四、字符集与排序规则的现代化

字符集是国际化应用的基石，9.x 系列在这方面持续推进现代化。

4.1 utf8mb4 的进一步推广

自 8.0 将默认字符集改为 utf8mb4 以来，9.x 继续推动移除非 UTF-8 字符集的使用。utf8mb4_0900_ai_ci 作为默认排序规则，在 9.x 中获得了更多的性能优化，特别是在 LIKE 和范围查询场景中。

4.2 新的排序规则

9.x 引入了多个新的排序规则，包括针对日语、越南语等语言的特定排序规则，以及区分大小写、重音的变体。utf8mb4_ja_0900_as_cs 为日语文本提供了更符合本地习惯的排序。

4.3 字符集转换的性能提升

CONVERT() 和 CAST() 在不同字符集间转换字符串的性能在 9.x 中得到了提升，特别是在二进制与 UTF-8 之间的大批量转换场景。

五、查询性能调优实战指南

这一部分整合前七期分散提及的性能特性，并补充未展开的调优要点。

5.1 Hypergraph Optimizer（9.7 LTS 社区版开放）

传统的 MySQL 查询优化器基于「左深树」的连接顺序枚举，在处理超过 10 张表的复杂连接时容易陷入组合爆炸，或无法找到最优执行计划。Hypergraph Optimizer 使用图论模型，将查询表示为超图，能够更高效地枚举连接顺序，尤其擅长星型模型和雪花模型。

启用方式：

SET optimizer_switch='hypergraph_optimizer=on';

适用场景：

• 多表 JOIN（通常 5 张表以上）
• 星型/雪花型数据仓库查询
• 包含大量子查询或派生表的复杂查询

注意事项：

• 目前仍为实验性功能，建议在测试环境中充分验证
• 某些查询可能在 Hypergraph 下性能下降，可通过 OPTIMIZER_SWITCH 按查询级别控制

5.2 性能 Schema 的新增监控表

9.x 系列在 Performance Schema 中新增了多个实用表：

5.3 系统变量调优要点

基于 9.x 的变化，以下变量值得特别关注：

InnoDB 相关：

• innodb_buffer_pool_size：容器化环境中建议配合 container_aware 自动设置
• innodb_parallel_read_threads：并行扫描线程数，默认 4，可根据 CPU 核心数调整
• innodb_log_buffer_size：默认 16M，高写入负载建议增至 64M-128M

复制相关：

• replica_parallel_workers：9.3 起最小值强制为 1，不可再设为 0
• group_replication_autorejoin_tries：默认 3，可根据网络稳定性调整
• group_replication_member_expel_timeout：默认 5 秒，网络抖动频繁时可适当增加

优化器相关：

• optimizer_switch：9.x 新增 hypergraph_optimizer、subquery_to_derived 等开关
• join_buffer_size：默认 256KB，复杂连接可适当增大

容器化相关：

• container_aware：9.6+，建议始终开启

5.4 使用 EXPLAIN 分析 9.x 查询

9.x 的 EXPLAIN 输出增加了多个信息字段：

• EXPLAIN FORMAT=JSON 输出包含优化器版本信息（9.2）
• EXPLAIN 输出中包含多范围读取（MRR）信息和半连接策略描述（9.1）

建议在调优时使用 EXPLAIN ANALYZE（8.0.18+ 引入）获得实际执行耗时和行数估计的对比。

六、其他值得关注的小特性

6.1 FOR UPDATE SKIP LOCKED 的增强

在 9.x 中，SKIP LOCKED 选项在更多隔离级别下可用，并且与 NOWAIT 选项的组合行为得到了规范。

6.2 窗口函数的扩展

窗口函数在 9.x 中获得了更多的帧规范支持，包括 RANGE 帧的增强和更多聚合函数在窗口中的支持。

6.3 公用表表达式（CTE）的递归增强

递归 CTE 在 9.x 中支持更复杂的终止条件检测，避免无限递归的风险，同时递归深度限制的可配置性得到增强。

6.4 升级检查工具

MySQL Shell 提供的 util.checkForServerUpgrade() 函数在 9.x 中得到了持续增强，能够检测更多升级兼容性问题，包括 JSON 函数使用、已移除的插件、不推荐的数据类型等。

七、系列总结：MySQL 9.x 技术全景回顾

7.1 从 8.0 到 9.x：一次深刻的代际跨越

MySQL 8.0 作为历史上最长寿的 LTS 版本（2018-2026），为全球无数企业提供了稳定可靠的数据服务。而 9.x 系列，特别是 9.7 LTS 的发布，标志着 MySQL 进入了一个全新的发展阶段。

回顾整个 9.x 系列的技术演进，我们可以归纳出四大核心趋势：

1. AI-Ready 数据平台

第二期详细解读的向量检索技术（VECTOR 类型、HNSW 索引）和 HeatWave GenAI 能力，使 MySQL 能够原生支撑 RAG、语义搜索、推荐系统等 AI 应用场景。这是 MySQL 从「存储结构化数据」到「存储和理解非结构化语义」的根本性跨越。

2. 多语言开发范式革命

第三期深入剖析的 JavaScript 存储程序与 MLE 组件，将数据库编程的大门向 1700 万 JavaScript 开发者敞开。LIBRARY 模块化、事务 API、国际化 API 等持续演进的能力，正在重塑数据库开发体验。

3. 云原生基础设施转型

第六期聚焦的 container_aware、OpenTelemetry 集成、Kubernetes Operator 生态，使 MySQL 能够以「云原生公民」的身份运行在现代基础设施之上。声明式运维、自动化可观测性、弹性伸缩成为可能。

4. 默认安全与智能自治

第四期的高可用智能选举、第五期的身份认证强化（移除 mysql_native_password、MFA、PBKDF2）、第七期的声明式备份与 PITR，共同构建了「安全与高可用作为默认属性」的新基线。

7.2 社区版与企业版的边界重塑

9.7 LTS 的一个重要里程碑，是将原本仅限企业版的 8 大能力开放至社区版，包括：

• Up-to-date Aware Primary Election（智能主节点选举）
• Automatic Eviction & Rejoin（自动驱逐与重加入）
• Flow-control monitoring（流量控制监控）
• Multi-threaded Applier Extended Statistics（多线程应用器扩展统计）
• OpenTelemetry integration（可观测性集成）
• JSON Duality Views（JSON 双重视图）
• Hypergraph Optimizer（超图优化器）
• Profile-Guided Optimization（配置文件引导优化）

这表明 Oracle 正在响应社区的长期呼吁，逐步降低企业版与社区版之间的能力鸿沟。虽然安全组件（TDE、审计日志、数据脱敏）和高级备份工具仍保留在企业版中，但开放的趋势已经确立。

7.3 升级策略的再思考

对于仍运行在 MySQL 8.0 的用户，2026 年 5 月 1 日之后的安全风险是真实且紧迫的。升级路径主要有两条：

建议大多数生产环境跳过 8.4，直接升级至 9.7 LTS，因为 9.7 已经足够稳定，且提供了更长久的支持窗口和更丰富的功能。

7.4 未来展望：MySQL 10.x 的方向

虽然 9.7 LTS 刚刚确立，但 MySQL 的创新脚步不会停歇。展望未来的 10.x 创新版，我们可以期待：

• 向量能力的深化：VECTOR 列支持作为索引键、更多向量索引类型（IVF、PQ）、与 AI 模型的更紧密集成
• 多语言引擎的扩展：Python、R 等语言的存储程序支持，Wasm 模块的深度集成
• 云原生能力的完善：Serverless 架构适配、更强的 GitOps 集成、跨云复制
• 智能化运维：基于机器学习的自动参数调优、异常检测、容量预测
• 更开放的社区治理：Oracle 承诺的公开路线图、社区贡献机制、第三方工具生态的繁荣

八、写在最后

八期系列文章，从 2026 年 4 月 MySQL 8.0 EOL 的节点起笔，一路伴随 9.7 LTS 的确立、Percona Operator 1.1.0 的发布、社区关于「MySQL 生态系统未来」的公开讨论……这既是 MySQL 技术演进的记录，也是我们共同经历的数据库技术变革的一个缩影。

MySQL 能够走过三十年的历程，从一个小型关系型数据库成长为全球部署最广泛的开源数据库，靠的不仅仅是 Oracle 的持续投入，更是无数 DBA、开发者、开源贡献者、社区布道者共同的热情与智慧。作为这个生态的一份子，我们既是技术的使用者，也是技术演进的一部分。

希望这个系列能为你理解 MySQL 9.x 新技术提供一份系统性的参考，也期待在未来的 MySQL 10.x 时代，我们能够再次相聚，共同见证更多激动人心的创新。

本系列到此结束。感谢你的持续关注！

欢迎在评论区留言，告诉我你对这个系列的看法、建议，或者你希望在未来的系列中看到哪些新主题。我会认真阅读每一条留言。

再见，朋友们。

📚 参考资料

• MySQL 9.0 Reference Manual – JSON Enhancements
• MySQL 9.2 Reference Manual – Partitioning Improvements
• MySQL 9.6 Reference Manual – Performance Schema New Tables
• MySQL 9.7 LTS Announcement – Community Edition Open Features
• Oracle Blog: JSON Duality Views in MySQL 9.7
• MySQL 9.6 Release Notes – InnoDB Optimizations
• MySQL 9.0 Reference Manual – Parallel Read Threads
• Percona Blog: What’s New in MySQL 9.6
• 2026 MySQL Upgrade Best Practices Guide (Oracle)
• MySQL 10.0 Roadmap (Oracle Open Source Summit 2026 Keynote)

（全文完）