AP version history

This topic only lists changes to core capabilities related to real-time analytics.

V4.4.2

Version information

• Release date: February 10, 2026
• Version: V4.4.2

New features and enhancements

• Enhanced materialized view functionality

  V4.4.2 continues to improve materialized view capabilities. At the DDL level, it supports RENAME operations and adding columns to materialized view logs. It also implements automatic creation and replacement of MLOG tables, as well as background redundancy cleanup. Incremental refresh capabilities are significantly expanded, now supporting complex query patterns such as outer joins, UNION ALL, non-aggregated single-table queries, and aggregated queries with LEFT JOIN. The handling of MIN/MAX aggregate functions is strengthened, supporting duplicate SELECT ITEMS and GROUP BY columns, and adapting to scenarios without a primary key base table. The AS OF PROCTIME() syntax is introduced to enable dynamic exemption from refresh for dimension tables (views that reference this syntax are supported), and the cascading refresh mechanism for nested materialized views is improved. Additionally, support for UDT/UDF, minimal mode, and the md5_concat_ws function is enhanced. View content display and creation error messages are optimized, comprehensively improving the flexibility, performance, and ease of use of materialized views in complex queries, real-time analytics, and operational management.

V4.4.1

Version information

• Release date: September 26, 2025
• Version: V4.4.1

New features and enhancements

• Support for HMS Catalog

  V4.4.1 supports the open table format of Iceberg data lakes, and also supports querying external tables in Iceberg and Hive formats through HMS Catalog. The introduction of HMS Catalog aims to build a unified metadata abstraction layer compatible with the HMS protocol. By automatically synchronizing metadata for multiple table formats (such as Hudi Timeline, Iceberg Snapshots) and seamlessly integrating with mainstream computing engines, it addresses metadata ambiguity across systems.

• External tables support JDBC plugins

  OceanBase supports directly accessing various external data sources via external tables, such as CSV files stored on OSS or ODPS tables. V4.4.1 introduces JDBC plugin capability, allowing connection to JDBC-compatible data sources. Currently, MySQL data sources are supported.

V4.4.0 Beta

Version information

• Release date: July 8, 2025
• Version: V4.4.0

New features and enhancements

• Support for ODPS Storage API

  V4.4.0 adds support for the ODPS Storage API, enabling ODPS external tables to directly access underlying ODPS storage. This avoids the second-level initialization latency caused by establishing independent sessions for each partition scan in the Tunnel API approach, significantly improving external table access performance in small query and high-frequency query scenarios. Tunnel API compatibility is retained to meet diverse access requirements.

• SELECT INTO OUTFILE supports HDFS paths

  V4.4.0 continues to improve external table functionality, supporting direct querying or importing files from HDFS paths via external tables. The new version further integrates HDFS capability, supporting direct data export to HDFS and HDFS access with Kerberos authentication.

V4.3.5 BP5

Version information

• Release date: November 17, 2025
• Version: V4.3.5 BP5

New features and enhancements

• Enhanced materialized view functionality

  V4.3.5 BP5 introduces support for incremental refresh of aggregated materialized views with left joins, allows creating nested materialized views based on incrementally materialized views without a primary key, supports using non-basic column parameters for MIN/MAX aggregate functions in aggregated incremental materialized views, enables incremental materialized views referencing regular views declared as dimension tables (AS OF PROCTIME()) in multi-table joins, supports full refresh of materialized views referencing UDFs, supports the minimal refresh mode for incremental materialized views (where incremental refresh DML only reads/writes data from necessary columns of the columnar table), and allows materialized views to use fixed session variables for refresh.

• Support for Skip Index in incremental data queries on Delete-Insert tables

  V4.3.5 BP5 supports Skip Index for pre-generated incremental data on Delete-Insert tables. When querying incremental data, Skip Index can be used to pre-filter data, significantly improving query efficiency. The coverage of Skip Index capability can be controlled via the tenant-level parameter default_skip_index_level.

• Extended partition exchange functionality

  Prior to V4.3.5 BP5, exchanges between partitions of RANGE/RANGE COLUMNS partitioned tables and non-partitioned tables, between subpartitions of RANGE/RANGE COLUMNS subpartitioned tables and non-partitioned tables, or between a subpartition's RANGE/RANGE COLUMNS partition and a partition of a non-partitioned table were supported. V4.3.5 BP5 extends this to include exchanges between a partition of a LIST/LIST COLUMNS partitioned table and a non-partitioned table.

V4.3.5 BP4

Version information

• Release date: September 10, 2025
• Version: V4.3.5 BP4

New features and enhancements

• Enhanced materialized view functionality

  V4.3.5 BP4 continues to refine materialized view capabilities. Functionally, it supports refreshing incremental materialized views without refreshing the dimension table. When creating a materialized view, you can use the new AS OF PROCTIME() syntax to specify which tables do not need to be refreshed, so their incremental data is skipped during the materialized view's incremental refresh. Incremental refresh of single-table aggregated materialized views now supports MIN()/MAX() aggregate functions. For ease of use, it supports automated MLOG management: when creating an incremental materialized view, it automatically creates/replaces the required MLOG tables for the base table and periodically cleans up redundant MLOG tables in the background. It also optimizes the view content of materialized views and the error messages reported during creation.

• AP parameter templates disable full direct load by default.

V4.3.5 BP3

Version information

• Release date: July 21, 2025
• Version: V4.3.5 BP3

New features and enhancements

External data source and integration optimizations

• ODPS external table adaptation to Storage API

  For ODPS external tables based on the Tunnel API, each partition scan during execution required opening a separate session, which introduced second-level latency. This caused some queries that were otherwise very fast to spend time preparing sessions. In addition to the Tunnel API, ODPS provides an open Storage API that allows direct access to its underlying storage, offering more optimization strategies and better read performance. Therefore, the new version adapts to support the ODPS Storage API, further enhancing external table access performance.

• Object storage support for Azure Blob

  Supports accessing Azure Blob object storage using the Azure Blob protocol.

Comprehensive enhancements to materialized views

• Materialized view enhancements

  The new version continues to improve materialized view capabilities. This includes support for RENAME on materialized views, incremental refresh support for outer joins, UNION ALL, and non-aggregated single tables, log support for added columns in materialized views, and cascading refresh support for nested materialized views. It also fixes multiple issues, such as the deadlock in DROP MATERIALIZED VIEW, improving the stability of materialized views.

Storage and partition management optimizations

