Oracle Database 23ai 新特性系列 —— 第三期：数据库内机器学习，让智能与数据共生 在数据库内机器学习（In-Database Machine Learning）这个方向上，Oracle 的布局早在 20 多年前就已经开始——从 Oracle 9i R2 首次提供内置数据挖掘功能，到如今已发展成为企业级数据科学和 AI 平台的核心支柱。而在 23ai 版本中，Oracle Machine Learning（以下简称 OML）迎来了一次质的飞跃，数据库内机器学习不再只是“能用”，而是向着“好用”和“智能”全面进化。 一、核心理念：让智能与数据共生 1.1 “零数据迁移”的 AI 范式 在传统的企业 AI 架构中，数据科学家通常需要将数据从生产数据库导出，经过复杂的 ETL 流程，导入到独立的机器学习平台或 Python 环境中进行模型训练和预测。这一过程伴随着几个难以解决的痛点： 数据时效性缺失：导出、转换、再导入的流程可能耗时数小时甚至数天，模型训练时使用的已是“过期数据” 安全风险与合规挑战：敏感业务数据一旦离开数据库环境，数据主权和审计追踪便难以保障 架构复杂与运维成本：多套系统之间需要维护数据同步、版本对齐和权限映射，系统复杂度呈指数级增长 Oracle Database 23ai 彻底改变了这一范式。OML 将 30 多种高性能机器学习算法直接内置于数据库内核，用户可以通过 SQL、Python、R 或低代码界面在数据所在的位置完成探索、准备、建模、评估和部署的全流程。正如 Oracle 所强调的：“AI where the data lives”——AI 能力的部署不再需要将数据从数据库中搬移，而是让智能能力在数据库内部落地。数据在哪，智能就在哪。 1.2 统一的数据科学平台 OML 超越了传统机器学习平台的边界，它不仅覆盖标准的结构化表数据，还能够分析事务数据、聚合数据、原始星型架构数据，甚至通过 Oracle Text 提取 CLOB 中的非结构化内容进行分析。更关键的是，OML 与数据库的安全体系深度集成——模型构建和评分过程遵循 Oracle 的权限方案，所有操作均被审计跟踪，这在金融、医疗、政府等强监管行业中具有不可替代的价值。 二、强大的数据库内算法库 2.1 超过 30 种原生算法 Oracle Database 23ai 提供了超过 30 种高性能、可并行化的数据库内机器学习算法，覆盖了企业级数据科学任务的主流需求。这些算法在数据库内核级别实现，利用 Oracle 底层 SQL 引擎的并行处理能力，能够处理 PB 级数据，同时保持对 SQL 标准的完全兼容。 核心算法涵盖以下类别： 分类：决策树、逻辑回归、朴素贝叶斯、SVM、随机森林、XGBoost、神经网络 回归：线性回归、多元线性回归、XGBoost（回归）、神经网络回归 聚类：K-Means、O-Cluster 关联规则：Apriori 特征提取：非负矩阵分解（NMF）、主成分分析（PCA） 异常检测：单类 SVM 时间序列：指数平滑方法（ESM） 2.2 23ai 新增算法：XGBoost、ESM 与 NMF 23ai 在算法库方面实现了显著扩充。其中最受关注的是 XGBoost 算法，它支持分类、回归和生存分析三类任务。XGBoost 作为一种基于梯度提升决策树的集成学习方法，在 Kaggle 等数据科学竞赛中长期占据统治地位，它以高精度、高效率和鲁棒性著称。XGBoost 的原生引入，使 OML 在模型精度上进一步逼近甚至超越 Python 生态的主流机器学习框架。 指数平滑方法（ESM） 是另一项重要补充，专为时间序列预测场景设计。相较于传统的 ARIMA 模型，ESM 对数据平滑性和趋势性变化更为敏感，适合处理带有季节性和趋势成分的业务数据（如销量预测、库存规划、流量预估）。 非负矩阵分解（NMF） 则专注于特征提取和降维，在处理高维稀疏数据（如文本挖掘、推荐系统）时具有独特的优势。 2.3 神经网络与随机森林的升级 在 23ai 中，神经网络和随机森林算法也得到了重构。新增的 ore.odmNN 类用于分类和回归任务，能够捕捉输入与输出之间复杂的非线性关系。ore.odmRF 类则以集成学习方式提供随机森林建模能力，替代了原有的 ore.randomForest。这些升级使模型的准确性和稳健性进一步提升。 2.4 数据库内评分的智能优化 OML 支持批量评分和实时评分两种模式。在生产环境中部署模型后，只需通过 SQL 查询调用预测算子即可完成评分，无需额外的部署流程。 值得特别强调的是，在 Exadata 和自治数据库上，OML 支持 Oracle Exadata Smart Scan 技术。评分处理可直接卸载到存储层执行，在数据存储端完成预测计算，显著减少了数据传输和 CPU 负载，带来了数量级的性能提升。 三、ONNX 集成：打破生态壁垒 3.1 ONNX：跨平台模型互操作的桥梁 Open Neural Network Exchange（ONNX） 是一种开源的深度学习模型表示格式，定义了统一的文件格式和算子集，使得模型可以在不同框架之间自由流转。23ai 的 OML 支持导入 ONNX 格式的机器学习模型，这意味着企业可以在任意环境（如 Hugging Face、PyTorch、TensorFlow、Scikit-learn）中训练模型，然后无缝导入到 Oracle 数据库中运行。 3.2 模型导入与应用 OML 支持导入以下类型的 ONNX 模型：文本嵌入模型（Transformer）、分类模型、回归模型和聚类模型。以 AI Vector Search 为例，企业可以通过 PL/SQL 包 DBMS_DATA_MINING 或 DBMS_VECTOR，将 Hugging Face 上的预训练文本嵌入模型以 ONNX 格式加载到数据库中，作为一等数据库对象供 AI Vector Search 使用。 在 OML4Py 中，Oracle 进一步简化了这一流程，提供了将 Hugging Face 模型自动转换为 ONNX 格式的工具。数据科学家无需关心底层转换细节，只需调用统一 API 即可完成从外部模型到数据库内部署的完整链路。 四、AutoML：让机器学习不再是数据科学家的专属 4.1 AutoML […]

