本文整理自《深入解读 VSAG——OceanBase 自研开源向量索引库》系列文章作者 | 金加宝、李昊天、王翔宇、杨鸣宇、钟萧遥（按姓名首字母排序）摘要：OceanBase向量索引库VSAG通过引入SIMD、内存分配优化、量化等方法提升向量检索性能。其核心算法包括：BSA在保证检索精度的前提下加速向量距离计算；EnhanceGraph利用搜索日志和构造日志动态增强图索引，提升查询准确性；DFSANN适配存算分离架构，实现低成本混合存储检索；HGraph则通过组件化分层架构支持多场景平滑切换。向量搜索技术，被认为是海量非结构化数据检索的关键技术之一，这会涉及到高维空间的搜索问题，通常会通过近似最近邻搜索（Approximate Nearest Neighbor Search, ANNS）的方式来在高维空间中进行检索，以此来找到满足要求的数据。随着 AI 应用场景的发展，半结构与非结构化数据的涌现，向量数据库成为 AI 时代重要的数据基座。在 VectorDBBench 基准测试中，OceanBase 在同等环境下向量性能已达到业界主流开源向量数据库的最优水平。这一出色表现很大程度上得益于 OceanBase 向量背后的向量索引库 —— VSAG。向量索引，作为影响向量检索准确率、查询性能的重要因素，是决定向量数据库性能的关键基础。当前，开源社区已经涌现许多算法库，每个算法库有不同的特点，适用于不同的向量检索场景，包括在相似性搜索领域最有名、维护时间最长的 FAISS 算法库 （facebookresearch/faiss）；由于高效、易于集成、单线程读写等特性广泛应用于搜索推荐系统的 hnswlib 算法库（nmslib/hnswlib）；以及本文将深入介绍的 OceanBase 开源向量索引库 VSAG。VSAG 库通过引入了许多 SIMD、内存分配和布局、量化等方法，获得了卓越的近似 K 近邻图的搜索性能表现。受益于其资源管理模块，在系统中能够提供租户级细粒度的计算和存储资源管理，提供了超大规模下混合内存与磁盘的快速检索方案。VSAG 在 960 维的 GIST 数据集上表现出色，在 ANN-Benchmarks 测试中远超其他算法。今天，让我们从最基础的概念讲起，一起走进 OceanBase 向量背后的向量索引库 VSAG，并揭秘其中各项硬核算法。向量是什么向量（Vector / Embedding）是一个数据结构，其中包含一个浮点数的数组。这是一个向量的示例：向量在检索相似的图片、音频和文本等方面发挥着关键作用，这源于其数据属性和特征表示能力。在机器学习和数据科学领域，向量被广泛用于描述数据特征。以图片数据为例，我们可以将其表示为向量。在计算机中，图片本质上是由像素构成的二维矩阵。每个像素的亮度值可视为图片的一个特征，因此，我们可以将这些亮度值串联成一个高维向量，从而实现图片的向量化表示。这种向量化表示使我们能够利用向量空间中的距离和相似度度量方法来比较不同图片之间的相似程度。例如，欧氏距离可用于衡量两个图片向量间的像素差异，而余弦相似度则可测量它们的方向差异。通过计算向量间的距离或相似度，我们可以量化评估不同图片之间的相似程度。在实际应用中，图片除了像素亮度以外还有轮廓等更复杂的特征可以用于比对相似度，所以一般会使用神经网络来进行特征向量的提取，然后通过距离函数来衡量不同图片之间的相似度。这就是为什么向量可以被用来衡量非结构化数据的相似度。当可搜索内容表示为向量时，查询可以在相似内容中找到接近的匹配项。用于向量生成的嵌入模型知道哪些单词和概念相似，并将生成的向量放置在嵌入空间中。例如，关于 “clouds” 和 “fog” 的向量化源文档更有可能显示在关于 “mist” 的查询中，因为它们在语义上相似，即使它们在词法上不匹配。如何衡量向量相似度向量相似度有几种不同的度量方法，其中最常见的是欧式距离、点积距离和余弦距离。这些度量方法各有特点和适用场景。欧式距离直观地反映了向量在空间中的绝对距离，适用于需要考虑向量大小的情况。点积距离反映了向量的方向和大小，常用于机器学习中的权重计算。余弦距离则专注于向量间的角度，忽略大小差异，特别适合文本相似度等归一化场景。选择合适的度量方法对于提高相似度计算的准确性和效率至关重要，并且往往需要根据具体的应用场景和数据特征进行权衡。相似度搜索的一种方法：近似最近邻搜索（ANNS）在大规模数据集中，传统的精确最近邻搜索算法可能需要花费大量时间和计算资源。因此，近似最近邻检索（Approximate Nearest Neighbor Search，ANNS）技术的出现满足了对相似度搜索更快速和高效的需求。近似最近邻检索通过牺牲一定的搜索准确度，来换取更快的搜索速度。这种特性使得 ANNS 技术在需要快速检索大规模数据集中的相似对象时极具优势，特别是在诸如推荐系统、图像识别、自然语言处理和数据挖掘等领域。近似最近邻检索技术的应用范围非常广泛，它在提高效率的同时保持了对搜索结果准确度的要求，因此在大数据量情况下更能展现出其价值。一般来说，近似最近邻搜索依赖对数据集提前构建好一个索引，搜索在索引上进行。通过使用索引，近似最近邻搜索一般能将耗时降低几个量级。常见的向量索引类型：基于树的索引结构、基于哈希的索引结构、基于图的索引结构、基于倒排的索引结构等。这些索引对于构建时间、批量查询、异构计算等场景分别有不同的优势，一般在业务场景中会根据实际需要来选用索引。本文开头提到的 faiss，hnswlib，包括 vsag 都属于 ANNS 算法库。向量搜索的挑战在哪里虽然现在我们已经有了很多成熟的开源算法，但随着非结构化数据量的持续增长，以及更多 AI 应用的诞生，向量搜索技术被提出了更多的挑战。更快的搜索速度是第一个挑战。对于更好性能的追求在业务中是一直存在的，更快的搜索速度意味着单位实例能够服务更多的用户请求，同时更快的搜索速度能够降低访问延迟提升体验。更高的搜索精度是第二个挑战。向量召回作为搜索推荐链路的上游环节，搜索精度很大程度上影响到整条搜索链路的召回精度上界。通过提高向量召回的精度，能够给后续的排序环节提供更加高质量的输入。在 RAG 应用中同理，向量的召回率越高，能够输入给语言大模型的内容就越好，语言大模型的回答就越准确。更低成本的搜索是第三个挑战。更低成本更多是企业从降本增效出发，希望在技术上获得收益。向量检索因为数据结构本身的特点，查询服务的成本本来就高于标量数据。而当前音视图文数据量的增长给系统带来的服务成本来增长迅速。近几年对于低成本的向量索引的探索更多被关注到，比较有名的是微软提出的 DiskANN 算法，而后续在学术界和工业界也涌现出更多相关的后续工作。VSAG 硬核算法详解1.BSA（Bridging Speed and Accuracy）：在保证检索精度的前提下加速向量距离计算背景与设计目的现有向量检索算法（如 HNSW、IVF）经过多年优化，对索引结构的改进只能带来小幅度性能提升。向量检索算法的性能瓶颈在于“距离计算”这一操作：在 HNSW 中距离计算约占 80% 的总时间开销，在 IVF 中更是接近 90%。使用计算代价更低的近似距离代替精确的距离计算，例如乘积量化（product quantization），虽然可以大幅提高距离计算的效率，然而会导致检索精度的大幅下降，使其很难应用于高精度的向量检索场景。因此，如何既利用近似距离的实现快速计算、又能够保持高检索精度，成为了 BSA 算法试图解决的关键问题。核心技术与实现方案BSA 算法将向量检索中的距离计算分为两类，其中第一类为需要精确距离计算（Label 0），第二类为不需要精确距离计算（Label 1），并利用近似距离、当前搜索过程中的队列阈值作为特征，训练一个线性二分类器，通过调整模型截距来保证分类器的分类精度达到检索要求。在搜索过程中，如果线性分类器将当前距离计算分为第一类，则需计算当前点的精确距离并更新结果队列；如果线性分类器的分类结果为第二类，该次的距离计算则可以避免。该算法不仅可以加速内存向量检索的距离计算，同时还可以避免磁盘方案的冗余 IO。性能表现以下展示了几种加速距离计算的方法在 GIST 和 DEEP 两个数据集上的性能表现。结果可见，BSA+OPQ 框架实现了原始 HNSW 最高 1.7 倍的检索性能提升，以及相对原始 IVF 最高 2.2 倍的提升，远超索引结构优化带来的性能提升。同时 BSA 方法不受索引结构的限制，可以应用于任意向量检索算法。实战应用当前，BSA 方法在内部的数据和实际应用场景均已进行验证和应用：在 100w 数据集上，在召回率不降低的前提下，搜索耗时从 7.53ms 下降到4.85ms，降低 35.59% 。这意味着吞吐能够增加 55.25% 。在 1000w 数据集上，在召回率不降低的前提下，搜索耗时从 10.09ms 下降到7.33ms，降低 27.35% 。这意味着吞吐能够增加 37.64% 。2. EnhanceGraph：动态增强的图索引构建，提升查询准确性背景与设计目的以 k-NNs Graph 为例，基于图的近似最近邻搜索（ANNS）算法以其优越的搜索性能和精确性成为主流。为了对其进行进一步优化，当前许多研究正在探索通过边的剪枝策略，减少索引的空间占用和提高搜索效率，然而此类策略往往会导致检索精度大幅下降。此外，由于传统基于图的索引在构建后将保持静态，所以在人脸识别等服务中经常会出现反复识别失败的情况。面对上述挑战，EnhanceGraph 将搜索日志和构建日志用于辅助图索引的构建，从而有效利用历史查询数据和被丢弃的信息完善图索引，从而在保障查询性能的同时提升准确性。核心技术与实现方案EnhanceGraph 利用搜索日志和构造日志对图进行动态增强，前者可用于检测图结构中的缺陷，后者可用于补充近似图中缺失的 k-NNs，从而在可接受的空间成本增加的情况下显著提高查询的准确性。与现有的索引在构建完成后即保持静态不同，EnhanceGraph 允许在搜索过程中实时进行反馈，基于用户的实时反馈或历史查询生成共轭图，用于维护所有反馈的召回信息。在线搜索时，第一阶段首先在近邻图进行搜索，第二阶段使用共轭图对搜索结果进行补充以增强召回表现。具体来说，在构建图索引时，首先将近似图中被裁掉的边（构造日志）添加到共轭图中。在历史查询中，将失败查询时收敛到的局部最优解，与离线计算或者用户反馈的全局最优解结合，构成搜索日志。基于搜索日志，可以在共轭图中添加缺失的从局部最优解到全局最优解的边。这些边将在搜索的第二阶段补充搜索结果，以提高召回率，确保历史中失败的查询不会再次收敛到局部最优。性能表现如图所示为 EnhanceGraph 在若干主流数据集（GIST1M；SIFT1M；GloVe-100）和蚂蚁数据集上对召回率增强的表现。结果显示，在部分数据集上，EnhanceGraph 能显著提高 Recall@1 的召回率，最高从 41.74% 提升到 93.42%。得益于从生成的查询和历史的查询得到的搜索信息，大幅度降低了未来的查询对 TOP1 最近邻的召回失败情况。对于OceanBase 数据集，即使是 Recall@1 非常高的情况下也能无损 QPS 提高召回率（从 99.8% 提升到 99.9%）。另外，使用构建信息对二阶段搜索进行补充也显著提升了 Recall@10。实战应用当前，EnhanceGraph 已在实际业务场景中进行了测试验证：在 100w 数据集上，使用生成式方法，在几乎不降低 QPS 和使用少量额外存储空间（少于 7%），提升 HNSW 的 TOP-1 召回率从 99.8% 到 99.96% 。保证召回失败的人群有 80% 以上的概率不会再失败。在 100w 数据集上，使用历史查询进行反馈，在几乎不降低 QPS 和使用少量额外存储空间（少于 3%），提升 HNSW 的 TOP-1 召回率从 99.8% 到 99.97% 。保证召回失败的人群有 85% 以上的概率不会再失败。3. DFSANN：适配存算分离架构的低成本检索方案背景与设计目的当下的向量检索的研究主要关注纯内存向量索引的性能，较少关注海量数据的存储性能。然而，随着非结构化数据的快速膨胀，内存开销增加，数据的存储成本飙升，只使用压缩方法会显著降低精度；同时，存算分离架构中的共享存储相比起本地 SSD 会有更高的 IO 成本，这导致现有的基于 IO 的检索方案（例如DiskANN、SPANN等）不一定有比较高的性能。因此，业界迫切地需要一种能够适配在存算分离架构系统上的低成本的检索方案。核心技术与实现方案现有磁盘方案中，搜索过程会产生频繁 IO，且重排阶段有较多不必要的精确距离计算，从而造成资源浪费。为此，DFSANN 先将搜索过程与 IO 过程进行解耦，再通过优化 IO 方案实现有效降本。一方面，通过减少 IO 次数和 IO 后的重排数据量来优化检索时间，另一方面，通过异步下放 IO 来减少总的 IO 时间：缓存 Graph 与部分 IO：将 Graph 缓存至内存，原始数据仍在底层存储中，在搜索过程中使用压缩向量进行快速检索，对近似距离进行排序，仅在结果重排阶段对最有可能的部分后续集进行 IO，从而降低少对磁盘的依赖。优化 IO 方案：边搜边 IO： 搜索中异步下发 IO 请求，获取全部候选集对应的精确向量，搜完后只计算部分候选集合的精确距离。该方法虽然需要全量 IO，但只计算部分集合，此外由于 IO 在搜索过程中下发，重排时无需等待，IO 的耗时开销几近于无。搜完再 IO： 在搜索过程中积累 IO 请求，搜索完成后，根据近似距离排序结果将部分更有可能是最终结果的候选集对应的 IO 请求一次性异步下发，并计算精确距离。该方案可减少 IO 量，但搜索耗时会稍高一些。进一步的成本优化：当前方案能够在较短的时间内实现较高召回率的检索。然而，受限于本地 SSD 的 IO 并发与图索引的构建成本，单机一般不会只构建一个大规模索引，导致单次检索产生巨大的 IO 开销。后续将采用预聚合（即，预先将部分点聚类成簇）的方式进一步降低存储成本和 IO 成本。性能表现在随机数据上的实验结果显示，DFSANN 的两套搜索模式都显著优于原始 DiskANN，特别当存储介质是 DFS 时，DFSANN 的吞吐显著优于 DiskANN。4. HGraph：适配通用场景，支持平滑切换的六边形战士背景与设计目的现有的向量算法往往针对特定的需求，只能做到部分场景的适配。如果伴随业务需求调整，需要切换算法，则算法之间的异构特性会导致切换难度大，同时切换后存在各种不确定性的隐患。HGraph 致力于实现一套支持多种场景并且可以平滑切换的索引。核心技术与实现方案HGraph 基于组件化的分层架构，弹性化各个向量检索组件（量化器，IO 模块，图结构模块等），部分组件支持可插拔能力，通过不同组件的配置支持广泛的业务场景，且几乎保持同等性能。HGraph的分层架构包括：基础的算子层：包括量化器算子，IO访问算子等，支持新型的量化算法变更，支持多种数据访问方式；数据组织层：提供算法核心能力，支持多种算法角度的数据结构管理、访问与计算能力；接口抽象层：屏蔽底层的数据结构细节，提供统一的访问接口；基础索引层：支持具体的索引算法结构，包含了构建、训练、检索的工作流，以及标签过滤、范围查询等特定功能。适配不同场景，HGraph 提供多种组装方案。例如纯内存场景、混合存储场景等，用户在使用上只需要修改配置参数即可实现不同索引类型，支持快速迭代落地。此外，HGraph 还在算法兼容和工程层面实现了多项优化。算法兼容方面已实现对 BSA、EnhanceGraph、DFSANN 等算法的兼容；工程层面，通过优化算子调用开销、SIMD 混合加速、预取优化等方案，实现了性能对标专业领域索引，甚至有所超越。典型场景配置HGraph支持大部分应用场景，覆盖不同数据规格，不同精度诉求，尤其是希望一套索引支持多个场景和具备平滑切换能力的场景。高性能，高精度场景（数据规模 1M-100M，内存资源充足，精度 99%+，性能要求高）：带重排和共轭图的纯内存方案；或单层 FP32 图，配合共轭图提升精度。低内存，高性能场景（数据规模 100M-10B，内存资源紧张，精度 96%-98%，性能要求高）。低成本，混合存储场景（数据规模 10B-1000B，内存资源十分紧张，精度和性能要求放宽）欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
贝叶斯不确定性引导的早停框架ESTune——OceanBase 校企联合研究
摘要：OceanBase联合河南师范大学软件学院与华东师范大学数据科学与工程学院撰写的ESTune论文被数据库领域顶级会议 SIGMOD 2026录用。通过对性能不佳的配置引入早停机制，ESTune 成功打破了迭代式数据库调优中的效率瓶颈。具体而言，ESTune 结合贝叶斯网络，利用部分执行数据（即分段性能指标）对低效配置的最终性能进行可靠预测。日前，由河南师范大学软件学院，华东师范大学数据科学与工程学院与OceanBase团队联合撰写的论文《ESTune: Bayesian Uncertainty-Guided Early Stopping for Database Configuration Tuning》被数据库领域顶级会议 SIGMOD 2026（Proceedings of the ACM on Management of Data）录用。SIGMOD 是 ACM 旗下的年度会议，是数据库领域公认的权威会议。本论文针对现有数据库旋钮调优方法效率低下的痛点，提出了一种基于贝叶斯不确定性引导的早停（即 Early Stopping）框架——ESTune 。该论文的录用，标志着数据库参数自动调优领域在效率提升上取得了突破性进展。该方法通过解决利用部分工作负载数据可靠预测低效配置性能的技术难题，成功在不牺牲调优有效性的前提下，显著加速了现有方法的调优效率。以下为论文介绍：问题尽管现有的自动化调优方法（如 OtterTune、HUNTER 等）能够实现数据库性能的显著提升，但它们普遍面临一个致命瓶颈：调优效率低下。这些方法在每轮参数性能评估时都需要完整运行整个工作负载，导致评估成本高昂且固定。而获取一个满意的参数配置通常需要数百次迭代，因此造成整体调优周期极为冗长，这样严重制约了自动化调优技术的实际应用和推广。目前的自动化参数通常采用全量评估模式（即为每个配置都完整运行整个工作负载）。然而这种评估模式存在固有的局限性与显著的改进潜力。该观点主要基于以下两个关键观察：1.探索与利用的权衡导致性能波动。调优过程中会产生大量性能不佳的配置，这些配置往往占据了大量的评估时间。2.对差配置的评估无需极其精确。对于表现极差的配置，即使评估存在一定误差（例如在 85%-115% 范围内波动），也不会影响最终调优结果的有效性。基于此，该论文提出了 ESTune，其核心理念是：对性能不佳的参数配置实施早停策略，即无需完整运行整个工作负载；随后，ESTune 利用可靠的预测性能替代这些早停配置的最终性能。通过这种方式，ESTune 不仅保证了调优的有效性，而且减少了不佳配置的评估时间，从而提升了调优效率。核心技术一：分段式性能监控与最优粒度切分工作负载通常被划分为基于时间和基于数量两种类型。基于时间的工作负载常见于具有大量短查询的 OLTP 场景。对于此类工作负载，ESTune 将其执行过程划分为固定数量的时间段，并记录每个段的性能指标。例如，对于一个总执行时长为 500 秒的工作负载 TPC-C，若其执行过程被划分为 10 个时间段，则收集器将在每 50 秒的时间间隔内记录一次吞吐量。基于数量的工作负载常见于查询数量较少但耗时较长的 OLAP 场景。对于此类工作负载，ESTune 会按预设的查询语句数量进行分段，并记录每个分段的性能指标。例如，对于一个由 22 个查询语句组成的工作负载 TPC-H，若其被分段为 22 个部分，则 ESTune 将记录针对每个查询语句的性能。核心技术二：基于混合贝叶斯神经网络的性能预测为了准确预测早停配置的数据库性能，ESTune 设计了混合贝叶斯神经网络（即HBNN），其整体架构如图 1 所示。具体来说，GRU 处理由段性能数据组成的数据序列。S1，S2，…，Sl。FNN 用来处理n个参数的取值 V1，V2, …，Vn。BNN 则结合了 GRU 和 FNN 的输出，并预测该配置性能的均值和方差。图1：HBNN的整体架构核心技术三：基于 MAML 的少样本快速适应技术由于数据库参数调优通常期望在短时间内获得满意的结果，因此只能进行有限次的迭代。然而，神经网络又通常需要依赖大量的训练数据来微调参数，以防止过拟合并实现良好的学习与泛化能力。为了应对这一挑战，ESTune集成了MAML（Model-Agnostic Meta-Learning）算法。该算法通过在历史调优任务上进行元训练，学习出一组优秀的初始化超参数。这使得 HBNN 能够快速适应新的调优任务，即使在“冷启动”场景下，也能通过少量迭代迅速收敛。性能成果论文在 MySQL 8.0 和 PostgreSQL 12.12 两个主流数据库系统上进行了广泛评估，使用了包括 TPC-C 和 TPC-H 在内的多种工作负载。实验对象涵盖了 BestConfig, OtterTune, HUNTER, LlamaTune (SMAC), OpAdviser, OBTune 和 GPTuner 等多种最先进的参数调优方法。实验对比了这些现有方法及其集成 ESTune 后的增强版本（即ES_*）的性能。图2、图 3 和图 4 分别展示了不同场景下的调优结果，实验数据一致显示：ESTune 大幅增强了这些基线方法的调优效率。图 2：MYSQL 在 TPC-C 工作负载上的调优结果图 3：MYSQL 在 TPC-H 工作负载上的调优结果图 4：PostgreSQL 在 TPC-C 工作负载上的调优结果小结与展望通过对性能不佳的配置引入早停机制，ESTune 成功打破了迭代式数据库调优中的效率瓶颈。具体而言，ESTune 结合贝叶斯网络，利用部分执行数据（即分段性能指标）对低效配置的最终性能进行可靠预测。未来的工作将围绕 ESTune 在复杂动态环境下的应用展开：一是探索框架负载漂移场景下的泛化能力；二是将其扩展至云原生数据库，以支持同时优化性能、成本和稳定性的多目标调优。欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
在 ClawdBot (MoltBolt / OpenClaw) 中增加记忆插件 PowerMem 的新方法
摘要：本文介绍如何为开源个人AI助手 Moltbot（原 ClawdBot）集成基于 OceanBase 技术栈的长期记忆插件 PowerMem。通过 HTTP API 对接，PowerMem 为 Moltbot 提供智能信息抽取、艾宾浩斯遗忘曲线调度及多智能体隔离的记忆能力，显著增强其上下文持久化与自主决策水平，实现更类人的“数字员工”体验。 Moltbot 是什么？Clawdbot（后更名为 Moltbot，又更名为 OpenClaw）是一款开源、以通讯为核心的AI智能体项目，运行在你自己的设备上，通过你已有的渠道（WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Teams、WebChat 等）和你对话，支持语音、Canvas、多代理路由等。 简单点说：Moltbot 最大的特点是不仅能回答问题，更能真正“动手”操作你的电脑系统，执行命令、控制浏览器、管理文件，就像一个 7 x 24 小时在线的 “数字员工”。 官网 ：https://www.molt.bot/github 地址：https://github.com/moltbot/moltbot Moltbot 部署方式一：NPM 全局安装方式二：源代码安装上面两种安装方式二选一，因为我是走的源代码安装：1. pnpm moltbot onboard --install-daemon 初始化2. 同意风险提示这里会让你确认风险。Moltbot 功能强大，能执行系统命令、读写文件、控制浏览器，但这也意味着如果配置不当或被滥用，可能会带来安全风险，请谨慎使用。3. 选择快速开始4. 配置 AI 模型授权，我手里头有qwen的5. 启动web问个小问题：“查一下我的电脑型号”，很快 moltbot 回复了我机器的具体型号，虽然任务非常简单，但是还是挺惊喜的，距离“贾维斯”又进了一步了。Moltbot 的原生记忆解读Moltbot 的持久记忆可以概括为：「Markdown 文件为单一事实来源 + 可选向量/混合检索」。 存储形态：纯 Markdown 文件 事实来源：模型「记得」的内容 = 写入磁盘的 Markdown；不依赖模型内部状态。默认布局（在 workspace 下，如 ~/clawd）：memory/YYYY-MM-DD.md：按日期的日志，仅追加；会话开始时读「今天 + 昨天」。MEMORY.md（可选）：长期、人工可维护的记忆；只在 main 私聊 session 加载，群聊不加载。 也就是说：短期、按天的记录 → memory/YYYY-MM-DD.md长期、精选事实 → MEMORY.md持久化完全靠「写进这些文件」，而不是靠对话历史本身。 写入时机与「记忆冲刷」（Memory Flush） 平时：模型通过 工具（如 write、edit）或技能，把要记住的内容写到 MEMORY.md 或 memory/YYYY-MM-DD.md。自动冲刷：当 session 快触发自动 compaction 前，Moltbot 会跑一轮 静默的 agent 回合，专门提醒模型「把该持久化的东西写进记忆文件」，并鼓励用 NO_REPLY 不回复用户，避免用户看到这次内部回合。触发条件由 agents.defaults.compaction.memoryFlush 控制，例如在「剩余 token ≈ softThresholdTokens」时触发；每轮 compaction 只做一次 flush，并在 sessions.json 里记 memoryFlushCompactionCount 等，避免重复。 相关代码在 src/auto-reply/reply/memory-flush.ts：shouldRunMemoryFlush()：根据当前 token、context 上限、reserve、softThreshold 判断是否该 flush。若 workspace 只读（如 sandbox workspaceAccess: "ro"），则不做 flush。 检索层：向量 + 可选 BM25 混合检索 数据流实现方式 插件控制：默认使用 memory-core 插件（可设 plugins.slots.memory = "none" 关掉）。工具：memory_search：对 MEMORY.md 和 memory/.md 做语义检索（按 ~400 token 分块、80 token 重叠），返回片段 + 文件路径 + 行号；可选开启 BM25 + 向量 的混合检索。memory_get：按路径（及可选 from/lines）读取 MEMORY 或 memory 下的文件片段，供在检索后精确拉取，控制上下文长度。向量索引：对MEMORY.md 和 memory/.md 建索引；索引按 agent 存于 ~/.clawdbot/memory/.sqlite（路径可配）。支持远程 embedding（OpenAI、Gemini 等）或本地模型（如 GGUF）；可选 sqlite-vec 做向量加速。文件变更有 watcher（debounce），索引异步更新；若 embedding 模型/端点等变化，会整库重建索引。 混搜权重分配最终分数的计算公式非常简单（src/memory/hybrid.ts）：这意味着：向量搜索和文本三七开：最终得分 = 0.7×向量分 + 0.3×文本分（归一化后），偏重语义。候选池放大 4 倍：先取 maxResults × 4 的候选再合并、排序、截到 maxResults，提高最终 Top‑N 质量。 Moltbot + powermem 方案有 PowerMem VS 没有 PowerMem集成 powermem 方案集成方式：已插件的方式进行集成集成方式：新增插件 extensions/memory-powermem，通过 HTTP 调用 PowerMem 已启动的 API 服务；不把 PowerMem 作为库嵌入 Moltbot 进程。部署：用户需单独启动 PowerMem（如 powermem-server --host 0.0.0.0 --port 8000 或 Docker），并在 Moltbot 配置中填写 baseUrl（及可选 apiKey）。 代码结构代码地址：https://github.com/ob-labs/moltbot-extension-powermem在 Moltbot Agent 里会暴露这些能力：memory_recall — 按查询搜索长期记忆memory_store — 写入一条记忆（可选是否智能抽取）memory_forget — 按记忆 ID 或按搜索条件删除 使用 powermem 插件 Step1: 前置条件 已安装 Moltbot（CLI + gateway 能正常用）PowerMem 服务：需要单独安装并启动（见下文两种方式，任选其一）若用 PowerMem 的「智能抽取」：需在 PowerMem 的 .env 里配置好 LLM + Embedding 的 API Key（如通义千问 / OpenAI） Step2：把本插件装进 Moltbot 在你本机执行（路径改成你实际克隆的目录）：安装成功后，可用 moltbot plugins list 确认能看到 memory-powermem。 Step3：配置 Moltbot 使用本插件 编辑 Moltbot 的配置文件（常见位置：~/.clawdbot/config.json 或项目里的 moltbot.json），在 根级 增加或合并 plugins 段，并把记忆槽指向本插件，并写上 PowerMem 的地址。 示例（JSON）：说明：baseUrl：PowerMem 的 HTTP 地址，不要加 /api/v1，就写 http://localhost:8000 或你的实际主机/端口。若 PowerMem 开了 API Key 鉴权，在 config 里增加 "apiKey": "你的key"。改完配置后重启 Moltbot gateway（或重启 Mac 菜单栏应用），配置才会生效。 Step4：验证插件与 PowerMem 连通 在终端执行：若输出里没有报错、能看到健康状态，说明插件已连上 PowerMem。 Step5: 测试手动写入 + 搜索 我们来简单测试一下,用手动写入验证数据库是否有数据 若搜索能返回刚写的那条（或类似内容），说明「安装 PowerMem → 安装插件 → 配置 Moltbot」全流程已打通。 下面是执行结果：看一眼数据库,妥妥的已经写入了 欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
摘要：浙大与 OceanBase 联合提出 DeepK 调试引擎，为 LLM-based 自动程序修复提供了一种全新的思路。通过将隐含在大规模 bug-fix 数据中的调试经验显式化、结构化并系统复用，有效弥补了现有方法过度依赖隐式推理的不足，引导大语言模型从“隐式猜修复”转向“基于经验的知识驱动调试”，显著提升了自动程序修复的准确性与稳定性。日前，由浙江大学与 OceanBase 团队联合撰写的论文：《Debugging Engine Enhanced by Prior Knowledge: Can We Teach LLM How to Debug?》被软件工程领域顶级会议 The ACM International Conference on the Foundations of Software Engineering (FSE) 2026 录用。FSE 是软件工程领域最具影响力的国际顶级会议之一，是中国计算机学会 CCF 推荐的 A 类国际会议。本论文通过系统化提取和复用结构化调试知识，引导大语言模型从“隐式猜修复”转向“基于经验的知识驱动调试”，显著提升了自动程序修复的准确性与稳定性。简介随着大语言模型在代码理解与生成领域能力的不断增强，自动程序修复（Automated Program Repair，APR）逐渐成为软件工程研究的重要方向。近年来，大量工作尝试通过提示工程、多智能体协作、示例检索或执行反馈等方式提升修复效果，并在多个基准数据集上取得了可观进展。然而，这些方法大多仍然依赖模型的隐式推理能力：模型需要从原始示例、上下文或运行结果中自行推断调试思路，而调试过程中真正稳定、可复用的知识却并未被显式建模和系统利用。论文 DeepK（Debugging Engine Enhanced by Prior Knowledge）正是针对这一核心缺陷提出了解决方案。作者指出，大规模 bug-fix 数据集中蕴含着丰富的调试经验，但现有方法通常只将其作为上下文示例或推理演示使用，而没有将其中的调试逻辑提炼为结构化知识。DeepK 通过系统性地提取、验证并复用调试知识，为大语言模型提供明确的调试指导，使程序修复从“依赖模型临场发挥”转向“基于经验的知识驱动推理”。核心理念：让调试从隐式推断走向显式知识引导传统的 LLM-based APR 方法在设计上存在一个根本矛盾：一方面希望模型具备类似人类的调试能力，另一方面却很少向模型明确提供“人类是如何调试的”。模型虽然可以在大量示例中隐式学习模式，但这种方式缺乏稳定性、可解释性，也难以在分布外场景中保持鲁棒。DeepK 的核心理念在于，将调试视为一种可总结、可验证、可复用的知识过程。它不再把修复行为简单等同于补丁生成，而是将调试拆解为两个紧密协同的部分：对错误根因的理解，以及围绕该根因展开的修复策略。通过显式建模这两类调试知识，DeepK 试图为大语言模型提供类似“资深程序员经验”的指导，使其在面对新 bug 时能够遵循已有的成功调试路径进行推理，而非从零开始试探。图 1. DeepK 的 4 阶段架构核心技术一：基于 AST 的编辑描述生成与调试语义对齐在从历史 bug-fix 数据中提取调试知识时，一个关键挑战在于如何避免被低层次的代码差异所干扰。直接对比 buggy 与 fixed 代码往往会产生大量琐碎、语义不明确的修改信息，难以反映真实的调试逻辑。为此，DeepK 引入了一种基于抽象语法树的编辑描述生成机制，将代码层面的差异转化为人类可读、具有步骤感的自然语言编辑描述。该机制通过分析两版代码的 AST 结构，定位真正与错误修复相关的修改位置，并过滤掉不合理或无关的编辑操作，从而生成更符合人类调试习惯的修改描述。这一过程有效弥合了“代码补丁”与“调试思维”之间的鸿沟，为后续调试知识的抽取提供了清晰、语义化的输入。图 2. 代码编辑描述生成工具核心技术二：结构化调试知识的抽取、验证与知识库构建在获得编辑描述后，DeepK 进一步引导大语言模型围绕“如何定位并修复该 bug”生成结构化调试知识。模型需要明确指出错误的根因，并给出一步步的调试与修复策略。与以往方法不同的是，DeepK 并不直接接受模型生成的结果，而是引入了验证机制：模型必须仅基于自己生成的调试知识重新修复程序，并通过测试用例验证其正确性。只有能够稳定指导修复成功的知识，才会被纳入最终的调试知识库。在知识组织层面，DeepK 采用多视角索引策略，从任务描述、程序结构以及执行轨迹等多个维度刻画每一条调试知识，使其能够在面对不同类型的新 bug 时被准确检索。这种多维度设计避免了单一相似度度量带来的偏差，使知识检索既具备语义相关性，又保留结构与运行层面的信息。图 3. 结构化调试知识抽取核心技术三：先验调试知识增强的程序修复流程在实际修复新 bug 时，DeepK 并不替代现有 APR 系统，而是以“调试知识增强模块”的形式融入其中。当系统接收到新的 buggy 代码后，会从知识库中检索出最相关的调试知识，并将其注入模型的推理阶段，引导模型围绕已验证的调试思路展开修复。这种设计使 DeepK 能够自然地与不同类型的 APR 系统集成，无论是基于提示与检索的非智能体方法，还是基于脚本化流程的修复框架，都可以从中受益。通过这种方式，程序修复过程不再依赖单次推理的偶然成功，而是建立在大量历史调试经验的积累之上，使模型的行为更加稳定、可解释。性能成果在 ACPR 与 AtCoder 等多个基准数据集上的实验结果表明，DeepK 在不同模型后端（GPT-4o与 DeepSeek-v3）下均能显著提升现有方法的修复准确率。在分布内场景中，DeepK 相较最强基线方法取得了稳定的绝对提升；在更具挑战性的分布外竞赛编程任务中，其相对提升尤为显著，显示出结构化调试知识在应对分布偏移时的独特价值。图 4. DeepK 与其他基准方法的对比进一步的消融实验验证了各个设计组件的重要性。结果显示，对调试策略的显式建模对性能提升贡献最大，多维度检索机制显著增强了系统的鲁棒性，而基于 AST 的编辑描述在复杂程序修复中发挥了关键作用。同时，实验还揭示了调试知识数量与性能之间的权衡关系，表明适量、精准的知识注入比简单堆叠上下文更加有效。图 5.知识库索引构建的消融实验图 6. 结构化调试知识的消融实验图 7. 代码编辑描述工具的消融实验图 8. 调试知识数量与调试性能的关系结语DeepK 的工作为 LLM-based 自动程序修复提供了一种全新的思路。通过将隐含在大规模 bug-fix 数据中的调试经验显式化、结构化并系统复用，该框架有效弥补了现有方法过度依赖隐式推理的不足。在实践中，DeepK 在多种数据分布与模型设置下均展现出稳定的性能提升，并显著增强了修复过程的可解释性与鲁棒性。这项研究表明，相比不断扩展模型规模或复杂化推理流程，让模型掌握可复用的调试知识可能是一条更加稳健、可持续的路径，也为未来构建更可靠的软件智能系统奠定了坚实基础。欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
中国联通软研院基于OceanBase引领运营商数智化转型新范式
摘要：中国联通使用的传统集中式数据库面临高并发、扩展难、运维复杂等痛点，于是其与 OceanBase 构建“企业版核心承载 + 社区版自主创新” 双轨体系，现已全面覆盖联通 B 域（业务支撑）、O 域（运营支撑）、M 域（管理支撑）全场景。其中，OceanBase 企业版攻克运营商最核心的B域40% 生产系统，支撑全球最大规模 “全国大集中” 核心业务。当超 4 亿用户的通信消费、5G 服务、政企业务全部汇聚于 “全国一套系统”，当传统数据库的性能瓶颈，遭遇数字时代的 “数据海啸”，自研数据库如何扛起全球最复杂的电信核心业务？近日，中国联通软件研究院（简称 “联通软研院”）与 OceanBase 的四年深度合作交出了震撼行业的答卷：双方打造的 “企业版核心承载 + 社区版自主创新” 双轨体系，已全面覆盖联通 B 域（业务支撑）、O 域（运营支撑）、M 域（管理支撑）全场景，累计部署节点超 1000个。其中，OceanBase 企业版攻克运营商最核心的 B 域 40% 生产系统，支撑全球最大规模 “全国大集中” 核心业务；基于OceanBase 社区版自研的 CUDB 数据库规模化上线数百套系统，更以 AI 向量数据库创新应用 ChatDBA，为运营商智能化转型提供了可复用的创新方案。这场合作见证了自研数据库技术从 “入局” 到 “破局” 再到 “引领” 的华丽转身。破局 “全国大集中”：超 4 亿用户核心系统的分布式升级革命在电信行业 “省集中” 为主流的格局下，中国联通率先推行 “全国大集中” 战略，以一套 cBSS 系统承载 31 省全业务、全客户、全渠道服务，支撑超 4 亿用户的 CRM、计费、结算等核心场景 —— 这是全球电信行业单体承载用户最多、集中化程度最高的业务支撑系统，其技术升级难度堪称 “在飞行的飞机上换引擎”。此前，该系统长期依赖传统集中式数据库，即便后续升级为 “中间件 + 数据库” 架构，仍面临高并发性能瓶颈、扩展性不足、运维复杂等致命痛点：月初缴费高峰时 “一省慢、全国卡”，5000 万用户基数就触达集中式数据库性能上限；31 省业务 “共性收敛与个性保留” 难以平衡；复杂存储过程与多数据库类型导致升级改造难如登天。OceanBase 的分布式架构成为破解困局的关键。作为 “全国电信唯一大集中核心业务支撑系统国产升级” 案例，OceanBase 企业版通过三大核心能力实现突破：一是 “两地三中心” 部署模式，以Paxos 协议分布式一致性机制，实现 RPO=0（数据零丢失）、RTO<30秒的金融级容灾，相比传统集中式数据库的主备架构，容灾建设成本降低 50% 以上，支撑核心业务全年 7×24小时无间断运行；二是多租户弹性扩缩容技术，将全国上千个节点物理资源池化，按业务需求动态分配 CPU、内存、IO，彻底解决资源争抢问题，计费中心查询性能提升 60%，政企中台并发处理能力翻倍，资源利用率从不足 40% 跃升至 80% 以上，硬件成本降低 60%；三是深度兼容特性，完美适配 MySQL 与 Oracle 语法，让复杂存储过程、冷僻 SQL 语句无需大幅改写，实现 ERP 系统零改造平滑升级，B 域核心系统整体升级改造成本降低 70%。更具创新性的是，基于 OceanBase 多租户能力构建的 “一库多服” 架构：通过镜像库将 10 余个业务中心的高负载查询请求从生产库剥离，既保障 “全国一套账” 的统一管理，又能灵活响应各省 5G 用户增长分析、政企客户关联图谱等个性化需求，仅用 1 周就完成所有数据库升级同步，成为支撑业务运营的数据枢纽。自主创新加码：CUDB 引领开源生态规模化落地在核心业务升级的同时，联通软研院并未止步于 “使用者” 角色，而是向 “开发者”“创新者” 转型。2021 年 OceanBase 开源后，联通软研院仅用 13 个月就完成社区版深度优化，打造出分布式 HTAP 数据库产品分布式 CUDB，成为基于 OceanBase 社区版的最大规模应用案例。截至 2025 年 6 月，分布式 CUDB 已承载数百个业务应用，部署节点超 200 个，管理原始数据量近 300TB，广泛覆盖 O 域、M 域各类场景。为解决传统 MySQL 多版本分散、升级低效的痛点，自研 MySQL 与分布式 CUDB 双向数据迁移工具，实现 10 万条 / 秒的升级速度 —— 这是社区版 OMS 的 3 倍、同类产品 DataX 的 5 倍，已累计完成 25TB + 数据升级，兼容性与效率均处于行业领先水平。同时，分布式 CUDB 全面接入联通云，实现 “一点开通、一点交付、一点监控、一点运维、一点操作” 的一站式服务，大幅提升云租户使用体验与运营效率。更值得关注的是，联通软研院在合作中累计向 OceanBase 开源社区贡献代码超万行，输出数据库事务日志精准恢复、云存储备份对接等核心能力，实现 “使用开源、贡献开源” 的良性循环，推动数据库生态协同进化。AI + 数据库融合：ChatDBA 树立智能化转型新范式2025 年，AI 成为数字化转型的核心驱动力，中国联通软研院聚焦 AI 向量数据库等前沿领域，基于 OceanBase 完成数据库智能专家 ChatDBA 的底层架构升级，破解了大模型落地的关键痛点。作为基于 RAG（检索增强生成）技术构建的 AI 应用，ChatDBA需整合海量数据库专业知识与运维经验，传统架构存在扩展性不足、运维复杂、资源利用率低等问题。经过对主流向量数据库的全面测评，OceanBase 的一体化能力脱颖而出：其支持关系型数据、向量数据等多类型数据混合存储查询，可处理最高 16000 维稠密向量，在 768 维 100 万数据集下检索性能是主流向量数据库的 3-6 倍；分布式架构保障高并发与故障自动恢复，多租户技术实现资源隔离，搭配完善的管控与迁移工具，大幅降低运维成本。依托这些优势，ChatDBA 仅用两周就完成适配改造，硬件资源成本直降 30%，运维人力成本同步降低，问题解决效率显著提升，成为运营商领域 “AI + 数据库” 深度融合的标杆范例。从核心业务分布式升级的 “破冰”，到开源生态自主创新的 “深耕”，再到 AI 一体化架构的 “引领”，中国联通软研院与 OceanBase 的合作不仅实现了量化的降本增效，更构建了 “自主创新、安全稳定、智能高效” 的数字基建新范式。联通软研院相关负责人表示，未来将持续扩大合作范围，深化向量数据库、多模数据融合等领域创新。OceanBase 也将以此次合作为基础，持续迭代升级，适配电信行业核心需求。这场跨越四年的深度合作，不仅为中国联通 “数字服务使能者” 转型筑牢技术底座，更向全行业证明：自研数据库已具备支撑全球最复杂核心业务的能力。这一点在 OceanBase 过去五年的实践中得以充分验证：自 2020 年商业化以来，OceanBase 已在运营商领域实现从“点上突破”到“面上开花”的转变，深度服务中国联通、中国移动、中国电信三大运营商，覆盖 B/O/M 全业务域。在今年 9 月举行的中国通信展上，凭借在通信行业扎根沉淀的实践优势和技术创新能力，OceanBase 联合运营商打造的五个标杆案例获得由中国通信企业协会评选的“一等案例”荣誉。这些成绩的背后，是 OceanBase 作为运营商“可信赖基石”地位的奠定。当每一通电话、每一笔交易、每一次 AI 交互都运行在自主研发的数据库上，我们看到的不仅是技术自立自强的硬核实力，更是数字化的坚实底气 —— 自研数据库正在从幕后走向台前，重新定义数字时代的数据库核心标准。欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
爱奇艺基于OceanBase实现百亿级卡券业务的“单库双擎”架构升级
摘要：爱奇艺卡券业务原采用 “MySQL 分库分表 + ES 异步同步” 架构，面临 TP/AP 分离导致的架构复杂、AP 查询分钟级延迟、数据一致性隐患等问题。如今借助 OceanBase 的 HTAP 能力，将 AP、TP 业务融合到一个数据库，在架构简化、成本控制与效率提升方面均取得了突破。爱奇艺是国内知名的在线视频平台，每年都会推出上百部优质长视频内容，其中不乏如 2023 年现象级爆款《狂飙》这样的佳作。近两年，随着短视频、微剧的兴起，平台年处理视频内容数量级从上百部直接跃升至上万部。每一部内容从立项、拍摄、生产、制作到上线播出，均需经过复杂流程，并依赖上百个业务模块协同支持。卡券业务是出于整个业务生态里面的中台位置，对上提供中台能力，如为创新型业务会员、云影院提供商业化变现和用户转化营销工具。过去，卡券业务系统将 AP（分析处理）与 TP（事务处理）业务分开处理，架构复杂，需要较高的维护成本；如今，借助 OceanBase 的 HTAP 能力，将 AP、TP 业务融合到一个数据库，在架构简化、成本控制与效率提升方面均取得了突破。解构卡券业务的数据架构困境卡券是爱奇艺核心的营销与促销工具，贯穿爱奇艺的会员购买、云影院观影等商业化变现全链路。其底层数据库的性能直接关乎用户体验与业务敏捷性。例如，促销发券、会员领券等场景均需要业务系统提供高并发事务处理（TP）能力。而在运营侧，则需要实时统计和分析发券数量、会员领券等指标，以便评估活动效果、优化营销策略，这依赖于高效的数据分析（AP）能力。过去，卡券业务系统采用的是“MySQL 分库分表+ES 异步同步”的复杂架构：分库分表的 MySQL 来承载 TP 业务，以应对高并发海量请求；Elasticsearch（ES）来完成统计分析等 AP 类业务。“这个卡券业务的架构基本上能为业务需求提供足够的支撑。不过，我们并不满意，一直在寻找新的解决方案。”爱奇艺高级总监张冲表示。其最重要的原因就在于系统架构过于复杂，虽能满足业务需求，但每一个节点都需要研发投入大量精力维护，顶峰的时候研发资源占比近 80%，严重挤占了业务创新资源。具体而言，在 TP 业务方面，通过分库分表的 MySQL 集群支撑高并发交易，但实际日常资源利用率仅约 10%，资源冗余明显。在 AP 业务方面，ES 进行运营统计分析时的数据源自订阅多个 MySQL 实例的 binlog，经消息队列 RMQ 异步同步至 ES，链路冗长，存在分钟级延迟。并且 ES 的清理归档代价较高，Reindex 开销也比较大。此外，数据的一致性与准确性面临挑战，在异步同步过程中，甚至出现过 UV（访客数量）超过页面点击的异常，统计准确率难以保障。张冲坦言，对现有架构进行升级更深层的原因，源于对技术进步的持续追求。“我们希望技术上再往前走一走，要和互联网行业最先进的技术保持对齐。”从“分库分表+ES”到“单库双擎”，爱奇艺 HTAP 架构升级实践随着新技术趋势的出现，爱奇艺也开始寻找能够简化架构、支撑业务更好发展的新发展。数据库的升级是这次架构升级的关键。对于新一代数据库，爱奇艺提出了明确的要求：第一，必须是一款兼顾 TP、AP，具备 HTAP 能力的数据库产品，无需管 MQ，无需处理异构的数据，尽量减少对数据平台的依赖，以简化数据底座；第二，总体成本可控，和现有架构相比成本不能上升，符合公司降本增效的目标；第三，云中立，在遇到故障的时候可以实现云逃逸，且在不同的云上均可提供一致性的服务。根据上述三个基本要求，经过对多款主流数据库产品的调研与测试，OB Cloud 一体化云数据库凭借其卓越的性能与高度契合的需求满足度，赢得了爱奇艺的青睐，并且在高并发、高可用、安全、数据治理、低成本等方面的技术积累，都被浓缩到 OB Cloud 一体化云数据库的产品中。张冲表示：“OceanBase 不仅提供了真正的 HTAP 融合能力，其原生分布式架构还与我们的云原生战略高度契合。同时，OB Cloud 在百度云上开服也是一个重要契机，因为爱奇艺的系统平台就部署在百度云上。”完成数据库选型之后，爱奇艺迅速开始了数据和架构升级的准备工作。升级工作分为两个阶段：AP 升级：将 ES 集群中的百亿文档升级至 OB Cloud 集群。通过双写、迁移历史数据、切读、停双写等步骤，不仅完成数据升级，还从业务层面进行了逻辑去冗余和简化。最终，资源成本下降 60%，运营查询类 SQL 基本在 1 秒内返回。TP 升级：将 16 个物理机数据库从原生 MySQL 分库分表形态升级至 OB Cloud 集群。借助 OceanBase 的 OMS 同步工具，顺利完成海量数据同步与校验工作。最终，存储成本下降 80%，且系统具备弹性伸缩能力，无需为大促提前预备资源。张冲表示，为了尽量减少对业务的干扰，保持业务稳定性，升级过程尽可能少地修改代码，他们采取了一些措施：汇聚到 OceanBase 的分区表、分区键与原来的分片逻辑一致，使得业务系统零改造切换；保持 AP 业务不变，仅修改数据源订阅，通过全兼容的 binlog 直接订阅到同租户的 AP 表。此时还是多份存储，但依靠高压缩比，整体存储成本没有上升；将 TP 业务的表异步修改为行列混存，不影响业务稳定性，同时运营统计只需简单修改库和表名即可快速上线。通过多副本读写分离，最终实现了单库双擎、支撑实时在线业务与数据分析的简洁架构。化繁为简，打造卡券业务的现代化数据库底座经过升级改造后，卡券业务系统架构变得非常简洁，只有基本的业务服务和数据中台的数据交互，不再需要维护额外的数据流服务，也无需担心存储不足等问题，归档清理的周期也相应延长，研发人员得以更加聚焦于业务需求的开发。张冲表示，卡券业务系统架构升级带来了如下好处：首先，链路极大简化。 去除了 MySQL 到 ES 的异步同步链路，消除了 ES 集群的运维与成本；张冲特别感慨此次架构的升级带来的简化，他表示“简单到只有计算、只有存储，简单到有点像互联网刚开始发展的那个阶段。”其次，分析效率提升。 常规 AP 查询可直接在 OB Cloud 中完成，时间也从原来的准实时变成了实时，所有统计 SQL 的响应时间（RT）均小于 1 秒，性能大幅提升。而 BI 类需求以前需要数据中台部门支持，属于跨部门协作，最快也需数天；现在本部门内部就能完成，时间缩短为 2-3 天；第三，存储成本显著节省。 借助 OceanBase 的高压缩能力，相比 MySQL 的存储成本下降了 80%，并且它可以弹性伸缩，不再需要提前为大促预备过量资源。“相对于之前的架构，现在的架构非常简洁。这要得益于 OceanBase 把高并发、高可用、安全、数据治理、低成本等各种技术积累都浓缩到了这个数据库产品中。”张冲这样评价。小结张冲表示，未来爱奇艺计划将 OceanBase 的实践推广至更多在线交易型业务，如订单支付、会员中心等，并逐步探索其在 KV 存储、向量检索等场景的应用。面对 AI 浪潮，张冲也提出了对未来数据库的期待：“知识图谱、AI 工作流等复杂场景，需要更智能的底层数据支撑。希望 OceanBase 能在这些方向持续演进，成为企业智能化转型的数据基石。借助 OceanBase 技术的不断完善和应用场景的拓展，爱奇艺将在科技创新的道路上走得更远。”欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
主流关系型数据库系统缺陷实证研究——OceanBase 校企联合研究
摘要：OceanBase联合中国人民大学数据库团队的数据库缺陷实证研究，被软件工程顶刊IEEE TSE录用。该研究首次构建了面向开源关系型数据库的细粒度缺陷分类体系，共获得12 项发现，为RDBMS系统的开发维护和测试提供了重要启示。研究发现，涉及SQL数据类型及数据库触发器、存储过程、参数设置等复杂功能的缺陷现有测试工作无法有效触发，这一发现为提升RDBMS缺陷检测能力提供了显著改进空间。日前，由 OceanBase 联合中国人民大学数据库系统研究团队（刘爽副教授）对主流关系型数据库系统缺陷开展的实证研究《A Comprehensive Study of Bugs in Relational DBMS》被软件工程领域顶级期刊 IEEE Transactions on Software Engineering(TSE) 正式录用。IEEE TSE 是 IEEE 旗下软件工程方向的权威期刊。在数据库缺陷实证研究方面，本论文首次系统分析了 MySQL 等三个开源数据库中 777 个真实缺陷，揭示了 RDBMS 的缺陷在根因、表症等方面的特点，以及现有测试工具在深层语义缺陷检测上的局限性。以下为论文介绍。简 介本研究通过“系统性实证分析”揭示主流关系型数据库在真实场景中的缺陷规律。研究覆盖 MySQL、SQLite 和 openGauss 三大系统中 777 个高质量修复缺陷，深入剖析其根本原因、症状表现、分布特征及其关联性。其核心贡献在于：首次构建了面向开源关系型数据库的细粒度缺陷分类体系，研究共获得 12 项发现，为 RDBMS 系统的开发维护和测试提供了重要启示。研究发现，涉及 SQL 数据类型及数据库触发器、存储过程、参数设置等复杂功能的缺陷现有测试工作无法有效触发，这一发现为提升 RDBMS 缺陷检测能力提供了显著改进空间。方法与分类体系表1：采集 bug 的统计信息本研究通过一套严谨的实证方法对关系型数据库中的真实缺陷进行系统性分类与归因。围绕三个核心维度展开：根因、症状和修复模块。研究团队从 MySQL、SQLite 和 openGauss 的官方仓库中收集了 2018 至 2023 年间报告的 2495 个缺陷，经过严格筛选后构建了一个高质量的 777 个缺陷数据集。在此基础上，作者提出了一套四维分析框架：根因维度识别出 12 类根本问题（如错误逻辑、API 误用、类型处理缺陷等）；症状维度归纳了包括错误结果、崩溃、死锁、性能退化等行为；模块维度定位缺陷修复位置（如解析器、优化器、执行引擎、存储层等）；关联性进一步探索三者之间的关联规律，例如“类型相关根因多导致错误结果，且集中于表达式求值模块”。为确保标注一致性，两名研究人员独立完成全部标签分配，并通过 Cohen’s Kappa 系数评估达成共识。该方法不仅保证了分析的客观性，也为后续数据库测试工具的设计提供了可操作的指导依据。结果与分析研究揭示了多项关键发现。首先，在根因分布上，“不正确的代码逻辑”占比最高达 32.3%，“类型处理缺陷”和“API 误用”分别以 9.0% 和 8.4% 的比例成为第二、第三大类根因。其次，在症状表现方面，“结果不一致”是最普遍的症状，占全部缺陷的 42.99%，且往往无崩溃、无报错，具有极强的隐蔽性。图1：按根本原因划分的缺陷分布进一步的跨系统对比显示：MySQL 与 SQLite 在缺陷模式上高度相似，而 openGauss 因架构差异与活跃开发状态，表现出显著不同的缺陷谱系。这些结果不仅刻画了数据库内核的脆弱面，也为未来高可靠数据库的设计与质量保障工作指明了方向。图2：症状与根因的关系概念验证工具 SQLT研究中观察到类型相关缺陷在数据库 bug 中占比显著，团队开发了一个概念验证工具 SQLT，用于针对性挖掘此类问题。SQLT 强化了对跨数据类型表达式、隐式类型转换以及非标准类型（如 BIT、JSON）组合的查询生成能力。该工具通过比对语义等价查询的执行结果，能够有效识别那些不触发崩溃但返回错误结果的静默逻辑缺陷。在实验中，SQLT 不仅成功复现了多个已知类型 bug，还新发现 8 个此前未被报告的问题，其 5 个已被 MySQL、SQLite 和 openGauss 官方确认并修复。表2：SQLT检测到的缺陷欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
基于分层协作多智能体的数据库参数调优——OceanBase 校企研究
摘要：OceanBase联合成都信息工程大学的数据库缺陷实证研究，被软件工程顶刊IEEE TKDE录用。研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题，提出一种分层协作的多智能体框架，通过创新的训练机制与协同策略，有效破解传统调优方法的瓶颈，为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。近日，成都信息工程大学与 OceanBase 研发团队合作完成的研究《CMA+DB: How to Automatically Tune Database Parameters through Collaborative Multi-Agents》，被《IEEE Transactions on Knowledge and Data Engineering》（TKDE，CCF A 类、SCI 一区）录用。研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题，提出一种分层协作的多智能体框架，通过创新的训练机制与协同策略，有效破解传统调优方法的瓶颈，为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。以下为论文介绍：研究背景与挑战随着分布式与云计算技术的发展，数据库工作负载日趋多样化、复杂化。从高并发的在线交易场景（TPC-C），到随机读写的云服务场景（YCSB），再到高实时性的社交互动场景（Twitter），不同场景对参数配置的需求差异显著。传统调优方式逐渐难以适配这些实际需求：人工调优高度依赖 DBA 的专业经验，不仅需要耗费大量时间梳理参数关系，而且无法应对动态变化的工作负载，往往出现 “调优即过时” 的问题；搜索式调优方法依赖启发式规则，在简单场景下表现尚可，但面对多参数交互的复杂场景时，搜索空间急剧扩大，调优效率大幅下降；贝叶斯优化方法需要手动筛选关键参数，若参数定义不全面，难以找到最优配置；现有强化学习调优方法多采用单智能体设计，仅能对参数进行粗粒度调优，无法充分挖掘不同类型参数间的深层交互影响，调优精度和泛化能力受限。如何实现参数调优的自动化、精准化与高效化，成为数据库领域亟待解决的关键问题。图1 数据库参数调优主要步骤核心理论创新：CMA+DB 多智能体协作框架CMA+DB 框架以 “分类协作、分层训练” 为核心设计理念，构建了三级递进式训练机制，整合单智能体预训练模型 SAPM、多智能体联合训练模型 MATM 与基于概率选择的联合训练模型 PJTM，既保障了单个参数类别内的调优深度，又实现了跨类别参数的协同优化。三个子模型并非孤立存在，而是以级联方式递进工作，前一阶段的训练成果直接作为后一阶段的输入，形成 “基础专精—交互探索—精准强化” 的完整调优链路，确保框架在参数交互捕捉、调优效率与泛化能力之间实现最优平衡。图2 CMA+DB 模型工作原理在技术实现上，CMA+DB 基于深度确定性策略梯度（DDPG）与多智能体深度确定性策略梯度（MADDPG）构建核心算法架构，采用 Actor-Critic 网络结构实现智能体的决策与优化。每个智能体都具备独立的观测空间与动作空间，通过与数据库环境的持续交互获取反馈，不断优化参数调优策略。图3 多智能体 Actor 和 Critic 网络结构在第一阶段，提出单智能体预训练模型 SAPM。训练初期，每个 Agent 负责调优一类功能或参数级别相似的参数，目的是探究单个 Agent 对数据库性能的影响，进而优化其网络，使得其神经网络偏向于调节重要参数。该过程 Agent 之间相互不影响。与传统的单智能体模型相比，SAPM 模型的优点在于更深入地探究相似参数之间的关系，也更容易识别出一些重要参数。这一阶段对于识别关键参数和实现快速收敛至关重要。通过使智能体能够初步掌握参数调整策略，SAPM 为后续更复杂的多智能体训练奠定了坚实的基础，并减少后续阶段的耦合干扰，从而提高了整体效率和效果。在第二阶段，提出多智能体联合训练模型 MATM，在 MATM 模型训练阶段，使用组合算法将多个 Agent 的预测动作组合并映射为一组数据库的推荐配置，要求 Agent 之间不能存在相同的数据库参数。这种协作方法不仅增加了可调参数的数量，还显著增强了模型的表现力和调整能力。此阶段虽然存在耦合，但通过联合训练，能够让智能体逐步适应彼此的行为模式，实现协同优化。在第三阶段，提出了联合动作概选模型 PJTM，在 SAPM 和 MATM 模型训练之后进行训练，算法为每个 Agent 设置了一个概选因子 Pi， Agent 根据 Pi，随机地参与联合动作推荐。当一个 Agent 控制的数据库参数对数据库性能的提升微乎其微时，就可以根据 Pi 减小该 Agent 的动作参与，进而降低其对其它 Agent 所做动作的负面影响。这一机制有效减少了低影响智能体对整体调优过程的干扰，缓解了耦合带来的负面影响。基于上述三种方式，提出协作型多智能体模型 CMA+DB，其整合 SAPM、MATM 和 PJTM 模型进行分阶段训练，实现分功能、分级别地对数据库参数进行调优。探究了相同类型参数之间的相互影响以及不同类型参数之间的协作关系。有效地解决了离散环境和异步反馈的挑战，确保多个智能体的动作是协调的，并针对数据库性能进行了优化，提高了数据库参数的调优数量，提升了数据库参数调优的效率。关键验证成果相关研究成果已在 PostgreSQL 数据库环境下，在 TPC-C、YCSB、Twitter 三种典型工作负载上，与主流调优方法进行全面对比验证，核心性能指标表现突出且稳定。在调优效率方面，CMA+DB 的收敛速度优势显著。在 TPC-C 高并发交易场景中，这一优势尤为明显，CMA+DB 的平均收敛速度（达到最大吞吐量时）优于其他三种算法。能帮助数据库更快脱离性能波动期，进入最优稳定状态，大幅缩短调优耗时，降低系统上线或扩容后的性能适配成本。在性能提升方面，CMA+DB 展现出持续优化的能力。经过 SAPM 预训练后，框架的吞吐量已优于现有部分主流方法；后续经 MATM 的跨类别参数协同优化，以及 PJTM 的精准强化，在 TPC-C 场景下，其延迟显著低于 OtterTune、CDBTune+ 等方法，有效保障了系统在峰值压力下的响应稳定性，避免了因参数配置不当导致的延迟突增问题。在泛化能力方面，CMA+DB 表现出极强的适应性。实验结果表明，不同参数规模与智能体数量的组合测试显示，CMA+DB 能够根据实际场景灵活调整，无需人工干预即可适配不同规模的数据库参数调优需求，解决了传统方法在参数规模变化时泛化能力下降的问题。总结与展望作为一种兼具理论深度与工程价值的数据库参数自动调优方案，CMA+DB 框架通过多智能体分类协作与分层训练的创新设计，有效解决了传统方法在参数交互探索、调优效率与泛化能力上的短板，为 AI 赋能数据库优化领域提供了新的技术思路。该框架的核心优势在于，不但实现了参数调优的自动化与精准化，而且无需依赖大量人工干预与领域知识，降低了数据库性能优化的门槛，具备较强的应用价值。未来研究将进一步优化框架结构，通过算法改进降低计算复杂度，提升框架在超大规模参数场景下的运行效率；同时，将尝试适配 MySQL、OceanBase 等更多主流 DBMS，针对不同数据库的内核特性调整智能体的参数分类与协作策略，推动相关技术在金融、电商、社交等实际生产环境中的广泛应用，为数据库系统的性能优化提供更高效、更通用的解决方案。欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/
【文档悬赏令】第2号：数据库巡检手册征集，上传文档赢好礼！
墨天轮社区举办的 【文档悬赏令】系列活动，每次聚焦一个主题，征集真实、可操作的第一手文档，希望能扩充社区文档资源、为更多人提供有用的参考资料，让技术学习少走弯路！第2号悬赏令活动主题：数据库巡检方案实践数据库巡检是保障业务稳定运行的核心运维环节，更是DBA日常工作的重中之重。当前数据库类型、场景十分丰富，多数从业者需耗费大量时间整理巡检清单、调试巡检流程。墨天轮社区第二期【文档悬赏令】活动特围绕这一主题发起有奖征集活动，诚邀您上传实用、可落地的数据库巡检文档，和社区众位DBA们互帮互助，让巡检工作更高效、更标准！一、活动时间2026 年 1 月 26 日 - 3 月 28 日二、文档要求1、主题范围本次征集聚焦 “数据库巡检” 核心主题，覆盖国内外主流数据库，基础巡检、专项巡检、自动化巡检等多类实用方案等均可，具体范围如下：巡检主题细分（包含但不限于）：基础巡检：日常运维巡检表/巡检清单/巡检手册专项巡检：性能监控与优化巡检/灾备状态巡检/单机or集群巡检方式：手动巡检标准化文档/自动化巡检/脚本命令/巡检工具数据库不限：商业数据库：Oracle、SQL Server等国产数据库：达梦DM8、人大金仓KingbaseES、OceanBase等国产库开源数据库：MySQL、PostgreSQL、Redis等开源库2、合格要求与格式文档内容需明确巡检目的、适用场景、巡检流程等，包含巡检相关代码（部分敏感信息可隐去）。页数要求：≥5 页必加标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签支持格式：优先推荐 .doc、.pdf、.ppt、.md、.txt 格式（可支持前 5 页预览，下载率更高）；也可上传 .zip （需附内容说明）；以下文档将被判为不合格：1）主题无关：非“数据库巡检”相关主题2）内容搬运：直接上传电子书或产品官方文档、他人演讲PPT，或直接复制抄袭、全文搬运网站其他文章/文档内容（已发布的文章内容不可以同时上传成文档参与活动，但如果是您曾发在其他网站的内容则可以上传参与）3）流水账或凑字数：文档页数需≥5页，但不可通过凑字数、使用大量无关图片占篇幅等4）作者刷量：不可刷数据-我们鼓励作者自发宣传自己的文档，但不可使用人工刷量、注册小号刷量等方式提高下载量；不可将文档拆分多份上传，导致单份内容无实际意义、缺乏完整性5）重复文档：重新上传以前发布的文档系统会自动识别判定为重复仅自己可见，也不可删除旧文档后重新上传三、上传步骤登录上传：登录墨天轮账号后，点击链接直达上传页：https://www.modb.pro/docUpload，或在首页下拉框点击 “传文档”；填写信息：标题：建议明确标注 “数据库种类 + 巡检场景”（如《MySQL数据库巡检手册》《Oracle数据库常规巡检项目和命令》），帮助他人快速判断主题标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签墨值设置：支持免墨值 / 5 墨值 / 10 墨值 / 25 墨值 / 50 墨值 / 100 墨值，设置墨值后，他人下载时支付的墨值将实时计入您的账户（ps：一般来说墨值越低下载门槛越低，被下载可能更高）提交：确认信息无误后点击 “提交文档”即可。于 “控制台-内容管理-我的文档” 处可查看您所有文档明细，若您遇到“仅自己可见”“转换失败”等状态可询问墨天轮小助手（VX：modb666）询问具体原因。四、奖励设置本次活动奖励分为 “合格奖”“有效助人奖”“巡检先锋奖” 三类1、合格奖每位用户每日首次上传≥5 页的合格文档，可自动触发 “每日任务” 获 5 墨值。此外，本次活动奖励额外可叠加，根据用户合格文档数量发放不同等级的墨值奖励，具体如下：合格数量墨值0-3个10墨值/份3个以上15墨值/份2、有效助人奖根据单个文档下载数发放不同等级的墨值奖励，每个用户最多可有5个文档获得本项奖励：被下载数墨值30＜被下载数 ≤ 5050墨值50＜被下载数 ≤ 100100墨值100＜下载数 ≤ 150200墨值150＜下载数 ≤ 200300墨值下载数＞200500墨值3、巡检先锋奖将综合评估用户上传的合格文档的内容质量及总下载量，评选出 “既多产、又优质” 的核心贡献者，发予相应奖励：奖项等级奖励内容第 1 名1000 墨值 + 100元内数据库实体书一本第 2 名500墨值 + 爱国者U盘（128GB 双接口）第 3-5 名笔记本电脑支架（可旋转）说明：三类奖项单独评奖、每位用户可重复获得。其中新版本先锋奖数量将根据实际参与情况灵活调整，若参与情况佳则可能增设、反之亦然。五、奖励公布与发放进度公示：为了让大家更加了解自己的参与进度，将在活动期间不定期在活动原文评论区公布最新合格情况。若发现违规行为也欢迎向工作人员反馈，一经核实将取消其参与资格。结果公布：活动结束后 3 个工作日内公布所有获奖名单；奖励发放：墨值将在结果公布后 1-2 个工作日内发放至账户；实物奖励将通过私信收集地址，10 个工作日内寄出。常见问题（Q&A）Q1：如何让我的安装文档下载率更高？：A：建议在标题、简介中写明 “适用版本 + 核心亮点”，若上传的是.zip 等无法预览的格式，可在评论区附关键步骤截图或内容大纲，帮助他人判断价值。Q2：墨值可以干什么？A：墨值是墨天轮社区的“通用货币”，可以用来下载付费文档、赞赏他人文章或进行提问赞赏、直播打赏、兑换商品、参与墨值拍卖等。具体可查看使用说明：https://www.modb.pro/db/446902。Q3：我的文档会被展示在哪里？A：文档上传成功后可在您的控制台、个人主页找到相应链接。管理员也会择优推荐到网站首页及文档页面，为您的文档增加更多曝光。若您觉得您的文档优秀，欢迎您转发分享或自荐给工作人员，我们将为您争取首页推荐、转发等更多曝光。无论是你是初学者还是资深开发者，欢迎你加入本次文档悬赏活动，分享你的优质文档，与更多朋友一起学习进步！未来我们也将针对更多技术主题推出悬赏活动，如果你有推荐的主题也不妨告诉我们！乐知乐享、共同成长！点击跳转上传文档：https://www.modb.pro/docUpload往期活动导航【文档悬赏令】第1号：数据库新版本的安装实操欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台，持续促进数据领域的知识传播和技术创新。关注官方公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯
2026年1月中国数据库流行度排行榜：OB卫冕首席启新岁，PolarDB进位榜二绽锋芒
新元启幕，万象更新；榜单出炉，洞察先机。2026 年首期中国数据库排行榜正式发布，本期榜单整体格局延续此前态势，排名变化不大。回顾 2025 年，国产数据库厂商整体表现稳健，技术路线与产品定位进一步清晰。在这一背景下，1 月榜单的表现也为观察当前国产数据库市场的竞争格局与发展趋势提供了一个清晰窗口。接下来，和小编一同盘点本月榜单部分产品的亮眼表现。一、PolarDB 升榜眼，达梦守前三最新数据库榜单前十揭晓，OceanBase 毫无悬念卫冕榜首，PolarDB 实力突围跃升榜眼，达梦数据库稳坐前三之位。值得关注的是，本月前十排名中，仅 PolarDB 与达梦两家的位次发生调整，其余产品座次保持不变。图1:中国数据库流行度排行榜前十得分情况新年伊始，OceanBase 以737.24分稳居榜首，这份领先地位的背后，是其在技术研发、工程实践与战略布局上的全方位深耕。在数据库核心问题研究上，OceanBase始终深耕不辍，联合华东师范大学发表的论文《APQO：自适应参数化查询优化框架》成功入选数据库顶级会议SIGMOD 2026；与中国人民大学合作完成的关系型数据库缺陷实证研究成果，也顺利被IEEE TSE正式录用，通过系统分析777个真实缺陷，足见其在工程质量与底层机制打磨上的持续深耕。工程与产品打磨上，2025全年OceanBase完成460次投产，稳定支撑1500余个关键业务系统运行，在高复杂度生产环境中沉淀出成熟的交付与运维体系；全年累计推进16次版本迭代，新增489项功能与158项数据库相关专利，工程体系化能力进一步夯实。面向AI时代浪潮，OceanBase持续推进一体化战略，不仅发布兼容TP、AP与AI负载的融合版本OceanBase 4.4，还推出AI原生混合搜索数据库SeekDB助力Data × AI战略落地，其在AI就绪数据库方向的探索，更首次获得IDC面向生成式AI的数据基础设施“领导者”评价。本月 PolarDB以654.49分排名较上月上升一位，跻身榜眼之位，整体表现稳中有进。行业认可方面，Gartner 2025年全球云数据库管理系统魔力象限给出了有力佐证——阿里云连续第六年入选“领导者”象限，且是亚太区唯一入选厂商。这一成绩的背后，作为阿里云核心云原生关系型数据库的PolarDB提供了重要技术支撑，充分印证自身产品成熟度、技术完整性与全球竞争力。图2:Gartner 2025年全球云数据库管理系统魔力象限IDC最新报告披露的市场数据同样可观，2025年上半年中国关系型数据库软件市场规模达22.1亿美元，公有云关系型数据库同比增长16.3%，增速优于整体市场；阿里云位列市场前三，在云数据库规模化交付与行业覆盖上的优势，为PolarDB的持续落地与增长筑牢市场基础。图3:2025 年上半年中国关系型数据库软件市场规模前三名分别为：阿里云、腾讯、华为达梦数据库本月以614.76分稳居榜单第三名，核心竞争力集中在多关键行业的国产化落地成效，以及技术与生态的双重突破。国产化实践推进中，达梦不断拓宽覆盖边界、提升项目复杂度，在医疗、通信、交通等领域均交出亮眼答卷：助力武汉大学人民医院完成病案管理系统底层数据库升级重构；与福建移动深化国产化替代合作，还助力其斩获“数字中国创新大赛”奖项；参与建设的西镇高速全路段国产化收费系统已实现稳定运行。底层能力打磨与生态建设同步推进，凭借扎实的生态建设成果，达梦荣获2025 IDC中国生态奖；资本市场上，达梦数据（688692）成功入选“科创板上市公司价值30强”。综合来看，达梦数据库本月稳居前列，正是其在重点行业落地、技术自主可控及生态体系建设上持续发力的必然结果。金篆信科GoldenDB 本月表现亮眼，以577.06分位居行业排行榜第四位，核心竞争力在权威认可与关键行业落地中充分彰显，成为国产数据库领域的核心标杆。权威评选中，2025数据智能“星河（Galaxy）”案例评选给出有力背书，GoldenDB成为入选案例数量最多的数据库厂商，充分印证其技术落地能力与行业实践深度。关键行业布局中，运营商领域GoldenDB稳居领先地位，在中国移动、中国联通核心系统数据库市场占比分别超80%、60%，每日支撑9亿+移动用户、12亿+物联网用户计费，与多家移动公司合作的核心业务改造、智能运维等案例均获权威认可，转型成效显著。金融领域更是实现突破，作为业界首家覆盖全类型金融机构核心系统的国产数据库，其服务超100家金融机构，每日承载超100亿笔、10万亿元交易，获头部机构战略投资，连续稳居市场占有率第一。本月，金仓数据库以568.20分位列行业排行榜第五位，核心优势集中在关键行业持续落地与产品能力的迭代完善上。能源领域始终是其重点实践方向，截至目前，已累计支撑1000余个发电厂项目，部署3000多套数据库，覆盖全国31个省（区），形成扎实的规模化应用基础。产品能力打磨上，金仓数据库聚焦部署、安全与性能三大核心维度持续优化；行业认可持续加码，金仓数据库与辽宁移动、新疆移动等合作的多项实践成功入选2025数据资产管理大会“星河案例”榜单。排名第六位的腾讯云TDSQL表现尤为亮眼，核心竞争力集中在金融核心系统领域的规模化落地能力与高可靠运行水平。2025年年终决算作为银行IT体系最具挑战性的关键节点，TDSQL成功护航70余家金融机构实现“零失误”完成决算，覆盖国内超过半数Top 100银行，服务对象涵盖国有大行、头部股份制银行、城商行及支付清算机构，行业覆盖的深度与广度持续提升。YashanDB稳居行业排行榜前十，回顾2025年，其在行业影响力与技术能力两方面均取得实质进展，不仅跻身墨天轮中国数据库流行度排行榜前十，核心技术能力更获得中国电子学会“国际领先水平”认证，技术成熟度与专业认可度同步提升。产品与技术演进上，YashanDB V23.5版本以“TP+”为核心理念，面向企业混合工作负载场景进行系统性优化，多个关键模块能力实现跃升。综合来看，崖山数据库在保持榜单稳定位置的同时，通过持续的产品迭代与技术深化，进一步夯实了其在混合负载数据库方向的竞争力。二、细分产品实力出圈，多元特色创新破局图4:本月亮点数据库得分情况在月度中国数据库排行榜的头部阵营之外，一批各具技术特色与落地实力的数据库产品同样表现亮眼。它们或是凭借长期技术积淀夯实竞争力，或是依托行业标杆项目实现排名跃升，或是在细分赛道突破创新，共同勾勒出国产数据库多元化发展的活力图景。本期榜单中，排名第十一位的 openGauss 的稳定表现源于长期技术积累，核心支撑落在持续的内核演进、软硬协同优化与工程能力沉淀上。去年11月发布的7.0.0创新版，基于鲲鹏920平台在权威HTAP基准测试HyBench中斩获H-Score 2831.89的优异成绩，再度刷新性能纪录。openGauss Summit 2025的召开，进一步释放出持续演进的明确信号。大会不仅开源业界首个多写数据库架构oGRAC，更发布“1+2”技术战略，敲定多读多写、超节点数据库及AI原生多模态数据库底座的建设方向。Apache IoTDB 位次稳定保持在第20位，商业场景与航天领域的双重落地突破，成为榜单排名的核心支撑，充分验证其技术成熟度与市场适配能力。依托高吞吐读写能力、高压缩比及端 — 边 — 云协同架构的核心优势，Apache IoTDB 在关键场景中持续彰显硬核实力。航天领域更是斩获亮眼成果，12 月 3 日朱雀三号遥一运载火箭成功首飞入轨，这款国产时序数据库为此次试验提供高效数据管理支撑。本月，万里数据库排名稳步提升至第34名，重点行业项目的持续落地成为核心增长动力。作为国家级专精特新“小巨人”企业，万里数据库深耕国产自主可控数据库研发，核心产品GreatDB在金融与运营商领域的实践成效持续凸显。在运营商“O域系统国产替代”项目中，GreatDB凭借对MySQL协议与生态的高度兼容，实现应用平滑迁移与业务连续运行，迁移效率与运维友好性得到充分验证。深厚的技术积淀叠加丰富的行业实践，让万里数据库已构建起成熟的自主可控数据库解决方案。同方数科自主研发的KBase多模数据库成为本月榜单最大“黑马”。独特的搜索/NXD/RDF/向量四模一体架构是KBase的核心竞争力，集成98%精准度中文处理算法与400万概念词典，全文检索性能达2TB/s，十亿级向量检索可实现毫秒响应，在大规模知识管理与复杂数据处理场景优势显著。目前产品已通过信通院搜索型数据库与向量数据库双评测，斩获35项信创认证，全面适配鲲鹏/飞腾芯片及统信/麒麟系统，核心能力获得权威背书。近期，一款数据库新品凭借亮眼动作引发行业关注 —— 数翊科技自主研发的海纳数据库（HexaDB）于 12 月完成近亿元融资，这款定位于库仓一体型的产品，精准覆盖高并发交易与实时分析并存的复杂业务场景，成长势头强劲。成立于 2022 年的数翊科技，已凭借 HexaDB 在金融、智能制造、车联网、物联网等领域服务多家头部客户，产品逐步切入企业关键业务系统。技术架构上，数翊科技构建起自主创新的 H-T-A-I-P 全栈技术体系，实现交易型、分析型与智能型业务的一体化融合。研发布局层面，华中研发总部已落地武汉光谷，聚焦核心技术持续攻坚，强化区域服务与产业协同。随着技术能力、行业实践与研发布局的持续完善，HexaDB 正在实时库仓一体化与 “DB for AI” 方向上，逐步释放工程化与商业化潜力。三、见证荣耀时刻，2025年度数据库奖项揭晓在全球数字化转型持续深入与国家信创战略全面落地的双重推动下，数据库作为支撑数字经济运转的核心基础设施，正经历着从技术跟跑到自主引领的关键跨越。2025 年，云原生与人工智能的深度融合，不仅重构了数据库的技术架构，更催生出多元化的行业应用场景，国产数据库厂商也在核心技术突破与关键系统替代中交出亮眼答卷。为梳理年度发展成果、树立行业标杆，墨天轮社区依托近 50 个权威评估指标启动 2025 年数据库奖项评选。接下来，就让我们一同揭晓本年度脱颖而出的行业璀璨亮点。点击查看年度获奖名单图5:2025年度数据库获奖名单本次评选落下帷幕，上榜的每一款产品都以独特的技术优势与应用价值，勾勒出数据库领域的年度发展图景。我们期待，未来能见证更多产品在自主研发的道路上稳步迈进，在关键场景中持续释放价值，书写国产数据库的崭新篇章。相关阅读国产数据库流行度排行榜-墨天轮国产数据库流行度排名规则-墨天轮《往期国产数据库流行度排行榜解读》《中国数据库行业分析报告》往期合辑原文链接 ：https://www.modb.pro/db/2010657961249693696欲了解更多可浏览墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台，持续促进数据领域的知识传播和技术创新。关注官方公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