• Partition exchange supports exchanges between partitions and subpartitions

  The partition exchange feature now supports exchanging a partition of a subpartitioned table with a partition of a partitioned table.

Optimizer and query performance improvements

• Statistics enhancements

  In versions prior to V4.3.5 BP3, statistics collection required aggregating data such as MIN/MAX/NULL COUNT/NDV for each column at the partition and table levels, and estimating data distribution through sampling, which resulted in significant errors. The new version leverages the skip index capability of the storage layer to collect more accurate block-level column aggregate data for all columns in columnar storage, aiding the optimizer in generating and optimizing execution plans more precisely. It also introduces a progressive statistics collection method for partitions to address timeout issues caused by long collection times for large partitioned tables, improving system stability and data real-time availability.

Accelerated data import

• Performance optimization for direct load

  The new version optimizes the execution logic for direct load, including the sorting algorithm, vectorized path, CSV parsing, column_conv expressions, and cs encoding related to direct load. In scenarios involving non-partitioned heap tables in columnar storage, this leads to up to a 10% performance improvement.

V4.3.5 BP2

Version information

• Release date: May 15, 2025
• Version: V4.3.5 BP2

Feature enhancements

Enhanced data recovery capabilities

• Table-level restore now supports restoring columnstore tables

  Prior to this version, the table-level restore feature only supported restoring rowstore tables. The new version improves the table-level restore feature in the Share Nothing deployment mode, adding support for restoring columnstore tables and hybrid row-columnstore tables.

Performance optimizations

• Performance optimization for direct load of heap tables

  Optimized the uniqueness verification process during the creation of unique indexes in direct load of heap tables. The performance of full import of non-partitioned heap tables is now no lower than that of index-organized primary key tables.

• Performance optimization for hard parsing

  In some AP scenarios or for accounts of varying sizes, disabling the plan cache and resorting to hard parsing can reduce the use of suboptimal plans. However, disabling the plan cache requires higher performance from hard parsing. The new version enhances the performance of the optimizer's resolve and rewrite phases by optimizing hotspot functions during the resolver phase, replacing scenarios that do not require global cost verification with local cost verification, reducing expression memory usage, and removing unnecessary expression type inference operations.

Materialized view enhancements

• Full refresh of materialized views now supports building on external tables

  Prior to V4.3.5 BP2, OceanBase Database already supported creating materialized views based on user tables and materialized views. The new version adds support for materialized views with external tables as base tables in full refresh scenarios, expanding the applicable scenarios for materialized views.

• Enhanced materialized view diagnostics

  Added the CDB/DBA_MVIEW_RUNNING_JOBS system view to display ongoing materialized view tasks, such as refresh tasks and MLOG cleanup tasks. Added the DBA_MVIEW_DEPS system view to display dependency object information for materialized views. The CDB/DBA/ALL/USER_MVIEWS system view includes records for materialized view refresh checkpoints and refresh latency. The CDB/DBA/ALL/USER_MVIEW_LOGS view includes parallelism and time consumption information used for MLOG cleanup.

• Materialized view tasks now support resource isolation

  Operations such as materialized view refresh and purge consume system resources, which may affect the performance of foreground tasks. The new version provides resource isolation for incremental refresh and MLOG purge of materialized views based on the Resource Manager, allowing users to limit the maximum resources a materialized view task can use.

Partition management

• Dynamic partition management

  Businesses often choose to use date or time as the range partitioning key, dividing data from different periods into different partitions. Currently, DBAs are required to periodically pre-create partitions for future times to accommodate data writes. If a DBA forgets to pre-create a partition for some reason, data writes may fail due to the non-existent partition, impacting the business. Therefore, the new version provides a dynamic partition management feature. By specifying the dynamic partition management attribute for a table, it automatically pre-creates partitions for future times at the kernel level, reducing the burden on DBAs. Additionally, dynamic partition management also supports automatically deleting expired partitions that are no longer needed by the business, saving storage.

Index and query optimization

• NGRAM2 tokenizer for full-text indexes

  Full-text indexes now include a built-in NGRAM2 tokenizer, supporting NGRAM tokenization within the range of min_ngram_size to max_ngram_size. The NGRAM2 tokenizer is suitable for scenarios where performance and storage space are relatively insensitive and searches for tokens of different lengths are required. For fixed-length tokens, the NGRAM tokenizer can be used.

Data types and storage optimization

• Map data type

  The Map data type is used to store unordered key-value pairs, such as {a:1, b:2, c:3}. Common usage scenarios include storing configuration options, user attributes, product information, etc. In OceanBase Database V4.3.5 BP2, the Map data type was implemented based on the Array framework, supporting the Map constructor and functions/operators such as map_keys, map_values, and /=!=.

• JSON semi-structured storage in MySQL-compatible mode

  Currently, semi-structured data is stored as binary strings, making it difficult to compress using encoding. To achieve self-explanability, each record redundantly stores some data metadata, resulting in low storage compression rates. JSON is a typical semi-structured data format with strong structured characteristics. Theoretically, semi-structured data can be logically split into multiple columns of basic types, with the indivisible parts placed in a Binary column. Structured columns can leverage encoding to improve compression rates, and the indivisible parts, having had their data metadata extracted, also occupy less space than before. This is referred to as "structured storage for semi-structured columns." OceanBase Database V4.3.5 BP2 supports semi-structured storage for JSON types, implementing the corresponding encoding method to reduce storage space usage and optimize query filtering performance for JSON sub-columns. However, because JSON is split into multiple sub-columns for storage, this introduces major compaction overhead and performance regression in scenarios that require frequent reading of raw JSON data. Whether to enable this feature should be determined based on the business type.

Query execution

• Adaptive plan cache

  Plan cache is a critical capability in TP scenarios and is therefore enabled by default. In some AP scenarios, however, the execution time of a plan can be many times longer than its generation time. In such cases, letting the optimizer generate a plan each time often yields a better execution plan than reusing one, leading to improved performance. In different scenarios, especially HTAP mixed-workload scenarios, there is a need to provide a way for AP-oriented SQL to undergo hard parsing while TP-oriented SQL can still reuse plans to avoid the overhead of hard parsing. Therefore, OceanBase Database's new version supports an adaptive plan cache capability, which can decide whether to use the plan cache for an SQL based on its execution duration and timing distribution characteristics.

External data source integration