Oracle Database 23ai 新特性系列 —— 第二期：数据库内机器学习、图技术与湖仓一体 在第一期中，我们重点介绍了 Oracle Database 23ai 的 AI 向量搜索、JSON 关系二元性视图等划时代技术。如果说 AI Vector Search 赋予了数据库“感知”和理解语义的能力，那么本期介绍的数据库内机器学习（In-Database ML）、图技术（Graph）与湖仓一体（Lakehouse）等特性，则赋予了数据库“思考”、分析和自主优化的能力。 Oracle 在机器学习领域的布局已有超过 20 年的历史——从 Oracle 9i R2 首次提供内置数据挖掘功能，到如今已发展成为企业级数据科学和 AI 平台的核心支柱。而在 23ai 版本中，Oracle Machine Learning（OML）迎来了一次质的飞跃，数据库内机器学习不再只是“能用”，而是向着“好用”和“智能”全面进化。 一、数据库内机器学习（In-Database Machine Learning） 1.1 核心理念：“零数据迁移”的 AI 范式 在传统的企业 AI 架构中，数据科学家通常需要将数据从生产数据库导出，经过复杂的 ETL 流程，导入到独立的机器学习平台或 Python 环境中进行模型训练和预测。这一过程伴随着几个难以解决的痛点： 数据时效性缺失：导出、转换、再导入的流程可能耗时数小时甚至数天，模型训练时使用的已是“过期数据” 安全风险与合规挑战：敏感业务数据一旦离开数据库环境，数据主权和审计追踪便难以保障 架构复杂与运维成本：多套系统之间需要维护数据同步、版本对齐和权限映射，系统复杂度呈指数级增长 Oracle Database 23ai 彻底改变了这一范式。OML 将 30 多种高性能机器学习算法直接内置于数据库内核，用户可以通过 SQL、Python、R 或低代码界面在数据所在的位置完成探索、准备、建模、评估和部署的全流程。正如 Oracle 所强调的：“AI where the data lives”——AI 能力的部署不再需要将数据从数据库中搬移，而是让智能能力在数据库内部落地。数据在哪，智能就在哪。 1.2 超过 30 种原生算法 Oracle Database 23ai 提供了超过 30 种高性能、可并行化的数据库内机器学习算法，覆盖了企业级数据科学任务的主流需求。这些算法在数据库内核级别实现，利用 Oracle 底层 SQL 引擎的并行处理能力，能够处理 PB 级数据，同时保持对 SQL 标准的完全兼容。 核心算法涵盖以下类别： 算法类别 包含算法 分类 决策树、逻辑回归、朴素贝叶斯、SVM、随机森林、XGBoost、神经网络 回归 线性回归、多元线性回归、XGBoost（回归）、神经网络回归 聚类 K-Means、O-Cluster 关联规则 Apriori 特征提取 非负矩阵分解（NMF）、主成分分析（PCA） 异常检测 单类 SVM 时间序列 指数平滑方法（ESM） 1.3 23ai 新增算法：XGBoost、ESM 与 NMF 23ai 在算法库方面实现了显著扩充。其中最受关注的是 XGBoost 算法，它支持分类、回归和生存分析三类任务。XGBoost 作为一种基于梯度提升决策树的集成学习方法，在 Kaggle 等数据科学竞赛中长期占据统治地位，它以高精度、高效率和鲁棒性著称。XGBoost 的原生引入，使 OML 在模型精度上进一步逼近甚至超越 Python 生态的主流机器学习框架。 指数平滑方法（ESM） 是另一项重要补充，专为时间序列预测场景设计。相较于传统的 ARIMA 模型，ESM 对数据平滑性和趋势性变化更为敏感，适合处理带有季节性和趋势成分的业务数据（如销量预测、库存规划、流量预估）。 非负矩阵分解（NMF） 则专注于特征提取和降维，在处理高维稀疏数据（如文本挖掘、推荐系统）时具有独特的优势。 1.4 数据库内评分的智能优化 OML 支持批量评分和实时评分两种模式。在生产环境中部署模型后，只需通过 SQL 查询调用预测算子即可完成评分，无需额外的部署流程。 值得特别强调的是，在 Exadata 和自治数据库上，OML 支持 Oracle Exadata Smart Scan 技术。评分处理可直接卸载到存储层执行，在数据存储端完成预测计算，显著减少了数据传输和 CPU 负载，带来了数量级的性能提升。 二、ONNX 集成：打破生态壁垒 2.1 ONNX：跨平台模型互操作的桥梁 Open Neural Network Exchange（ONNX） 是一种开源的深度学习模型表示格式，定义了统一的文件格式和算子集，使得模型可以在不同框架之间自由流转。23ai 的 OML 支持导入 ONNX 格式的机器学习模型，这意味着企业可以在任意环境（如 Hugging Face、PyTorch、TensorFlow、Scikit-learn）中训练模型，然后无缝导入到 Oracle 数据库中运行。 2.2 模型导入与应用 OML 支持导入以下类型的 ONNX 模型：文本嵌入模型（Transformer）、分类模型、回归模型和聚类模型。以 AI Vector Search 为例，企业可以通过 PL/SQL 包 DBMS_DATA_MINING 或 DBMS_VECTOR，将 Hugging Face 上的预训练文本嵌入模型以 ONNX 格式加载到数据库中，作为一等数据库对象供 AI Vector Search 使用。 在 OML4Py 中，Oracle 进一步简化了这一流程，提供了将 Hugging Face 模型自动转换为 ONNX 格式的工具。数据科学家无需关心底层转换细节，只需调用统一 API 即可完成从外部模型到数据库内部署的完整链路。 三、AutoML：让机器学习不再是数据科学家的专属 3.1 AutoML 用户界面 […]

