--- title: "OceanBase AP 核心特性 | OceanBase 文档中心" description: OceanBase AP 核心特性 AP 关键能力总览如下： 列存引擎 在大规模数据复杂分析或海量数据即席查询场景中，列式存储是 AP 数据库的关键能力之一。列式存储是一种数据文件组织方式，区别于行式存储，它将表中的数据按照列进行物理排列。数据进行列式存储时，分析场景可仅扫描用于查询计算的列数据，避免整行扫描，减少 … --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库集中式版 - V 4.3.5 # OceanBase AP 核心特性 更新时间：2026-07-06 14:23:11 [编辑](https://github.com/oceanbase/oceanbase-database-standalone/edit/V4.3.5/zh-CN/620.obap/70.obap-features.md) AP 关键能力总览如下： ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.6.0/key-features-20260424.png) ## 列存引擎 在大规模数据复杂分析或海量数据即席查询场景中，列式存储是 AP 数据库的关键能力之一。列式存储是一种数据文件组织方式，区别于行式存储，它将表中的数据按照列进行物理排列。数据进行列式存储时，分析场景可仅扫描用于查询计算的列数据，避免整行扫描，减少 IO 和内存等资源使用，提升计算速度。另外按列存储也天然具备更好的数据压缩条件，更易获得较高的压缩比，减少存储空间和网络传输带宽。 OceanBase 基于 LSM-Tree （Log Structured Merge-Tree）的数据存储结构，通过持续优化高并发事务处理（TP）能力，在随机写入、实时更新、强一致性等场景中不断提升性能，积累了大量的工程实践经验，构建了自主可控存储引擎技术体系。与此同时，LSM-Tree 的分层合并特性与数据静态化组织能力，使其天然适配以批量写入、低频更新为特征的 OLAP 场景：通过列存数据压缩、层级合并策略与存储碎片优化，既满足分析型负载的高效扫描需求，又实现了 TP 与 AP 混合负载的统一架构支撑。 在 V4.3 版本，基于原有技术积累，OceanBase 存储引擎继续扩展，实现对列存的支持，实现存储一体化，一套代码一个架构一个 OBServer，列存数据和行存数据共存，这样真正实现了对 TP 类和 AP 类查询的性能的兼顾。 ### 列存引擎架构 首先每个用户数据整体可以分成两个部分：基线数据和增量数据。 **基线数据** - **多态存储支持：** 基线数据支持行存、列存及行列混存三种物理形态，用户可通过建表配置灵活选择，满足不同业务场景的存储需求。 **增量数据** - **行存优先策略：** 增量数据强制采用行存模式，确保事务处理（TP）链路与原生行存架构完全兼容，共享事务日志、锁机制等核心组件。 ![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/columnstore.png) **行列混合存储体系** 基于列存场景更新可控的特点，OceanBase 数据库结合自身基线数据和增量数据的特质，提出了一套对上层透明的列存实现方式： 1. **存储形态解耦：** 基线数据按列存格式组织（每列独立 SSTable，虚拟组合为逻辑表），增量数据保持行存，DML操作与上下游同步完全无感知。 2. **动态同步引擎：** 底层构建行列数据双向同步管道，支持 OLAP 系统迁移/行存升级的平滑过渡，业务无需感知存储格式差异。 3. **智能路由机制：** 从优化器到执行器，系统基于负载特征自动选择最优行/列访问路径，使列存性能优势在 AP 场景中充分释放，同时保留行存对 TP 事务的原生支持。 #### 关键一体化能力 | **能力维度** | **关键技术实现** | | --- | --- | | **SQL一体化** | - 列存感知代价模型与统计信息体系 - 向量化引擎支持动态批处理（Adaptive Batch Size） - 混合计划自适应选择执行引擎 | | **存储一体化** | - 表级存储模式动态配置（行存/列存/混存） - 透明化DDL支持（在线结构变更与二级索引） | | **事务一体化** | - 增量数据行存化保障ACID特性 - 共享行存事务日志与多版本控制 | ![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/engine-1.png) ### 列存主要特性 - **特性 1：自适应 Compaction** 引入新的列存存储模式之后，数据合并行为和原有行存数据有较大变化，由于增量数据全部是行存，需要和基线数据合并后拆分到每个列的独立 SSTable 中，合并时间和资源占用相对行存会有较大增长。为了加速列存表合并，存储层也对 Compaction 流程进行了适配优化，对于列存表，除了能够像行存表一样进行水平拆分并行合并加速之外，还增加了垂直拆分加速，列存表会将多个列的合并动作放在一个合并任务内进行，并且一个任务内的列数能够根据系统资源自主选择升降，保证整体在合并速度以及内存开销达到更好的平衡。 - **特性 2：列式编码算法** OceanBase 数据库存储数据会经过两级压缩，第一级是 OceanBase 自研的行列混合编码压缩，第二级是通用压缩，其中行列混合编码由于是数据库内置算法，因此可以支持不解压直接查询，同时可以利用编码信息进行查询过滤加速。但是原有行列混合编码算法仍然偏向行组织，因此针对列存表实现了全新的列式编码算法，相比原有编码算法，新算法支持查询的全面向量化执行，支持兼容不同指令集的 SIMD 优化，同时针对数值类型大幅提高压缩比，实现对原有算法在性能和压缩比上的全面提升。 - **特性 3：Skip Index** 常见列存数据库一般均会对每列数据按照一定的粒度进行预聚合计算，聚合的结果随数据一起持久化，当用户查询请求访问列数据时，数据库能够通过预聚合数据过滤数据，大幅减少数据访问开销，减少不必要的 IO 消耗。 在列存引擎中，我们同样增加了 skip index 的支持，针对每列数据会按照微块粒度进行最大值、最小值、以及 null 总量等多个维度的聚合计算，并逐层向上聚合累加获得宏块、SSTable 等更大粒度的聚合值，用户查询能够根据扫描范围不断下钻选取合适粒度聚合值进行过滤以及聚合输出。 - **特性 4：查询下压** OceanBase 数据库从 V4.x 版本开始，存储层的算子及表达式已经全面适配向量化执行，并支持了一些场景的查询下压。列存引擎中，下压功能进一步得到增强和扩展，具体包括： - 所有查询 filter 下压，同时根据 filter 类型，能够进一步利用 skip index 以及编码信息加速。 - 常用聚合函数的下压，非 group by 场景下，目前 count/max/min/sum/avg 等聚合函数已能下压到存储引擎。 - group by 下压，在 NDV 较少的列上，支持 group by 下压存储计算，利用微块内字典信息进行大幅加速。 有关列存的详细介绍和使用指导，参见[列存](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003578002)。 ## 向量化执行引擎 向量化执行是一种高效的按批处理数据的技术，在分析型查询中，向量化执行可以大大提升执行性能。OceanBase 数据库在 V3.2 版本引入了向量化执行引擎，但默认关闭。从 OceanBase 数据库 V4.0 版本开始，默认开启了向量化执行引擎，并在 OceanBase 数据库 V4.3 版本中实现了向量化引擎 2.0，通过对数据格式，算子实现优化及存储向量化优化等大幅提升了向量化引擎执行性能。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.3.5/620.obap/vector-engine.png) ### 数据格式简介 在向量化引擎 2.0 中，引入了新的按列数据格式，将数据描述信息（null、len、ptr）分别按列存放，避免冗余存储。根据不同数据类型和使用场景，设计了三种数据格式：定长数据格式、变长离散格式和变长连续格式。 - **定长数据格式：** 仅需存储一次 length 值，无需冗余存放，直接访问，数据局部性更佳。相较于 1.0 版本，节省空间、提高效率，并省略了指针的 swizzling 操作。 - **变长离散格式：** 每个数据在内存中可能不连续，每个数据用地址指针和长度描述。这种格式在编码数据时可避免深拷贝，适合短路计算场景，避免数据重整。 - **变长连续格式：** 数据在内存中连续存放，长度信息和偏移地址由 offset 数组描述。此格式提高了数据访问效率，但短路计算和列存编码投影时需要重整及深拷贝，该格式主要用于按列物化场景。 ### 算子及表达式性能优化 向量化引擎 2.0 对算子及表达式进行了全面优化，核心思路是利用新格式的信息以及数据结构的特化实现，降低 CPU Cache Miss 和指令开销，提升整体执行性能。主要优化包括： - **利用 batch 数据属性信息：** 维护 batch 数据特征信息，消除对 NULL 的特殊处理和过滤判断，优化 SIMD 计算。 - **算法及数据结构优化：** 优化了中间结果物化结构，支持按行/列物化，Sort 算子实现了 sort key 与非 sort key 的分离物化，降低了排序过程的 Cache Miss，提高了整体效率。 - **特化实现优化：** 针对具体场景进行优化，例如将多列定长 join key 编码为一个定长列和聚合计算的特化实现，显著提高执行效率。 ### 存储向量化优化 存储层全面支持新的向量化格式，通过 SIMD 加速投影、谓词下压、聚合下压和 groupby 下压等操作。投影时按列类型和长度定制化模板，简化计算；谓词计算则在列编码上直接进行，推动复杂表达式的快速计算。聚合下压利用中间层的预聚合信息，高效处理统计函数，groupby 下压利用编码数据信息显著加速性能。 ## 实时写入 OceanBase 采用 LSM-Tree (Log-Structured Merge-tree) 架构，这一架构的设计保证了数据库的实时写入能力。下面将对 OceanBase 数据库的实时写入能力进行详细介绍。 ### 核心存储机制 #### LSM-Tree 为了支持高效的实时写入，OceanBase 采用了 LSM-Tree 结构来存储增量数据。LSM-Tree 是一种特殊的树结构，专为优化写入操作而设计。其核心思想是先将写入操作记录在内存中的结构里，待到一定量后再异步批量写入磁盘，这样大大减少了磁盘 I/O 的次数，提高了写入性能。OceanBase 将这些增量数据定期通过转储、合并过程与基线数据合并，确保数据的一致性和完整性。 ### 实时写入能力 OceanBase 数据库采用 LSM-Tree 架构的设计，使得它在处理实时数据写入时表现出卓越的性能。无论是小量的数据更新还是大量的数据导入，OceanBase 数据库都能快速响应，保证数据的实时写入。其主要体现在以下几个方面： - **高效的写入处理：** 通过 LSM-Tree，OceanBase 数据库将写入操作集中处理，减少了磁盘操作，提升了写入效率。 - **数据的即时可查性：** 数据一旦被写入 LSM-Tree 的内存结构，即可对外提供查询，保证了数据的实时性。 - **优化的数据合并过程：** 通过智能的转储和合并策略，支持高效查询。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/storage.png) ## 优化器 OceanBase 数据库查询优化器是面向 HTAP 混合负载和实时分析场景设计的。一般而言，交易型负载具备以下典型特征：单次查询访问的数据量少、RT 响应要求高、吞吐率更高；分析型负载具备以下典型特征：单次查询访问的数据量多，吞吐率相对较低。不同类型负载要求的执行计划形态和调优方式差异也会较大。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer-enterprise/V4.6.0/ap-optimizer-20260424.png) - 交易负载通常需要针对基表过滤谓词和连接谓词创建合适的索引结构，要求每个表尽可能的选择合适的索引路径来大幅度减少数据扫描量。 - 分析负载通常依赖于列存进行全表扫描，使用 skipindex 快速跳过一些数据块的扫描；通过加大并行度来降低查询的响应时间。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/optimism-structure.png) OceanBase AP 优化器在完全继承 TP 优化器能力的前提下，针对各类复杂查询场景，进行了各模块的专项强化。 - **更完善的查询改写能力：** 查询改写模块支持了丰富的改写算法，不同的改写算法会匹配不同的模式，并进行相应的等价变换，以便将业务 SQL 往更 “好” 的方向改造。目前支持视图合并、子查询提升、内连接消除、外连接消除、消除恒真恒假条件等基于规则的改写算法，也支持了 OR Expansion、JA 子查询提升、Win Magic、Group-By Placement 等基于代价的改写算法。 - **行列路径选择：** 为了良好的处理 HTAP 混合负载，查询优化器一项核心的智能优化能力是自动的行列路径选择。这意味着对于一条查询，优化器会根据其数据访问特征，智能地决定是从行存（Row Store）还是列存（Column Store）中读取数据，以期达到最优的执行性能。OceanBase 针对列存扫描设计了针对性的代价模型，并引入新型的统计信息机制来准确评估列存 SkipIndex 对列存扫描的收益，保证在行存索引和列存扫描间进行准确的抉择。 - **更易用的 Auto DOP：** 通常数据库会使用并行执行来加速复杂 SQL 执行，但在实际业务场景中，是否开启并行及并行度大小比较难轻易评估。OceanBase 提供了 Auto DOP 能力，优化器在生成计划时，会评估查询需要执行的时间，自动确定是否开启并行和开启适量的并行度，以便 SQL 默认即可获得较优性能。 - **执行计划管理：** OceanBase 的 SPM（SQL Plan Management，SQL 执行计划管理）技术是保证实时分析型业务长稳运行的关键技术。它通过智能化地管理执行计划的演进来应对数据量剧烈变化，统计信息更新或者数据库版本升级之后，优化器可能会选择一个更差的新执行计划的情况，通过真实流量的灰度验证来防止执行计划出现回退。 想要了解更多信息，参见 [统计信息和估行机制概述](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003578221)。 ## 智能物化视图 智能物化视图的核心价值在于用户只需要通过 SQL 的形式定义数据处理结果，由 OceanBase 自动管理数据刷新和计算依赖。这意味着企业无需编写复杂的 ETL 脚本或管理数据管道，只需定义目标数据结构，OceanBase 将自动处理数据刷新、依赖管理和性能优化。这种方法极大地简化了数据工程流程，降低了运维成本，并确保了数据的新鲜度和一致性。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/mv-related-model.png) OceanBase 数据库支持的是异步物化视图，即基础表数据变动时，并不会立即更新物化视图，保证了基表 DML 操作的执行性能，但是物化视图的数据相对基表会存在延迟，依赖及时刷新更新数据。物化视图数据的更新支持两种策略：全量刷新和增量刷新。 - 全量刷新直接地重新执行物化视图对应的查询语句，完整计算并覆盖原有视图结果数据，适用于延时要求低、基表数据更新频率低或数据量较小的场景，例如，每天或每周更新一次的数据汇总报告。 - 增量刷新则只处理自上次刷新以来的数据变更部分，这种方式可以大大减少刷新所需的时间和资源。为实现精确的增量刷新，OceanBase 数据库实现了类似 Oracle MLOG（Materialized View Log）的物化视图日志功能，通过详细记录基础表的增量更新数据，确保物化视图能够快速增量刷新，增量刷新方式尤其适用于延时要求高、数据量庞大且变更频繁的业务场景，例如，在实时交易系统中，数据可能每分钟甚至每秒都在变化。 OceanBase 数据库还支持了实时物化视图，能够支持数据的实时分析。实时物化视图利用物化视图日志机制来捕获和处理基表数据的更改，查询时在线计算并集成数据变更，即使物化视图没有物理存储最新变更数据，也能确保用户得到与直接查询基表一致的查询结果。同时利用物化视图的查询改写能力做到透明查询加速。 OceanBase 数据库支持为物化视图指定主键或创建索引，以此优化基于主键或索引的单行查找、范围查询或关联场景性能。如果物化视图是多表 JOIN 形成的一张大宽表，可以通过创建列式存储的物化视图来提高某些查询的性能。并且通过创建分区物化视图可以利用分区裁剪的能力来减少操作的数据量。 在最新的 OceanBase V4.3.5 版本中，引入了嵌套物化视图（Nested Materialized View, Nested MV）功能，使您能在已有的物化视图基础上轻松构建新的物化视图，适用于数据仓库的 ETL 流程，即嵌套物化视图可以在数据转换和加载阶段生成中间结果，这些结果可以作为后续处理的输入，进一步优化整个数据处理流程的效率。 有关物化视图的详细介绍和使用指导，参见 [物化视图概述（MySQL 模式）](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003578272) 和 [物化视图概述（Oracle 模式）](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003578244)。 智能物化视图的关键特性： - **声明式 SQL 定义：** 智能物化视图允许用户以声明方式定义数据处理结果，而无需手动管理转换步骤。用户只需编写标准 SQL 查询来指定数据转换逻辑，OceanBase 负责执行和维护这些查询。 - **自动刷新机制：** OceanBase 根据用户指定的目标数据新鲜度要求自动处理数据刷新的级联关系，包括调度和执行。用户只需定义数据应保持的最新程度，例如30秒或5分钟的目标滞后，OceanBase 会自动确保数据符合这一要求。 - **增量处理优化：** 智能物化视图使用自动增量视图维护技术，只计算自上次刷新以来的更改，而不是执行全面刷新。这大大提高了性能并降低了计算成本。 - **依赖关系管理：** 智能物化视图会自动跟踪数据依赖关系，确保在基础数据变化时按正确顺序刷新。这消除了手动管理复杂数据管道依赖的需要。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/mv-related-model-1.png) ## 多模类型 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/data-type.png) 多模的存储基础是 LOB (Large Object)，同时 LOB 在 AI 的存储以及数据处理上具有重要的作用，AI 场景下的多模态数据（图片、文本、音频、视频）都是大对象，LOB 的性能对 AI 预训练等场景的计算效率非常重要。OceanBase 在存储层提供了非常高效的 LOB 实现，SQL 下支持 512M 的存储，使用 DBMS.Lob 包，可以支撑 TB 级大对象的高效存取。 在数据分析场景，OceanBase 原生支持 Array、Roaring Bitmap、Map 等多模数据类型，不仅可以高效存储、查询结构化数据，还能直接支持半结构化与复杂聚合分析。 - Roaring Bitmap/Map：适配大规模标签分析、人群圈选、去重聚合等高阶数据挖掘场景。 - Array：为日志检索、行为轨迹、多维标签等复杂业务提供极大灵活性，真正做到一库多能。 有关高效压缩位图数据类型的详细介绍和使用指导，参见 [高效压缩位图数据类型（RoaringBitmap）](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002018081)。 有关数组类型的详细介绍和使用指导，参见 [数组类型](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002018079)。 JSON 作为目前最通用的半结构化类型，在交易、分析甚至是 AI 场景，都有非常广泛的应用。 1. 在交易场景，作为 Schemaless 的弹性列存储和计算 2. 在分析场景，JSON 的多值索引适用于多维标签的灵活计算 3. 在 AI 场景，JSON 承接了模型和应用的衔接桥梁，同时在智能体/工作流等数据处理 Pipeline 中，JSON 也作为标准的输入输出格式。 为了支撑 JSON 在多工作负载下的能力，OceanBase JSON 实现了丰富的计算表达式、基于 JSON 的多值索引等；在底层存储格式中，不仅支持了 JSON Binary，优化 JSON 内数据的随机读写，同时支持了 JSON 的结构化编码，通过对相似 JSON 提取结构化信息，深度优化 JSON 的存储压缩比以及基于 JSON Path 的查询性能。有关 JSON 数据类型的详细介绍和使用指导，参见 [JSON 数据类型](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002018089)。 在生成式 AI 时代，多模态数据的处理变得越来越重要。OceanBase 强化了向量能力以及全文搜索能力，更好的支撑了知识检索场景下对混合搜索的诉求。基于向量算法+数据库的全自研路径，OceanBase 的向量，和开源向量数据库相比有明显优势，在 VectorDBbench 中性能超过典型开源竞品。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/vector-skill.png) ### 特殊索引 在传统关系型数据库中，B-Tree、Hash 等索引主要针对结构化数据的精确值查询（如数字、日期等）。但在实际业务中，随着半结构化数据（如JSON文档）、非结构化文本（日志、长文本）以及多维分析场景的普及，OceanBase 提供两类特殊索引： - **全文索引：** 基于倒排索引实现，通过分词技术对文本内容建立关键词映射，适用于日志分析、文档检索等场景 - **多值索引：** 针对JSON数组字段建立元素级索引，将数组展开为虚拟行记录并构建B-Tree索引，显著提升集合数据查询效率。 二者通过差异化的数据结构设计，为不同数据类型（文本/JSON）和查询模式（模糊匹配）提供针对性优化，共同构成复杂数据查询的加速层。 #### 全文索引 在关系型数据库中，索引通常用于加速精准值匹配的查询。然而，传统的 B-Tree 索引在处理大量文本数据和模糊检索时往往无法满足性能要求。此时，执行全表扫描来逐行查找匹配数据会导致性能瓶颈，尤其是在文本量大和数据量庞大的场景下。此外，复杂的查询需求，如近似匹配和相关性排序，也难以通过简单的 SQL 改写来实现。 为了解决这些问题，OceanBase 目前支持兼容 MySQL 的全文索引功能。全文索引通过预处理文本内容，建立关键词索引，显著提升全文搜索效率。 全文索引用于快速搜索文本数据的技术，其主要功能包括： 1. **全文搜索：** 通过构建全文索引，能够对整个文档或大段文本内容进行全面的索引，从而实现更灵活、高效的搜索。 2. **快速查找：** 用户可以根据输入的关键词在数据库中快速查找匹配的文本，大大减少了搜索时间。 3. **高效处理大量文本：** 全文索引能够有效处理各种类型的文本数据，包括文章、报告、网页和电子邮件等，为用户提供精准且快速的搜索体验。 4. **支持复杂查询：** 除了基础的关键词搜索，全文索引还能支持复杂的查询需求，例如近似匹配和相关性排序，极大地丰富了数据库的搜索能力。 通过引入全文索引功能，OceanBase 可以在面对大规模文本数据和复杂检索需求时，显著提高查询性能，使得用户能够更高效地获取所需信息。 有关全文索引的详细介绍和使用指导，参见 [全文索引（MySQL 模式）](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003578317)。 #### 多值索引 多值索引是 OceanBase 数据库 MySQL 模式下的一个特殊索引功能，主要用于处理 JSON 文档和集合数据类型，适用于需要对多个值进行查询或者需要对多个属性进行查询的场景。其主要特点如下： - 可以在数组或集合上创建索引 - 目前适用于 JSON 文档 - 可以提高基于 JSON 数组元素搜索的查询效率 多值索引在 AP 场景中非常有用。AP 场景通常涉及到复杂的数据分析和报表生成，多值索引可以加速这些操作。例如，在数据仓库中，多值索引可以用于加速对多个维度的数据分析，提高报表生成的效率。具体适用场景如下： - 多对多关联查询：使用多值索引可以优化实体间多对多关系的查询。例如，演员和影片的关系中,可以用 JSON 数组存储影片的所有演员,并通过 JSON 多值索引快速查询某演员参演的所有影片。 - 标签和分类查询：当实体具有多个标签或分类时,多值索引可以加速相关查询。例如,商品的多个标签可以存储在 JSON 数组中,通过 JSON 多值索引快速查找包含特定标签的商品。 有关多值索引的详细介绍和使用指导，参见 [多值索引](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003578315)。 ## MySQL 生态兼容 在追求极致性能与扩展性的同时，OceanBase 数据库还致力于提供与 MySQL 生态系统的高度兼容性，从而让 MySQL 业务能够无缝迁移至 OceanBase 数据库，并充分利用现有的 OLAP 生态工具与技术栈，实现数据分析与业务洞察的快速迭代与创新。 语法兼容性：OceanBase 数据库全面支持 MySQL 的 SQL 标准语法，包括但不限于数据定义语言（DDL）、数据操作语言（DML）以及数据控制语言（DCL）。这意味着，如果您之前使用 MySQL 编写的数据查询、表结构定义、索引创建、权限管理等语句，几乎可以直接在 OceanBase 数据库上运行，无需进行大量语法调整，大大降低了迁移成本和学习曲线。 - **无缝迁移：** 现有 MySQL 应用可以快速迁移到 OceanBase 数据库，减少迁移过程中的代码修改工作量。 - **技能复用：** MySQL 开发人员和 DBA 无需额外学习新的数据库语法，缩短适应周期。 - **生态融合：** 与 MySQL 生态兼容的语法基础，使得 OceanBase 数据库能更好地融入现有的 BI、ETL、数据可视化等工具链中。 视图兼容性：OceanBase 兼容了 MySQL 的 information_schema 视图，例如： - **表信息查询：** 支持如 TABLES、COLUMNS 视图，用户可以查询数据库中所有表的结构、列信息，这对于数据字典管理和第三方工具的集成至关重要。 - **权限管理：** 支持 SCHEMATA、SCHEMA_PRIVILEGES 等视图，帮助管理员便捷地查看和管理数据库、表的权限设置。 许多数据库管理、监控和分析工具依赖 INFORMATION_SCHEMA 来获取数据库状态和架构信息。OceanBase 数据库的这一兼容特性，使得这些工具可以直接在 OceanBase 数据库上运行，无需定制适配。OceanBase 数据库支持各类 OLAP 生态工具，例如： OceanBase 实现了从批量到流式的全栈数据集成： - 支持 Flink、Kafka、OMS、OBLOADER、Dataworks、dbt 等主流工具的无缝接入，轻松对接企业现有 ETL、实时同步、数据仓库环境。 - 数据库内核支持旁路导入、文件/ODPS/HDFS 外表、External Catalog 等，极大降低多源数据整合、数据湖联动的开发与运维门槛。 - 高度兼容 MySQL/Oracle 语法，主流 BI、分析与流计算工具（如 Tableau、PowerBI、Flink、Quick BI 等）可零代码迁移接入，真正做到“开箱即用”。 OceanBase 不止在核心引擎上创新，同时也适配了诸多生态产品： - 自动化编排调度：深度集成 DolphinScheduler、n8n、Airflow 等调度平台，实现多环节数据处理任务的自动编排与运维，提升大规模数据治理与多系统协同效率； - 可观测性：与 Prometheus、Grafana 等监控工具无缝集成，支持多租户、节点、集群的实时性能监控、告警与智能运维，便于大规模集群与多业务线稳定运营； - 数据可视化赋能：全面兼容 Superset、Tableau、QuickBI、观远 BI 等主流 BI 平台，支持多角色自助分析、交互式仪表盘和复杂业务报表，助力业务洞察和数据驱动决策。 ![](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/observer/ap/ecological-integrations-map.png) 关于目前 OceanBase 的 OLAP 生态集成情况，参见 [生态集成](https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003577306)。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线