• ODPS (MaxCompute) Catalog in MySQL-compatible mode

  To facilitate querying data stored in various external data sources, the new version supports the External Catalog framework and initially supports the ODPS Catalog feature. OceanBase's original internal objects belong to the Internal Catalog. Users can create their own External Catalogs to connect to external data sources and retrieve metadata of external data. It supports directly querying table data under an External Catalog, such as select col1 from catalog1.database1.table1; when permission requirements are met, it also supports arbitrary cross-Catalog table join queries. This eliminates the need for data import or creating external tables individually, improving the ease of access to external data.

Data import

• Load Data import URL CSV external table fault-tolerant mode

  When importing data via the Load Data method, issues such as data type incompatibility or precision mismatch would previously result in direct error reporting. The new version adds the LOG ERRORS directive for fault-tolerant import. In MySQL-compatible mode, it records failed rows, allowing you to view erroneous data via show warnings for error diagnosis.

V4.3.5 BP1

Version information

• Release date: March 18, 2025
• Version: V4.3.5 BP1

New features and enhancements

Data import and export

• Incremental direct load now supports heap tables with unique indexes

  Direct load is divided into full direct load and incremental direct load. When data already exists in the table, incremental direct load performs better than full direct load. Previously, incremental direct load did not support importing data into heap tables with unique indexes. The new version supports using incremental direct load to import data into heap tables with a local unique index.

• Direct load supports HASH partitioning and concurrent import of partitions

  Starting from V4.3.5 BP1, direct load at the partition level is supported for HASH partitions. Concurrent import of multiple partitions is also supported for incremental direct load. However, when multiple import tasks have overlapping partitions, parallel import of partitions is not supported.

• Performance optimization for direct load

  Through vectorization optimization, streamlining of temporary file processes, and computation performance optimization at various stages, the performance of importing data from a clickbench table has improved by 17% compared to V4.3.5.

External data source integration

• External tables support reading HDFS files

  HDFS is the most common storage medium in a data lake architecture and serves as a platform for multi-engine data sharing. Therefore, the new OceanBase version supports directly reading files on HDFS through external tables. It also supports accessing HDFS clusters with Kerberos authentication through relevant configurations.

• External tables support reading from and writing to MaxCompute (ODPS) data sources

  The new version supports reading data from MaxCompute through external tables or URL external tables, and also supports writing OceanBase data back to MaxCompute.

• URL external tables

  When OceanBase accesses external data sources, it usually requires creating an external table first, then using SQL queries. V4.3.5 BP1 introduces support for URL external tables, allowing you to directly query external CSV/Parquet/ORC and MaxCompute data using SELECT statements without creating an external table. On this basis, the LOAD DATA syntax has also been extended to directly reference URL external tables for data import, reducing the operational cost of data import.

Index optimization

• Enhancements to full-text indexes

  OceanBase has supported full-text indexes in MySQL-compatible mode since V4.3.1, with gradual functional supplements and expansions over versions. V4.3.5 BP1 adds a built-in Chinese IK tokenizer, supporting smart and max_word segmentation modes. Additionally, it supports adding tokenizers via plugins. Tokenizer attributes for full-text indexes are added, supporting table-level PARSER_PROPERTIES configuration. In addition to the existing natural language mode for full-text index queries, a boolean mode is added. You can enable it using the IN BOOLEAN MODE clause under MATCH AGAINST, supporting boolean operators and nested operations such as +, -, (), and no operator. This release also supports full-text indexes participating in index merge, improving query performance through the computation of index union merge. It also optimizes update/delete scenarios for full-text indexed columns of the primary table, accelerating update/delete performance.

Materialized view enhancements

• Materialized view enhancements

  The refresh parallelism of materialized views is closely related to the efficiency of incremental/full refresh. The new version supports a complete parallelism control mechanism, allowing you to set the refresh parallelism using the mview_refresh_dop system variable, the DBMS_MVIEW.refresh subprogram, or by specifying PARALLEL when creating the materialized view. The new version's incremental materialized views support the LOB type. It also provides the ability to directly modify materialized views or their attributes, using the ALTER MATERIALIZED VIEW/ALTER MATERIALIZED VIEW LOG command to modify the materialized view's parallelism, the time cycle for background refresh tasks, the parallelism for the MLOG table, the time cycle for background cleanup tasks of the MLOG table, and the LOB inline storage length threshold for MLOGs. Furthermore, after creating an MLOG on the base table, you cannot add columns to the base table; you must first delete the MLOG and then perform the DDL, which is quite complex. Therefore, the new version supports adding columns to the base table of an MLOG, including both adding columns at the end and in the middle. Additionally, the new version improves MLOG cleanup performance and optimizes error messages for incremental refresh.

Table structure and storage optimization

• Heap table organization mode

  OceanBase adopts a clustered index table model, which performs excellently in OLTP environments. It stores the primary key and the main table data in the same table, thereby optimizing primary key query speed and uniqueness verification performance. However, this model has certain limitations in OLAP scenarios that require efficient data import and complex data analysis. The import process requires sorting all data, and queries must perform primary key row fusion, both of which impact performance. The new version adds support for the heap table organization mode, where the primary key is used for uniqueness constraints, and queries rely on the main table. When user data is sorted by time, skip index can be utilized more effectively to improve query efficiency. Furthermore, decoupling the primary key from the data eliminates the need to sort the main table data during import, thereby improving data import performance.

Data types and storage optimization

• New String data type in MySQL-compatible mode

  Some AP workloads have a high tolerance for column length and often use variable-length string types to store data that serves as primary keys or indexes. In OceanBase Database, the char/varchar types can store strings and serve as primary keys or indexes, but require specifying a length. LOB types such as mediumtext/text can store variable-length strings but cannot be used as primary keys or indexes. To better meet AP workload requirements, a new String data type is introduced, which does not require specifying a length and has a default maximum size of 16 MB. When the column length is less than 16 KB and does not exceed lob_inrow_threshold, it can be used as a primary key or index.

• Enhancements to ARRAY type-related functions

  OceanBase Database supported the ARRAY data type in version 4.3.3 and provided support for some common functions and operators. The new version further enhances these functions, adding support for array_prepend, array_concat, array_compact, array_filter, array_sort, array_sortby, array_length, array_range, array_sum, array_first, array_difference, array_min, array_max, array_avg, array_position, array_slice, and reverse.

Parallel query optimization

• Decoupling PX compute nodes from data nodes

  In the current system architecture, storage resources and compute resources are highly coupled. The existing PX scheduling mechanism, for Non-Leaf DFO, only selects the machine where the data resides for task allocation. This tight coupling limits the full utilization of machine resources in certain scenarios. To enable large SQL queries to leverage more machines for computation, the new version supports decoupling PX compute nodes from data nodes. The candidate resource pool for Non-Leaf DFO is determined via configuration parameters or the PX_NODE_POLICY hint. Additionally, hints (PX_NODE_ADDRS, PX_NODE_COUNT) are provided to forcibly specify the exact machine or number of machines allocated to Non-Leaf DFO.