Oracle Database 23ai 新特性系列 —— 第一期：AI 时代的融合数据库变革 引言 如果说数据库行业在过去十年经历了从“云优先”到“数据驱动”的演进，那么 2024 年 5 月 2 日，Oracle 宣布了一个足以标记行业分水岭的时刻——Oracle Database 23c 正式更名为 Oracle Database 23ai，作为全新的长期支持版本全面发布。版本号的更迭背后，承载的是超过 300 项新特性，其中近一半与人工智能直接相关。这不仅是 Oracle 历史上最大规模的 AI 化升级，更标志着这家年近 50 岁的数据库巨头正以彻底重塑的姿态，将数据库从“存储容器”转变为“能够自主思考和执行的智能平台”。 Oracle 执行副总裁 Juan Loaiza 直言：“Oracle Database 23ai 对全球企业而言改变了游戏规则。”从原计划的 23c 到正式发布的 23ai，Oracle 用一次看似简单的命名调整，完成了数据库行业数年的 AI 转型路线图。Premier Support 将持续至 2031 年 12 月 31 日，这意味着 23ai 将成为未来近十年企业数据架构的核心基石。 本系列将分多期全面解读 Oracle Database 23ai 的核心新特性。作为开篇之作，本期将聚焦于 23ai 的版本定位、AI 向量搜索、JSON 关系二元性视图以及多租户与安全增强等重磅特性。 一、版本定位：为什么是“23ai”？ 1.1 从 23c 到 23ai 的战略转型 Oracle Database 23c 最初于 2022 年 Oracle 年度大会上首次亮相，并于 2023 年初率先面向开发者发布，这是 Oracle 首次在向企业正式发布之前先行面向开发者群体开放——这一策略转变，意在拥抱开发者生态，为数据库业务注入新的增长动力。2023 年 9 月，Oracle 宣布在 23c 中增加向量搜索能力；2024 年 5 月，随着 AI 功能的全面成熟，Oracle 正式将 23c 更名为 23ai 并推向市场。 从“c”（Cloud）到“ai”，品牌标识的变更折射出 Oracle 核心战略的转变：云能力仍是基础，但 AI 能力已成为牵引企业数字化变革的核心引擎。Oracle 数据库不再只是一个事务处理与数据存储的平台，而是原生支持 AI 工作负载的融合数据平台。 1.2 版本发布节奏与可用性 Oracle Database 23ai 在 2024 年 5 月率先在 Oracle Cloud Infrastructure（OCI）、Oracle Exadata Database Service 以及 Oracle Database@Azure 上以云服务形式提供。随后在 2024 年 7 月，23ai 正式登陆 Oracle Database Appliance（ODA），将 AI 能力引入一体化设备平台。对于本地部署（On-Premises）用户，经过多次版本迭代后，Oracle 于 2026 年 1 月 28 日正式发布 23.26.1 版本，标志着 23ai 可在通用 Linux x86-64 平台本地部署，标准支持持续至 2031 年底。 值得一提的是，Oracle 在 2026 年 3 月伦敦 AI World Tour 上进一步宣布，23ai 通过应用 RU 23.26.0 即可无缝升级为 Oracle AI Database 26ai，无需数据库升级或应用重认证——这表明 Oracle 的 AI 数据库产品线已进入持续迭代的快车道。 二、AI Vector Search：将语义搜索内建于数据库核心 如果说 23ai 只能介绍一个特性，那一定是 AI Vector Search。这是本次发布最具标志性的创新，也是 Oracle 将数据库从“关系引擎”进化为“AI 引擎”的核心能力。 2.1 VECTOR 数据类型 AI Vector Search 的基础是全新的 VECTOR 数据类型。它是一个同构数组，支持 8 位有符号整数、8 位无符号整数、32 位浮点数或 64 […]

📢 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 […]