Query optimization and pushdown

• Support for query pushdown in row-store data with added columns

  During a row-store SCAN, if there is no intersection of data—meaning no data with the same rowid exists in the major SSTable or elsewhere—the scan is pushed down to the storage layer. After a major compaction, when new columns are added, theoretically, the scan can be pushed down. However, parsing failures of the new columns could cause the pushdown to fail, reverting to the less efficient row-by-row read. The new version provides special optimization for this scenario, supporting query pushdown to the storage layer to improve query performance.

Columnar storage optimization

• Columnar replica optimization

  The columnar replica feature introduced in V4.3.3 had some limitations, such as supporting only a single C replica, inability to directly import full columnar data into a C replica, and insufficient user usability. The new version addresses these limitations: a cluster now supports specifying multiple C replicas, direct full bypass import of columnar data into a C replica is supported, and a system view CDB/DBA_OB_CS_REPLICA_STATS has been added to display conversion progress for partition-level and log stream-level columnar replicas, facilitating user observation of columnar replica status.

Behavioral changes

• Disabling NLJ in AP parameter templates

  After the optimizer generates a nested loop join plan, it is sensitive to the number of rows in the driving table. If the estimated number of rows in the driving table is too low, the actual execution performance of the plan may significantly degrade. In OLAP scenarios, data volumes are generally large, and the benefits of using a nested loop join plan are limited. Therefore, in AP scenarios, the behavior is modified to generate a hash join plan by default, with nested loop join plans generated only for non-equal join scenarios.

V4.3.5

Version information

• Release date: December 31, 2024
• Version: V4.3.5

New features and enhancements

Materialized view enhancements

• Support for nested materialized views

  In versions earlier than V4.3.5, you could only create materialized views on regular user tables. In data warehouse scenarios, materialized views are used for data processing. To better support lightweight real-time data warehouse scenarios, V4.3.5 allows you to create new materialized views based on existing ones, known as nested materialized views. Nested materialized views support the same refresh methods as non-nested ones, including complete and incremental refresh. Therefore, V4.3.5 supports creating materialized view logs based on materialized views. The freshness of data in a nested materialized view depends on the freshness of the base table data. To ensure the freshness of data in the upper-level materialized view, you must first refresh the underlying materialized view.

  For more information, see the section on creating nested materialized views in Create a materialized view (MySQL-compatible mode) or Create a materialized view (Oracle-compatible mode).

Data import and export

• Support for direct load of specified partitions

  In versions earlier than V4.3.5, OBServer only supported using the direct load path for full-table data imports to accelerate the process. If you wanted to import data from only some partitions, you had to use partition exchange, which involved first importing the partition data into a non-partitioned table via a full direct load, and then performing a partition exchange between the corresponding non-partitioned table and the target partition. This operation was cumbersome for users. To better support partition-level data import, V4.3.5 allows you to use the LOAD DATA and INSERT INTO SELECT syntax to specify partitions for the direct load path, but it does not support specifying partitions whose last-level partition type is Hash/Key.

  For more information, see Full direct load or Incremental direct load.

• Enhancements to the SELECT INTO OUTFILE feature

  V4.3.5 improves the SELECT INTO export functionality, supporting exports to Parquet and ORC formats, and allowing you to specify a compression algorithm when exporting to CSV format. New syntax has been added for SELECT INTO.

  • Use the FORMAT clause to set export options.
  • Specify a compression algorithm when exporting a CSV file.
  • Export files in Parquet format.
  • Export files in ORC format.

Index enhancements

• Enhancements to full-text indexing

  Building upon V4.3.4, V4.3.5 continues to improve the full-text indexing feature, mainly including:

  • Supports creating full-text indexes using the CREATE FULLTEXT INDEX or ALTER TABLE ADD FULLTEXT INDEX statement.
  • Supports cost-based selection of full-text index execution plans. For SQL statements containing multiple MATCH AGAINST filters, it can select the index with lower cost for scanning.
  • Supports Functional Lookup:
    • Supports multiple MATCH AGAINST expressions in query statements.
    • Supports using other indexes while searching via a full-text index.
    • Supports outputting MATCH AGAINST without filter semantics as projection columns.
    • Supports filtering with filter semantics MATCH AGAINST using symbols like <=/<.
    • Supports logical AND/OR chaining of filter semantics MATCH AGAINST with other filter semantics.

  For more information, see MATCH AGAINST.

External data source integration

• External table enhancements

  In V4.3.5, external tables support reading ORC format files.

  For more information, see Create an external table (MySQL-compatible mode) or Create an external table (Oracle-compatible mode).

Columnar storage optimization

• Read-only columnstore replicas

  The read-only columnstore replica feature supported in V4.3.3 was an experimental feature. After iterations in V4.3.4 and V4.3.5, this feature has met the General Availability requirements in V4.3.5.

• Asynchronous online DDL for row-to-column conversion

  V4.3.0 supported three storage formats for tables: rowstore, pure columnstore, and hybrid row-column. Converting a rowstore table to a hybrid row-column table or a columnstore table required offline DDL. To reduce the impact of offline DDL on customers, V4.3.5 supports asynchronous online conversion from rowstore to columnstore. By specifying the delayed keyword during DDL execution, you can modify table schema information in real time without blocking user data writes, achieving online conversion. Subsequent reorganization of baseline data is executed asynchronously during a major compaction. V4.3.5 supports converting rowstore tables to columnstore tables and converting rowstore tables to hybrid row-column tables as online DDL operations.

Performance optimization

• Vectorization of direct load write paths

  Prior to V4.3.5, direct load implementation lacked vectorization; write functions processed data row by row, resulting in significant function call overhead. Moreover, writing SSTables was a background process, and some operations were not optimized specifically. V4.3.5 vectorizes the direct load path and optimizes columnstore encoding, thereby improving direct load performance. Verification shows that direct load performance in scenarios without primary key columnstore tables can be optimized by about 2 times.

Data type and storage optimization

• JSON multi-valued indexes support complex DML

  V4.3.5's JSON multi-valued indexes improve support for complex DML statements. They now support multi-valued predicates in statements like UPDATE and DELETE, and also support complex DML involving multi-valued index lookups.

• Support for richer array expressions

  OceanBase Database supported the ARRAY data type in V4.3.3. To better support business use cases for the ARRAY type, V4.3.5 supports more array expressions to meet diverse business scenario needs. The new version introduces array expressions such as array_append, array_distinct, arrayMap, array_remove, cardinality, element_at, array_contains_all, array_overlaps, array_to_string, array_agg, unnest, and rb_build.

V4.3.4

Version information

• Release date: October 31, 2024
• Version: V4.3.4

New features and capability enhancements

Index capability enhancements

• Full-text index capability enhancements

  OceanBase Database has supported full-text indexing since V4.3.1. By preprocessing text content and creating keyword indexes, it effectively improves full-text search efficiency. However, there were still some limitations in complex DML scenarios involving full-text indexes, which caused inconvenience for businesses. To better support business development, V4.3.4 enhances complex DML functionality. For primary tables containing full-text indexes, it now supports complex DML operations such as INSERT INTO ON DUPLICATE KEY, REPLACE INTO, multi-table update and deletion, and updatable views. Additionally, the new version optimizes full-text search performance through methods like vectorized execution and extended TAAT processing strategies. It also removes the token count limit for the MATCH AGAINST predicate, supporting the creation of full-text indexes on partitioned tables without primary keys. Furthermore, the new version supports viewing tokenization results using the tokenize function, aiding in debugging tokenization systems.

  For more information, see Create a multi-valued index.

• Enhancements to multi-valued indexes

  Currently, multi-valued indexes only support pre-created indexes, and there are some limitations on operations such as DML and DDL. To better support business use, V4.3.4 has lifted some usage restrictions and enhanced the functionality. The main enhancements include support for complex DML operations, including INSERT INTO ON DUPLICATE KEY, REPLACE INTO, multi-table updates/deletes, and DML functions on updatable views.

Data import optimization

• Incremental direct load now supports non-unique local indexes

  OceanBase supports full direct load and incremental direct load. When data already exists in a table, incremental direct load performs better than full direct load. Previously, incremental direct load did not support importing data into tables with indexes. V4.3.4 adds support for importing data into tables with non-unique local indexes during incremental direct load.

• Direct load performance optimization

  During direct load, for tables with primary keys that require sorting, data is first written to temporary files, then loaded into memory for sorting and merging, and finally written to SSTables. This method divides data import into two phases: the write phase and the sort-merge phase. If data is not fully written, the subsequent sort-merge phase cannot begin; if write I/O reaches a bottleneck, it will indirectly cause a bottleneck in direct load performance. V4.3.4 optimizes the data import method by writing data directly into memory instead of temporary files, followed by subsequent sorting and merging. After the optimization, data import and sorting are performed in a pipelined manner, avoiding the impact of one phase on the next. In primary key table scenarios, for a data volume of 1 TB, the overall import performance improves by 35%, showing significant optimization effects. The larger the memory and CPU, the greater the performance improvement during data processing and rotation. Therefore, this optimization is particularly suitable for large-specification tenant scenarios. Meanwhile, it does not cause a noticeable performance regression for small-specification tenants.

Data type and storage optimization

• Bitmap feature enhancements

  Bitmap, also known as a bitmap, is a data structure used to efficiently store and process whether an element exists in a set. OceanBase V4.3.2 and V4.3.3 successively supported some features of RoaringBitmap. V4.3.4 continues to improve this by adding the rb_iterate and rb_select expressions. rb_iterate is used to expand a RoaringBitmap type into a multi-row column based on the number of elements. rb_select is used to filter elements within a RoaringBitmap type based on conditions and return a new RoaringBitmap type.

V4.3.3

Version information

• Release date: September 30, 2024
• Version: V4.3.3

New features and enhancements

Columnar storage optimization

• Read-only columnstore replicas (Experimental feature)

  OceanBase Database V4.3.0 introduced support for columnar storage. Depending on the business type, users can choose to create columnstore tables, rowstore tables, or hybrid row-column tables. Regardless of the table type defined, the replica mode is consistent across different zones of a tenant. For example, if tenant X has a unit distribution of 1:1:1 and Table T1 is a hybrid row-column table, then Table T1 will have one rowstore replica and one columnstore replica in each of the three zones. To meet the requirement for strong physical isolation of TP and AP resources in HTAP mixed-workload scenarios, V4.3.3 introduces a new deployment model that supports expanding a separate zone to store read-only columnstore replicas (Column Store Replica, abbreviated as C-replicas) on top of the original cluster. In this zone, all user tables are stored in columnar format. AP workloads can use an independent ODP and set the routing strategy to COLUMN_STORE_ONLY via the session-level system variable ob_route_policy to access columnstore replicas for weak-consistency query analysis without affecting the original TP workloads. Additionally, a deployment model like 3+1 zones saves some storage overhead compared to hybrid row-column storage. This feature requires ODP V4.3.2 or later. For more details, see Columnstore replicas.

  V4.3.3 defines this feature as experimental and will continue to refine it into a formal production feature in subsequent versions.

Materialized view enhancements

• Materialized view capability enhancements

  To reduce the cost of manual business rewrite, OceanBase Database V4.3.1 introduced support for materialized view rewrite capability. When the system variable QUERY_REWRITE_ENABLED is set to True, you can specify ENABLE QUERY REWRITE when creating a materialized view to use automatic rewrite. The system can then rewrite queries from the original table into queries for the materialized view. V4.3.1 supported rewriting for non-aggregated materialized views where the FROM clause fully matched and the WHERE clause partially matched. V4.3.3 further supports rewriting for non-aggregated materialized views with FROM join compatibility, queries containing tables not present in the materialized view, and supports rewriting for aggregated materialized views and aggregation rollup.

  The new version also extends the SQL types supported for incremental refresh and real-time materialized views. Earlier versions already supported incremental refresh and real-time query for single-table aggregation and multi-table join scenarios. V4.3.3 adds support for join aggregation scenarios. For more details, see Materialized view query rewrite (MySQL-compatible mode) and Materialized view query rewrite (Oracle-compatible mode).

  Furthermore, previous versions of OceanBase Database only supported materialized views in row storage format. Starting from V4.3.3, support for materialized views in column storage format will be extended, potentially providing better query performance in some complex analytical scenarios that partially contain materialized view references. For more details, see Create a materialized view (MySQL-compatible mode) and Create a materialized view (Oracle-compatible mode).

Data import and export optimization