📢 MySQL 新技术系列第七期 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。在前六期，我们依次解读了 9.x 版本策略、向量检索技术、JavaScript 多语言引擎、Group Replication 高可用架构、安全加固体系以及云原生部署能力。这些话题涵盖了 AI 转型、开发范式革命、基础架构韧性和安全合规等多个维度。 然而，所有上述能力都有一个共同的底层依赖——数据本身。无论 MySQL 集群在高可用、安全、可观测性上做了多少优化，一旦发生不可逆的逻辑错误（如 DROP DATABASE）或不可恢复的物理损坏（如存储设备故障），真正能够挽回数据的，只有备份。备份是数据安全的最后一道防线，也是恢复策略的起点。 在云原生时代，备份与恢复的理念正在发生深刻变革：从「定时任务」走向「声明式策略」，从「单点恢复」走向「任意时间点恢复（PITR）」，从「文件存储」走向「对象存储」，从「人工验证」走向「自动化演练」。本期将系统梳理 MySQL 9.x 时代备份与恢复技术的演进路径，结合开源生态的最新实践，提供一份从传统工具到云原生策略的完整指南。 一、备份与恢复的核心概念 在深入工具之前，有必要先厘清备份与恢复领域的几个核心概念。 1.1 逻辑备份 vs 物理备份 这是备份类型中最基础、最重要的分类： 对比维度 逻辑备份 物理备份 工作原理 导出 SQL 语句，重建时逐条执行 直接复制数据库的数据文件 典型工具 mysqldump、mysqlpump、MySQL Shell Dump Percona XtraBackup、MySQL Enterprise Backup 备份速度 较慢（需逐表读取并生成 SQL） 极快（直接复制文件） 恢复速度 较慢（需逐条执行 SQL） 极快（直接替换文件） 跨版本兼容 良好（SQL 标准跨版本） 有限（需版本匹配） 粒度灵活性 高（库、表、甚至部分行） 低（通常为全库或表空间） 适用场景 中小数据量、开发测试、跨版本迁移 大数据量、生产核心、要求快速恢复 简单来说，逻辑备份是把书的内容抄写下来，恢复时需要重新朗读一遍；物理备份是直接把整本书复印一份，恢复时直接把复印件放回去。 1.2 全量备份、增量备份与差异备份 备份类型 说明 恢复复杂度 存储开销 全量备份 备份全部数据的完整副本 最低（一次恢复） 最高 增量备份 只备份自上次备份（全量或增量）以来变化的数据 较高（需按顺序依次应用） 较低 差异备份 只备份自上次全量备份以来变化的数据 中等（需全量 + 最新差异） 中等 在实际生产环境中，这三类备份通常组合使用：例如，每周日凌晨执行一次全量备份，工作日每天执行一次差异备份或增量备份，同时持续归档 binlog，从而在备份存储成本和恢复速度之间取得平衡。 1.3 RPO 与 RTO 任何备份策略的设计都必须围绕两个核心指标： 指标 定义 示例 RPO（Recovery Point Objective，恢复点目标） 数据丢失的最大容忍量，即允许丢失多长时间的数据 RPO = 5 分钟，意味着最多可丢失 5 分钟内产生的数据 RTO（Recovery Time Objective，恢复时间目标） 恢复业务所需的最大时间 RTO = 30 分钟，意味着必须在半小时内完成数据恢复 RPO 决定了备份的频率——binlog 归档的密度、全量备份的周期；RTO 决定了恢复的手段——物理备份比逻辑备份更快，但灵活性更低。备份方案的选择，本质上是在数据安全性、恢复速度、存储成本三者之间寻求最优平衡。 二、工具全景：从传统到现代的演进 2.1 传统工具：mysqldump 与 mysqlpump mysqldump 是 MySQL 最古老的逻辑备份工具，至今仍是最广泛使用的方案之一。它支持单数据库、多数据库、全实例三种粒度的导出，生成的 SQL 文件包含 CREATE DATABASE、CREATE TABLE 和 INSERT 语句，恢复时逐条执行即可。 mysqlpump 是 mysqldump 的升级版，支持多线程并行导出，但在实际应用中普及度不高，因为 MySQL Shell 的 Dump Utility 提供了更现代化的替代方案。 关键参数（适用于 9.x 版本）： 参数 作用 适用场景 --single-transaction 在 InnoDB 表中创建一致性快照，不锁表 所有 InnoDB 生产库备份 --lock-tables=false 避免锁表影响业务（InnoDB 引擎适用） 生产环境备份 --master-data=2 记录备份开始时的 binlog 文件和位置，用于 PITR 需要时间点恢复的场景 --all-databases 备份所有数据库 全实例迁移或灾难恢复 --set-gtid-purged=OFF 控制 GTID 处理方式 跨复制环境备份时 ⚠️ 生产环境提示：对于 InnoDB 引擎，必须使用 --single-transaction 保证备份一致性，同时配合 --lock-tables=false 避免锁表影响业务。 2.2 MySQL Shell Dump Utility：下一代逻辑备份工具 MySQL Shell 不仅仅是客户端工具，其内置的 Dump Utility 代表了逻辑备份技术的代际跨越。 核心命令： // JavaScript 模式 util.dumpInstance('/backup/full'); // 全实例备份 […]