• External table import performance optimization

  V4.3.3 optimizes the execution performance of the data reading phase from external tables during direct load, improving performance by approximately 15% compared to the previous version.

• INSERT OVERWRITE capability enhancement

  OceanBase Database V4.3.2 introduced support for table-level overwrite capability (INSERT OVERWRITE), which atomically clears old data and writes new data within a table to support AP business scenarios such as periodic data refresh, data transformation, and data cleansing and correction. However, V4.3.2 only supported full-table replacement writing, without providing partition-level replacement writing or the ability to specify partial columns for replacement writing. V4.3.3 complements and improves this feature, supporting the specification of target tables as partitions or subpartitions in INSERT OVERWRITE statements, and also supports specifying partial column information for the target table, making the data replacement writing method more flexible and applicable to more business scenarios.

• Load Data/external table support for compressed files

  Load Data is a commonly used data import method, including scenarios such as regular server-side import, direct load, and client-side import, all of which can import formatted text files into the database. However, previous versions only supported regular text files; compressed files like GZIP required decompression before import, making the operation more complex. The new version now supports importing compressed files, allowing GZIP, DEFLATE, and ZSTD format compressed files to be loaded, decompressed, and written simultaneously. Furthermore, CSV external tables now also support compressed files, enabling direct querying of data from these compressed formats by accessing the external table.

Data type and storage optimization

• ARRAY data type

  ARRAY is a complex data type commonly used in AP workloads, capable of storing multiple elements of the same type. It is an appropriate choice when managing and querying multi-valued attributes that cannot be effectively represented by relational data. OceanBase Database V4.3.3 begins supporting the ARRAY type in MySQL-compatible mode. When creating a table, you can define a column as an array of numeric or character type, and nested arrays are allowed. It supports constructing expressions for querying or writing to array objects, supports the array_contains expression and the ANY operator to determine whether an element is contained in the array, and also supports operators such as +/-/=/!= for array element calculation and judgment.

• RoaringBitmap performance optimization

  V4.3.2 introduced support for the RoaringBitmap data type and related expressions to support multidimensional analysis requirements in business scenarios such as user profiling, personalized recommendations, and precision marketing. However, performance was suboptimal in some scenarios. The new version focuses on analyzing the performance issues of RoaringBitmap type calculations, optimizing memory allocation and expression execution logic, and streamlining unnecessary performance overhead, significantly improving execution performance in cardinality, and/or/xor/andnot, and aggregation scenarios by several times.

Resource management and isolation

• Query-level resource group configuration

  OceanBase Database currently supports configuring user-level, background task-level, and column parameter-level resource groups using the DBMS_RESOURCE_MANAGER system package to achieve CPU and IOPS resource isolation. V4.3.3 introduces the capability to bind resource groups at the query level. By specifying the /*+ resource_group('group_name') */ hint in an SQL statement, you can force that statement to use the resources of the specified resource group. If the resource group does not exist, the current default resource group is used. When switching resource groups, the session needs to reconnect for the change to take effect.

V4.3.2

Version information

• Release date: July 16, 2024
• Version: V4.3.2 Beta

New features and enhancements

Data import and export optimization

• Enhancements to incremental direct load

  Starting from V4.3.1, incremental direct load was supported as an experimental feature, but it had some limitations. For example, it did not support importing data with OUTROW LOB, and only incremental direct load with load_mode set to inc_replace (i.e., REPLACE) was supported. V4.3.2 adds support for incremental direct load of OUTROW LOB data and extends the value of load_mode to include inc. The default is INSERT semantics, which behaves as IGNORE semantics when the ignore keyword is specified in the SQL statement. This is now a formal feature release. For more detailed usage information, see Use the LOAD DATA statement for direct data import and Use the INSERT INTO SELECT statement for direct data import.

• Performance optimization for full direct load

  In full direct load scenarios, the new version improves performance by reducing column type conversion operations during data loading, lowering CPU usage for statistics collection, removing the primary key generation logic on the SELECT side in INSERT INTO SELECT, and disabling sum skip index by default for column storage (which pre-aggregates SUM values for specified columns within a storage layer range). Combined with disabling microblock verification (setting the micro_block_merge_verify_level parameter to 0), direct load performance improves by about 20%.

• SELECT INTO OUTFILE partition export

  OceanBase currently supports exporting multiple files using the SELECT INTO OUTFILE statement, but does not support exporting data by partition. The new version adds the ability to export by partition for a clearer directory structure. Furthermore, this structure can be used to construct a partitioned external table, improving external table query efficiency through partition pruning.

External data source integration

• External table enhancements

  OceanBase Database has long supported CSV format external tables. However, as AP business expanded, it became evident that reading Parquet format external data sources was also a common requirement in data lake scenarios. Starting from V4.3.2, OceanBase supports Parquet file external tables. Users can import data from files into internal OceanBase tables via external tables, or directly use external tables for cross-data-source joint query analysis. To ensure the timeliness of the file directories scanned by external tables, the new version adds automatic file directory refresh functionality. When creating an external table, you can specify the refresh method (manual, real-time, periodic) for the file list using the AUTO_REFRESH option, and manage scheduled refresh tasks using the DBMS_EXTERNAL_TABLE.REFRESH_ALL_TABLE (with interval int) system package. For more detailed usage information, see Create an external table.

Performance optimization

• AP typical scenario performance optimization

  V4.3.2 provides comprehensive strategy optimizations for data block prefetching, vectorized batch processing, filter pushdown, comparison computation, aggregation computation, DTL shuffle, and monotonicity filters. Under a 100GB data volume specification, benchmark test performance in various AP scenarios such as TPCH, TPCDS, and ClickBench improves by approximately 10% to 15% compared to V4.3.1.

Data type and storage optimization

• RoaringBitmap

  With the advent of the big data era, enterprises have an increasing demand for user data mining and analysis. RoaringBitmap, with its space-saving and efficient computing characteristics, plays an important role in business scenarios such as user profiling, personalized recommendations, and precision marketing. Starting from OceanBase V4.3.2, the MySQL-compatible mode supports the RoaringBitmap data type. By storing and operating on a set of unsigned integers, it enhances large-scale dataset set computation and deduplication performance. To meet multi-dimensional analysis needs, this version supports over twenty expressions for cardinality calculation, set operations, bitmap checking, bitmap construction, bitmap output, and aggregation operations.

Data operation optimization