📢 MySQL 新技术系列第六期 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。在前五期，我们依次全景解读了 9.x 版本策略、向量检索技术、JavaScript 多语言引擎、Group Replication 高可用架构以及安全加固体系。这些话题覆盖了 MySQL 作为数据平台在 AI、开发、架构和合规等维度的全面升级。而本期，我们将聚焦于贯穿所有这些能力的基础设施保障——云原生。 近年来，容器化与 Kubernetes 已成为应用部署的事实标准，但数据库的云原生之路却一直充满挑战——状态管理的复杂性、资源调度的精细化要求、以及可观测性的碎片化，都使得「数据库上云原生」成为一个需要审慎对待的话题。MySQL 9.x 系列以一系列精心设计的功能，正在为这一议题给出自己的答案：从 9.6 的 container_aware 容器感知能力，到 9.7 LTS 的 OpenTelemetry 可观测性集成，再到社区日益成熟的 Kubernetes Operator 生态——MySQL 正在从「勉强能在容器中运行」走向「为云原生而设计」。 一、云原生时代 MySQL 面临的挑战 1.1 容器化的核心痛点 在 MySQL 8.x 时代，将数据库部署在容器中面临着几个难以回避的问题： 资源感知盲区：容器编排平台（Docker、Kubernetes）通过 cgroup 为容器设定 CPU 和内存的资源上限，但 MySQL 运行时却无法感知这些限制。默认配置下，MySQL 会假设自己独占宿主机资源，导致在资源受限的容器中过度分配线程池和缓冲区，引发 OOM Killer 或频繁的 CPU 节流。 状态管理的复杂性：数据库是有状态服务的典型代表。容器本身是临时和可替换的，但数据必须持久化。如何在 Pod 重建、节点迁移时确保数据不丢失，是容器化部署的核心难题。 可观测性碎片化：在微服务架构中，MySQL 作为基础设施组件，其运行状态需要与上层应用的可观测性体系打通。传统的 Performance Schema 和慢查询日志虽然功能强大，但难以与 OpenTelemetry、Prometheus 等现代可观测性平台无缝集成。 运维自动化的不足：在生产环境中，MySQL 集群的部署、扩缩容、故障转移和备份恢复需要大量的人工介入，这在云原生时代的「声明式运维」理念下显得格格不入。 1.2 从「容器兼容」到「云原生优先」的演进 MySQL 9.x 系列正在系统性地解决上述挑战，其演进路径清晰可见：9.0 版本奠定基础，9.6 版本引入 container_aware 容器感知能力，9.7 LTS 实现 OpenTelemetry 集成并将多项企业级能力开放至社区版，而 Kubernetes Operator 生态则在不同版本中持续演进。 二、容器化部署：从手动调参到自动适配 2.1 container_aware：MySQL 9.6 的里程碑特性 在 9.6 版本之前，MySQL 在容器中运行时，DBA 需要手动通过配置文件或启动参数，将容器的资源上限「翻译」成 MySQL 内部参数（如 innodb_buffer_pool_size、thread_pool_size 等），不仅繁琐，而且容易出错——一旦容器资源上限调整而 MySQL 配置未同步更新，轻则资源浪费，重则 OOM 崩溃。 MySQL 9.6.0 引入的 container_aware 启动选项，从根本上改变了这一局面。开启该选项后，MySQL 服务器可以自动识别容器环境的 CPU 和内存资源限制（通过读取 cgroup 信息），并动态调整内部的线程池大小、缓冲区尺寸等关键配置，确保在容器环境中实现资源利用最优化。 启用方式： # 在容器中启动 MySQL 9.6+ 时添加 container_aware 参数 docker run -d --cpus=4 --memory=8g mysql:9.6 --container_aware=ON 工作原理：当 container_aware=ON 时，MySQL 会在启动时主动读取容器的 CPU 配额和内存限制，然后根据这些值自动计算并设置以下关键参数： MySQL 参数 传统做法（手动） container_aware 自动行为 innodb_buffer_pool_size 手动设为容器内存的 70-80% 自动计算并设定 innodb_log_file_size 需根据 buffer pool 大小手动调整 自动关联调整 thread_pool_size 手动设为容器 CPU 核心数 自动设为 CPU 配额对应的核心数 innodb_io_capacity 需根据存储性能手动调整 自动适配 IO 限制 ⚠️ 实践建议：container_aware 适用于容器化部署的绝大多数场景，但在某些需要对资源分配进行精细控制的场景（如高负载 OLTP 系统），DBA 仍可手动覆盖部分参数。该选项的设计原则是「自动适配优先，手动可覆盖」。 2.2 9.6 版本的其他云原生相关增强 除了 container_aware，MySQL 9.6 还带来了多项与云原生部署密切相关的改进： GTID 复制性能优化：引入了一套全新的 GTID 集合数据结构库，彻底替换旧有实现。新实现使 GTID 处理逻辑更简洁、代码可维护性显著提升，并在分布式环境中有效提升了跨节点事务追踪和故障恢复的效率。对于在 Kubernetes 上部署跨节点复制的用户而言，这一改进直接降低了 GTID 集合操作的性能开销。 审计日志组件化重构：将原有的单体审计日志系统拆分为轻量级、可插拔的专用组件，支持更精细的输出格式（XML/JSON/CSV）和存储配置。在容器化环境中，组件化的架构意味着 DBA 可以根据实际需求按需安装审计组件，避免不必要的资源消耗。 Performance Schema 账户锁定监控：新增 TEMPORARY_ACCOUNT_LOCKS 表，用于实时查看被临时锁定的账户信息。这一能力在容器化环境中尤为重要——当大量短生命周期容器同时连接数据库时，账户锁定的可见性变得空前重要。 三、Kubernetes Operator：数据库运维的声明式革命 如果说 container_aware 解决了单实例容器化的问题，那么 Kubernetes Operator 则解决了「如何在 K8s 上规模化、自动化地运行 MySQL […]