• Table-level overwrite

  In data warehouses, scenarios involving regular data refresh, data transformation, and data cleansing often require table-level overwrite. OceanBase V4.3.2 introduces table-level overwrite capability (INSERT OVERWRITE), which atomically clears old data and writes new data into a table. Based on full direct load capability, INSERT OVERWRITE also demonstrates high execution performance. V4.3.2 supports the syntax INSERT OVERWRITE tablename SELECT * FROM tablename; partition-level overwrite is not currently supported and will be provided in a later version.

Task scheduling and asynchronous execution

• Asynchronous task scheduling

  OceanBase Database currently supports various data import commands, such as INSERT OVERWRITE, INSERT SELECT, CREATE TABLE AS, and LOAD DATA, to support real-time data ingestion. However, the real-time import method requires waiting for the import to complete during the process and does not allow session interruption, which makes it less practical for large-scale data import scenarios. The new version leverages DBMS_SCHEDULER to provide asynchronous task scheduling capabilities. Users can now use commands like SUBMIT JOB, SHOW JOB STATUS, and CANCEL JOB to create asynchronous import tasks, query their status, and cancel tasks.

V4.3.1

Version information

• Release date: May 17, 2024
• Version: V4.3.1 Beta

New features and enhancements

Materialized view enhancements

• Materialized view enhancements

  OceanBase Database V4.3.0 introduced materialized views, which precompute and store query results to reduce real-time computation and improve query performance. This simplifies complex query logic and meets requirements in application scenarios. Building on this foundation, V4.3.1 extends support for real-time materialized views, providing real-time computing capabilities based on both materialized view and MLOG data. This is suitable for analytical workloads with high real-time requirements. The version adds primary key constraints for materialized views, allowing users to specify a primary key for a materialized view to optimize performance for single-row searches, range queries, or join scenarios based on the primary key. It also extends support for incremental updates of materialized views in inner join scenarios, improving materialized view refresh performance in some cases.

  Additionally, when using materialized views in V4.3.0, you needed to manually rewrite accesses to the original table in business scripts to queries for the corresponding materialized view, introducing a manual rewriting cost. The new version supports materialized view rewriting in some scenarios. When the system variable QUERY_REWRITE_ENABLED is set to True, you can use the automatic rewriting capability for materialized views by specifying ENABLE QUERY REWRITE when creating a materialized view. In this case, the system can rewrite queries for the original table into queries for the materialized view, reducing the amount of business modification required. For more information about automatic materialized view rewriting, see Materialized view query rewriting (MySQL-compatible mode) and Materialized view query rewriting (Oracle-compatible mode).

Data import and export optimizations

• Incremental direct load (Experimental)

  OceanBase Database has supported the direct load feature since V4.1.0. By streamlining the data loading execution path, skipping modules such as SQL, transactions, and memtables, and directly persisting data as SSTables, it significantly improves data import efficiency. However, in scenarios where table data needs to be imported multiple times, each import requires rewriting the existing data in the table, affecting the performance of incremental imports. V4.3.1 specifically optimizes incremental import scenarios. Incremental direct load does not require rewriting the original data; it only processes new data, making multiple imports as efficient as the first one. You can use the /*+ direct(need_sort, max_errors_allowed, load_mode)*/ hint in LOAD DATA and INSERT INTO SELECT statements to specify whether to use the incremental direct load feature. If load_mode is not specified or is set to full, the original full direct load method is used. Setting load_mode to inc_replace uses the incremental direct load method. This feature is defined as an experimental feature in V4.3.1 and will continue to be expanded and evolved into a production-ready feature in later versions. For more information about incremental direct load, see Incremental direct load.

• SELECT INTO OUTFILE performance optimization

  Although the existing select into outfile function supports parallel reading from data tables, it can only write serially to external files, creating a performance bottleneck for data export. V4.3.1 adds parallel export capability by introducing the single and max_file_size options to the select into outfile command, controlling how data is written to external files. The single option controls whether data is exported to a single file or multiple files. When the specified degree of parallelism is greater than 1 and single = false, data can be exported to multiple files, achieving parallel read and parallel write. The max_file_size option controls the size of the export file.

Index enhancements

• Full-text index in MySQL-compatible mode (Experimental)

  Relational databases typically use indexes to accelerate queries based on exact value matching. However, ordinary B-tree indexes cannot be applied to scenarios involving large amounts of text data that require fuzzy retrieval. In such cases, a full table scan is necessary to perform a fuzzy search on each row, and performance often fails to meet requirements when the text is large or the data volume is high. Other complex query scenarios, such as approximate matching or relevance sorting, are also difficult to support through SQL rewriting.

  To address these issues, OceanBase Database supports the full-text index feature in V4.3.1. By preprocessing text content and establishing keyword indexes, it effectively improves full-text search efficiency. This feature is defined as an experimental feature in V4.3.1 and will continue to be expanded and evolved into a production-ready feature in later versions. This release includes the following functionality:

  Full-text index support in MySQL-compatible mode, compatible with basic MySQL syntax;

  • Supports pre-building full-text indexes on CHAR/VARCHAR/TEXT columns during table creation;
  • Applicable to partitioned tables;
  • Supports creating multiple full-text indexes on a primary table;
  • Supports three built-in tokenizers: SPACE (space), NGRAM, and BENG (basic English);
  • Supports performing a full-text search on multiple columns with one match against;
  • Supports the NATURAL LANGUAGE MODE.

Partition management

• Partition exchange

  Over time, tables may accumulate large amounts of historical data. This data may not need frequent access but must be retained to meet compliance or historical data analysis requirements. To improve query performance, businesses often need to distinguish between active and inactive data and archive the inactive data. Migrating data to a new table via SQL can solve this scenario requirement, but performance is often suboptimal for large data volumes. Therefore, OceanBase Database V4.3.1 introduces the partition exchange feature. By modifying the definitions of partitions and tables in the data dictionary without requiring physical data replication, it can move data from table A to a partition of table B almost instantaneously, greatly improving data migration performance. This release includes the following functionality:

  • Supports data exchange between a partition of a partitioned table and a non-partitioned table.
  • Supports a RANGE (Range Columns) type for a partitioned table.
  • Supports a RANGE (Range Columns) type for a subpartition of a subpartitioned table.
  • Supports the including indexes behavior, meaning that when partitions are exchanged, the corresponding local indexes are also exchanged and remain available after the exchange.
  • Supports the without validation mode, requiring users to ensure data falls within the partitioning key range.

External data source integration