📢 MySQL 新技术系列第五期 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。在前四期，我们依次全景解读了 9.x 版本策略、向量检索技术、JavaScript 多语言引擎，以及 Group Replication 高可用架构。这些话题分别聚焦于 AI-Ready 数据平台、开发范式变革和架构韧性提升，而本期我们将聚焦于贯穿所有技术演进的基础保障——安全。 随着 8.0 正式 EOL、9.7 LTS 接棒成为新一代长期支持版，MySQL 的安全能力也在 9.x 系列中经历了一场系统性重塑。从 9.0 坚决移除 mysql_native_password 插件，到 9.5 将复制加密设为默认行为，再到 9.6 实现审计日志组件化改造——MySQL 的安全演进脉络清晰可见：从「可选的加固项」走向「默认安全」。 本期将系统梳理 9.x 系列在身份认证、权限模型、数据加密、审计与脱敏等方面的安全增强，并结合开源生态的安全实践与企业级合规要求，提供面向生产环境的安全配置最佳实践。 一、9.x 安全演进全景 MySQL 9.x 系列的安全能力演进可以归纳为五个核心维度，覆盖了数据安全从「入口到落盘」的全链路： 安全维度 9.0 9.1 9.2 9.3 9.5 9.6 9.7 LTS 身份认证 移除 mysql_native_password OpenID Connect 支持 — — SHA-1 认证弃用 错误提示标准化 caching_sha2_password 支持 PBKDF2 权限模型 — CREATE_SPATIAL_REFERENCE_SYSTEM 权限细化 — — 强制角色激活 Performance Schema 账户锁定表 — 数据加密 — — — — 复制连接默认加密；密钥环增强 OpenSSL 升级至 3.0.18 — 审计与脱敏 — — — — — 审计日志组件化；MD5/SHA1 迁移至独立组件 动态数据脱敏（企业版） 可观测性 — — — — — Performance Schema 锁定账户表；HOST_CACHE 增强 OpenTelemetry 集成 二、🔑 身份认证：弱认证的终结 2.1 mysql_native_password 的移除（9.0） 在 MySQL 8.0 时代，虽然默认认证插件已切换到 caching_sha2_password，但 mysql_native_password 插件仍然可用，大量遗留系统继续依赖 SHA-1 哈希算法进行密码认证。SHA-1 早已被证实存在碰撞攻击风险（详见 SHAttered 攻击）且不含盐值，在现代安全标准下已被视为不安全的哈希算法。 MySQL 9.0 迈出了决定性的一步：彻底移除 mysql_native_password 认证插件，不再接受来自仅支持该插件的旧客户端程序的认证请求。同时，MySQL 客户端工具默认不再包含对该插件的支持。 升级影响：在从 8.0 升级到 9.x 之前，DBA 必须检查所有应用程序的 MySQL 客户端库是否支持 caching_sha2_password。如果某个应用程序使用了过时的 Connector 版本（如 Connector/J 8.0.11 之前的版本），升级后将无法连接数据库。 2.2 OpenID Connect 与 MFA 支持（9.1 / 9.6） MySQL 企业版在 9.1 版本中引入了 OpenID Connect 可插拔认证，使用户可以基于 OAuth 2.0 框架，通过外部身份提供商（如 Okta、Azure AD、Google Identity）的认证令牌登录 MySQL 服务器。该能力与 MySQL 8.0 就已引入的 LDAP、PAM 认证插件形成互补，使 MySQL 能够无缝融入企业级统一身份管理平台。 在 9.6 版本中，MySQL 进一步支持了多因素认证（MFA），单个账户最多可配置三种认证方法，从而实现两因素（2FA）或三因素（3FA）认证。这意味着 DBA 可以为高权限账户配置「密码 + WebAuthn 生物识别 + OIDC 令牌」的多层身份验证，显著提升账户安全性。 2.3 密码哈希强度提升（9.5 / 9.7 LTS） 9.5 版本：将 caching_sha2_password_digest_rounds 参数的默认值从 5000 大幅提升至 10000。哈希迭代次数翻倍意味着暴力破解的时间成本呈指数级上升。同时，SCRAM-SHA-1 认证方法被标记为弃用，默认改用更安全的 SCRAM-SHA-256。 9.7 LTS：caching_sha2_password […]

📢 MySQL 新技术系列第四期 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。在前三期，我们依次全景解读了 9.x 版本策略、向量检索技术，以及 JavaScript 存储程序与多语言引擎。这些话题分别聚焦于 AI-Ready 数据平台和开发范式变革，而本期我们将回归数据库运维最核心的命题——高可用。 在传统的主从复制时代，故障切换要么依赖人工介入，要么借助外部组件（如 MHA、Orchestrator），不仅运维成本高，而且恢复时间难以保证。随着 MySQL 9.3 引入智能主节点选举，再到 9.7 LTS 将企业级高可用能力开放至社区版，MySQL Group Replication 正在经历从「被动容错」到「主动智能恢复」的质变。 本期将系统梳理 Group Replication 在 9.x 系列中的技术演进，解读智能选举、自动重加入、多线程应用器增强等核心特性，并结合 Uber 大规模迁移的真实案例，探讨新一代高可用架构的最佳实践。 一、Group Replication 架构回顾：从基础到演进 1.1 什么是 Group Replication？ MySQL Group Replication 是一种基于 Paxos 共识协议的分布式状态机复制方案，通过组通信系统（Group Communication System，GCS）在集群成员之间传播事务，确保数据在多数节点上达成一致后才正式提交。相比传统的异步复制或半同步复制，Group Replication 提供了更高的数据一致性保障和内置的故障自动切换能力。 1.2 两种运行模式 模式 说明 适用场景 单主模式 仅一个节点（Primary）接受写操作，其余节点（Secondary）为只读 绝大多数生产场景，简化写入冲突处理 多主模式 所有节点均可接受写操作，通过冲突检测机制防止数据不一致 对写入可用性要求极高的场景，但需要应用层处理分布式事务冲突 在单主模式下，当主节点发生故障时，集群会自动触发选举流程，选出一个新的主节点，客户端写入请求可以迅速恢复。这一「自动化」正是 Group Replication 区别于传统主从复制的核心优势。 1.3 9.x 系列演进路线图 版本 Group Replication 关键演进 9.0 基础能力持续优化 9.1 原子 DDL（CREATE/DROP DATABASE）实现崩溃安全 9.2 复制监控与性能调优 9.3 Up-to-date Aware Primary Election（企业版首发）；自动重入组（Auto-Rejoin）增强 9.4-9.6 增量优化与稳定性提升 9.7 LTS 智能选举能力开放至社区版；Flow-control monitoring 开放；自动驱逐与重加入开放 二、🔄 智能主节点选举：从「权重优先」到「数据优先」 2.1 传统选举算法的局限性 在 9.3 之前的版本中，Group Replication 的主节点选举主要依赖 成员权重（member weight） 机制：DBA 为每个成员配置一个权重值，选举时权重最高的节点胜出；如果权重相同，则以 server_uuid 的字典序作为决胜依据。 这套机制虽然简单可控，但存在一个明显的盲点——权重反映的是管理员的偏好，而非节点实际的数据状态。设想一个场景：某从节点由于网络波动或硬件瓶颈而出现了较大的数据延迟，但管理员仍为其配置了较高的权重。当主节点发生故障时，这个「延迟节点」可能被选为新的主节点，然后不得不花费相当长的时间追赶缺失的事务日志，从而大幅延长故障恢复时间。 2.2 Up-to-date Aware Primary Election（9.3） 为解决这一痛点，MySQL 9.3 引入了一种新的选举策略：Most Up-to-date（数据最新优先）。该策略在执行权重比较之前，会先检查各成员的数据状态，选择数据最新的节点作为主节点，从而显著减少故障转移后的同步时间。 该功能通过组件 component_group_replication_elect_prefers_most_updated 实现。DBA 需要在所有组成员上安装该组件： INSTALL COMPONENT 'file://component_group_replication_elect_prefers_most_updated'; 启用后，选举流程变为多级判定： Step 1：比较各成员的数据最新程度（基于事务序列号等指标），选择数据最新的节点 → Step 2：若数据最新程度相同，再比较成员权重 → Step 3：若权重也相同，按 server_uuid 字典序决胜。 为了便于监控和排查，该组件还提供了状态变量： 状态变量 说明 Gr_latest_primary_election_by_most_uptodate_members_trx_delta 新主节点与第二最新节点之间的事务差距数量 Gr_latest_primary_election_by_most_uptodate_member_timestamp 最后一次使用「数据最新优先」策略进行选举的时间戳 当使用该策略选举出新主节点时，MySQL 还会记录一条日志，明确说明选举依据和新主节点与次新节点之间的事务差距，为故障复盘提供了清晰的可追溯性。 2.3 从企业版到社区版（9.7 LTS） 在 9.3 版本中，该功能仅限 MySQL 企业版用户使用。随着 9.7 LTS 的发布，Oracle 兑现了将企业级能力开放至社区版的承诺——Up-to-date Aware Primary Election 现已面向所有 MySQL 用户免费开放。这意味着即使是社区版用户，也能在生产环境中享受这一智能故障恢复能力。 三、⛑️ 自动恢复：从手动介入到智能自愈 3.1 自动重加入（Auto-Rejoin） 在分布式环境中，节点被「驱逐」的原因多种多样：网络短暂中断、硬件抖动、资源争抢等，其中相当一部分是临时性故障，节点在条件恢复后本应自动回归集群。但在早期版本中，被驱逐的节点只能被动地进入只读模式，等待管理员手动介入。 MySQL 9.3 在自动恢复方面做出了重要改进。当节点被驱逐后，它会自动尝试重新加入集群，每次尝试间隔 5 分钟，最多尝试 3 次。如果所有尝试均失败，节点才进入只读模式等待人工介入。 该行为可通过变量 group_replication_autorejoin_tries 进行配置： SET GLOBAL group_replication_autorejoin_tries = 5; -- 最多尝试5次 在 InnoDB Cluster / AdminAPI 层面，也可以通过 autoRejoinTries 选项在集群级别或实例级别进行配置，接受 0 到 2016 之间的整数，默认值为 3。 ⚠️ 重要提示：自动重加入机制要求被驱逐的节点在重试期间始终保持只读模式，以避免在重连过程中产生数据冲突。若集群已失去法定人数（Quorum），则不应期望成员自动重加入，因为法定人数是重新加入的前提条件。 3.2 自动驱逐与重加入（Automatic Eviction […]