• External table partitioning

  Starting from OceanBase Database V4.2.0, external tables are supported, but they are limited to non-partitioned tables. In scenarios where a large number of files exist, but a query theoretically only needs to scan a portion of the data files, a non-partitioned external table could only scan all files, making it inefficient due to lack of pruning. V4.3.1 introduces external table partitioning, supporting a partitioning method similar to LIST partitioning in regular tables, and provides both automatic and manual partition creation syntax. When specifying automatic partition creation, the system groups files by partition according to the partitioning key definition. When specifying manual partition creation, users must specify the subpath of the data file for each partition. In this case, external table queries can implement partition pruning based on partition conditions, reducing the number of files scanned and significantly improving query performance.

Data types and storage optimization

• MySQL-compatible mode JSON multi-valued index (Experimental)

  Starting from MySQL 8.0, multi-valued indexes are supported, applicable to JSON documents and other collection data types. This allows users to build indexes on arrays or collections for efficient element retrieval. OceanBase Database V4.3.1 is compatible with the JSON multi-valued index feature in MySQL-compatible mode, enabling the creation of efficient secondary indexes on JSON array fields containing multiple elements. This enhances querying capabilities for complex JSON data structures, balancing data model flexibility with high-performance data queries. This feature is defined as an experimental feature in V4.3.1 and will continue to be expanded and evolved into a production-ready feature in later versions. The current version includes the following features:

  • Supports pre-creation of multi-valued indexes and composite multi-valued indexes.
  • Supports unique and non-unique multi-valued indexes.
  • Supports creating multi-valued indexes where the JSON array element types are INT, UINT, DOUBLE, FLOAT, CHAR, etc.
  • Applicable to partitioned tables.
  • Supports using multi-valued indexes for queries with the MEMBER_OF(), JSON_CONTAINS(), and JSON_OVERLAPS() functions.

• MySQL JSON Partial Update

  Some users use JSON documents to store business data. When updating a document, the current approach requires full read followed by full update, which cannot meet performance expectations for large documents. V4.3.1 introduces support for JSON Partial Update. When users update partial fields of a JSON document using specific expressions (json_set/json_replace/json_remove), only the modified parts need to be updated, eliminating the need for a full overwrite and improving update performance. This feature requires enabling it via the log_row_value_options configuration parameter.

Query execution and resource management

• SQL temporary result compression

  When the amount of data involved in SQL execution is too large, insufficient memory may occur, forcing some operators to materialize temporary intermediate results. If the materialized data volume is too large and disk space is full, SQL execution will fail. V4.3.1 introduces SQL temporary result compression, allowing you to specify whether temporary results should be compressed and the compression algorithm via tenant-level configuration parameter spill_compression_codec or SQL-level hints (e.g., /*+opt_param('spill_compression_codec', 'lz4') */). Specifying temporary result compression can effectively reduce temporary disk space usage, supporting query tasks with larger computational loads.

V4.3.0 Beta

Version information

• Release date: March 22, 2024
• Version: V4.3.0 Beta

New features

• Columnar storage engine

  In scenarios involving complex analysis of large-scale data or ad-hoc queries on massive datasets, columnar storage is a key capability for AP databases. Columnar storage is a method of organizing data files that differs from row-based storage by physically arranging table data by columns. When data is stored in a columnar format, the system can scan only the columns required for query computation during analysis, avoiding full-row scans and reducing resource consumption such as I/O and memory usage, thereby improving computation speed. Additionally, columnar storage inherently provides better conditions for data compression, making it easier to achieve higher compression ratios, which reduces storage space and network transmission bandwidth.

  However, common columnar storage engines are often implemented assuming minimal random updates and strive to keep the data organized in a static manner. When a large amount of random data updates do occur, system performance issues are inevitable. OceanBase's LSM-Tree architecture allows for separate processing of baseline data and incremental data, perfectly addressing this scenario. Therefore, V4.3.0 builds upon the existing architecture to further support the columnar storage engine, integrating columnar and row-based data storage within a single codebase, single architecture, and single OBServer, balancing both TP and AP query performance.

  To facilitate AP business migration and ensure smooth adoption of the new version for existing customers, extensive adaptation and optimization have been made across multiple modules, from the optimizer and executor to DDL and transaction processing. These include a new cost model and vectorized engine based on columnar storage, extended and enhanced query pushdown functionality, Skip Index, a new columnar encoding algorithm, and adaptive compaction.

  For businesses, users can flexibly configure tables as row-based tables, columnar tables, or hybrid row-column redundant tables based on workload type. For more information about the columnar storage engine, see Columnar storage.

• New vectorized engine

  OceanBase implemented a vectorized engine based on the Uniform data description method in earlier versions, which significantly improved performance compared to non-vectorized engines. However, it still had some performance shortcomings in deep AP scenarios. V4.3.0 implements Vectorized Engine 2.0, which switches to a Column data format description, eliminating the memory usage, serialization, and read/write access overhead associated with maintaining ObDatum. Based on this data format description refactoring, the new version has also reimplemented a batch of commonly used operators and expressions, such as over 10 operators including HashJoin, AGGR, HashGroupBy, and Exchange (DTL Shuffle), and over 20 MySQL expressions including relational operations, logical operations, and arithmetic operations. Subsequent V4.3.x versions will continue to supplement and improve the implementation of other operators and expressions based on the new vectorized engine to achieve better performance in AP scenarios.

• Materialized view

  V4.3.0 introduces the Materialized View feature. Materialized views are a key capability for supporting AP business. By precomputing and storing the query results of views, they reduce real-time computation to improve query performance and simplify complex query logic. They are commonly used in rapid report generation and data analysis scenarios.

  Since materialized views need to store query result sets to optimize query performance, and there is a data dependency between a materialized view and its base tables, the data in the materialized view must be updated accordingly whenever data in the base tables changes to maintain synchronization. Therefore, the new version also introduces a materialized view refresh mechanism, which includes two strategies: complete refresh and incremental refresh. Complete refresh is a more straightforward approach. Each time a refresh operation is performed, the system re-executes the query statement corresponding to the materialized view, completely recalculates and overwrites the original view result data. This method is suitable for scenarios with relatively small data volumes. In contrast, incremental refresh only processes the portion of data that has changed since the last refresh. To enable precise incremental refresh, OceanBase has implemented a materialized view log function similar to Oracle MLOG (Materialized View Log), which tracks and records incremental update data of the base tables in detail through logs, ensuring the materialized view can be refreshed quickly and incrementally. The incremental refresh method is particularly suitable for business scenarios with large data volumes and frequent changes. For more information about materialized views, see Materialized view (MySQL-compatible mode) and Materialized view (Oracle-compatible mode).