📢 MySQL 新技术系列第三期 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。在第一期，我们全景解读了 MySQL 9.x 系列的版本策略与核心新特性；在第二期，我们聚焦于向量检索技术，剖析了 MySQL 如何从传统关系型数据库向「AI-Ready 数据平台」转型。 这一期，我们将深入探讨贯穿整个 9.x 系列的另一项革命性能力——JavaScript 存储程序与多语言引擎（MLE）。从 9.0 引入基础支持，到 9.2 的 LIBRARY 模块化，再到 9.3 的 DECIMAL 与国际化 API 增强，JavaScript 正在重写数据库编程的规则。本文将带你系统解读 JavaScript 存储程序的技术演进、实战应用，以及开源社区如何突破 Oracle 企业版限制，将这一能力推向更广阔的应用空间。 一、为什么数据库需要 JavaScript？ 1.1 SQL/PSM 的局限性 在过去二十年中，MySQL 存储过程只能使用 SQL/PSM（Persistent Stored Modules）语言编写。这是一种声明式语言，在处理复杂算法、字符串操作、JSON 处理等任务时显得笨拙且低效。正如 Percona 的工程师所言：SQL/PSM 难以调试、表现力有限，对于算法密集型任务更是「糟糕的选择」。 1.2 将逻辑推向数据的价值 JavaScript 存储程序的核心价值在于减少数据库与应用程序之间的数据移动： 问题 JavaScript 存储程序的解决方案 网络开销 数据处理在数据库内完成，无需往返传输 延迟累积 减少应用层与数据库之间的频繁交互 内存/存储成本 避免在中间层处理大量数据 安全风险 数据留存在数据库内，降低暴露面 云出口费用 减少跨服务的数据传输，降低云成本 1.3 JavaScript 的天然优势 MySQL 官方选择 JavaScript 作为首门多语言引擎支持的编程语言，理由充分：超过 1700 万 JavaScript 开发者的庞大技能池、npm 上数百万个可复用的 ECMAScript 模块、ECMAScript 2021 标准带来的现代语言特性，以及 GraalVM 运行时带来的高性能执行。 二、技术全景：从 MLE 到 JavaScript 存储程序 2.1 多语言引擎组件（MLE） MLE（Multilingual Engine Component）是 MySQL 企业版的一部分，在存储函数和存储过程中提供对 SQL 以外语言的支持。 核心特征： URN：file://component_mle 平台支持：MySQL 企业版支持的所有平台（Solaris 除外） 运行时：JavaScript 代码通过 GraalVM 执行，用户可免费使用 GraalVM 企业版（EE）的所有功能，包括编译器优化、性能和安全特性 安装要求：MLE 组件需要通过 INSTALL COMPONENT 安装 安装注意事项： 无法从已经创建或执行过任何 JavaScript 存储程序的用户会话中卸载 MLE 组件。建议在不同于安装 MLE 组件的会话中创建和执行 JavaScript 存储程序。 2.2 版本演进时间线 版本 JavaScript 能力演进 9.0 首次引入 JavaScript 存储程序，支持基础存储函数和存储过程 9.1 支持 JavaScript 程序使用 VECTOR 类型 9.2 LIBRARY 模块化：CREATE LIBRARY / DROP LIBRARY；事务 API（START TRANSACTION / COMMIT / ROLLBACK）；ENUM/SET 类型识别；MySQL 内置函数调用（通过全局 Mysql 对象） 9.3 DECIMAL 类型支持；国际化 API（Intl）；await 动态加载库；ALTER LIBRARY / SHOW LIBRARY STATUS 9.6+ 持续优化与稳定性增强 2.3 数据类型的无缝映射 MySQL 在 JavaScript 存储程序中对数据类型的支持覆盖了绝大部分常用类型： 整数类型： TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT 全系列，支持 SIGNED 和 UNSIGNED。BOOL 和 SERIAL 作为整数类型处理。 字符串类型： CHAR、VARCHAR、TEXT、BLOB 均受支持，使用 utf8mb4 或 binary 字符集。最大 LONGTEXT 值支持 1,071,741,799 字符；最大 LONGBLOB 支持 2,147,483,639 字节。 JSON 类型： 完整支持，JavaScript 代码中直接作为对象处理。 […]

📢 MySQL 新技术系列第二期 各位数据库同行、开发者朋友们，大家好！ 欢迎回到「MySQL 新技术」系列。在第一期「告别 MySQL 8.0 时代，全景解读 MySQL 9.x 创新版」中，我们系统梳理了从 9.0 到 9.7 的版本策略与核心新特性，明确了 9.7 LTS 已接替 8.0 成为新一代长期支持版。 这一期，我们将聚焦一个贯穿整个 9.x 系列最令人兴奋的技术方向——向量检索（Vector Search）。从 9.0 引入原生 VECTOR 类型，到 9.7 LTS 向量能力的全面成熟，MySQL 正在从传统关系型数据库向「AI-Ready 数据平台」完成关键一跃。本文将带你全景解读 MySQL 向量检索的技术演进、内核实现、生产实践，并展望未来的发展方向。 一、为什么 MySQL 需要向量检索？ 1.1 技术背景：从关键词匹配到语义理解 在大模型与检索增强生成（RAG）技术普及的当下，向量检索已从小众能力跃升为通用需求。关系型数据库作为企业数据架构的核心，长期以来以结构化数据管理、ACID 事务、成熟的 SQL 生态为核心优势，但在非结构化数据（文本、图片、音频）的语义检索场景中存在天然短板。 MySQL 作为全球使用最广泛的关系型数据库，也顺应这一趋势完成了向量检索能力的迭代，将向量检索纳入标准功能体系。 1.2 MySQL 引入向量检索的核心价值 价值维度 说明 架构简化 无需额外部署独立的向量数据库（如 Milvus、Chroma），在现有 MySQL 架构中统一管理结构化数据 + 向量数据，降低运维成本 能力互补 支持「SQL 条件过滤 + 向量相似性检索」的复合查询，例如「查询 2024 年发布的、与‘MySQL 向量检索’语义相似的技术文档」 生态兼容 依托 MySQL 成熟的事务机制、binlog、主从复制和备份策略，保障向量数据的安全性和稳定性 1.3 传统方案的痛点 在 MySQL 原生向量能力出现之前，用户往往面临两难选择：要么将向量数据存储为 TEXT/BLOB 类型，通过关键词匹配（LIKE/全文索引）检索，无法理解语义；要么引入独立的向量数据库，但需要面对两套安全模型、两套可观测性体系，以及难以回避的数据一致性问题。MySQL 原生向量检索的引入，正为解决这一困境而生。 二、MySQL 向量检索技术全景图 2.1 两条路径：原生支持 vs 插件扩展 目前，在 MySQL 生态中获取向量检索能力主要有两条路径： 方案 技术实现 适用版本 特点 原生 VECTOR MySQL 内核原生支持的 VECTOR 数据类型 + HNSW 索引 8.4 LTS / 9.x 系列 官方标准方案，与 MySQL 生态无缝集成 MyVector 插件 开源插件，通过 UDF 和组件机制扩展向量能力 8.0 / 8.4 填补了 8.0 用户无法升级至 8.4 时的能力缺口，无需更改表结构即可添加向量支持 两条路径并非互斥。对于已经运行在 8.0 且暂时无法升级的用户，MyVector 插件提供了平滑的过渡方案；而对于能够升级到 8.4 LTS 或更高版本的用户，原生 VECTOR 无疑是首选。 2.2 原生 VECTOR 数据类型 MySQL 9.0 首次引入了原生 VECTOR 数据类型，允许开发者直接在 MySQL 中存储和操作向量嵌入。 核心参数与函数 项目 说明 存储格式 每个条目为 4 字节单精度浮点值 默认最大长度 2048 绝对上限 16383 VECTOR_DIM() 返回向量的维度 STRING_TO_VECTOR() / TO_VECTOR() 将字符串格式转换为二进制向量表示 VECTOR_TO_STRING() / FROM_VECTOR() 将二进制向量转换为列表格式字符串 向量比较运算符 支持向量之间的等值比较 基本操作示例 -- 创建包含 VECTOR 列的表 CREATE TABLE products ( id INT PRIMARY KEY, name VARCHAR(255), embedding VECTOR(1536) NOT NULL ); -- 插入向量数据 INSERT INTO products VALUES (1, 'MySQL 9.7 LTS 发布公告', STRING_TO_VECTOR('[0.12, -0.34, 0.56, ...]')); […]