AP Version Update History

This topic lists only the changes to core capabilities related to real-time analytics. For a complete list of feature enhancements and iterations across all OceanBase Database versions, see Release Notes.

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, newly supporting complex query patterns such as outer joins, UNION ALL, non-aggregated single tables, and aggregated queries with LEFT JOIN. The processing of MIN/MAX aggregate functions is strengthened, supporting duplicate SELECT ITEM 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 O&M 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 cross-system metadata ambiguity issues.

• 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 capabilities, 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

• Enhancement to materialized views

  V4.3.5 BP5 adds support for incremental refresh of aggregated materialized views with left joins, supports creating nested materialized views based on incremental materialized views without primary keys, supports using non-basic column parameters for MIN/MAX aggregate functions in aggregated incremental materialized views, supports referencing regular views declared as dimension tables (AS OF PROCTIME()) in incremental materialized views of multi-table joins, supports using UDFs in full refresh of materialized views, supports the minimal refresh mode for incremental refresh of materialized views (incremental refresh DML only needs to read/write data from necessary columns of the columnar table), and supports refreshing materialized views using persisted session variables.

• 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 through the tenant-level parameter default_skip_index_level.

• Expansion of partition exchange functionality

  Before 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, and between a RANGE/RANGE COLUMNS partition of a subpartitioned table and a partition of a 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

• Enhancement to materialized views

  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 materialized view 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

Optimization of external data sources and integrations

• ODPS external table adaptation to Storage API

  For ODPS external tables based on the Tunnel API, each partition scan during execution required starting a separate session, which introduced second-level latency. This caused some queries that were otherwise very fast to consume time on session preparation. In addition to the Tunnel API, ODPS provides an open Storage API that allows direct access to ODPS' 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

• Enhancements to materialized view functionality

  The new version continues to improve materialized view capabilities. This primarily includes support for RENAME on materialized views, incremental refresh support for outer joins, UNION ALL, and non-aggregated single tables, column addition support for materialized view logs, 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 exchanging 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

• Enhanced statistics

  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 approach 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 results in 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 columnar tables

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

Performance optimizations

• Performance optimization for direct load of heap tables

  Optimized the uniqueness verification process during the creation of a unique index 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 to use hard parsing can reduce the occurrence 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 in 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 where the base table is an external table in full refresh scenarios, expanding the applicability of 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 refresh and purge of materialized views 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 set a resource cap for materialized view tasks.

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 regularly 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 business operations. Therefore, the new version provides dynamic partition management functionality. By specifying dynamic partition management attributes 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 methods. To achieve self-explanability, each record redundantly stores some data metadata, resulting in low storage compression rates. JSON, a typical semi-structured data format, has 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 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 data, implementing the corresponding encoding method to reduce storage space usage and optimize query filtering performance for JSON subcolumns. However, since JSON is split into multiple subcolumns for storage, this introduces major compaction overhead and performance regression for scenarios that require frequent reads of raw JSON data. Whether to enable this feature should be determined based on the business type.

Query execution

• Adaptive plan cache

  The plan cache is a critical capability in TP scenarios and is therefore enabled by default. In some AP scenarios, however, the plan execution time can be many times longer than the plan generation time. In such cases, letting the optimizer generate a new plan each time often yields a better execution plan than reusing an existing one, leading to improved performance. In different scenarios, especially HTAP mixed-workload scenarios, there is a need to provide a way for AP-heavy SQL statements to undergo hard parsing while TP-heavy SQL statements 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 statement 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 Database'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 about 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 accessing external data.

Data import

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

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

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 performance optimization of computations at various stages, the import performance of the 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 and then using SQL queries. V4.3.5 BP1 introduces support for URL external tables. You can 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 index functionality

  OceanBase Database has supported full-text indexes in MySQL-compatible mode since V4.3.1, with gradual functional supplements and expansions over subsequent versions. V4.3.5 BP1 introduces a built-in Chinese IK tokenizer, supporting two segmentation modes: smart and max_word. Additionally, it now supports adding tokenizers via plugins. Full-text indexes support tokenizer attributes, with table-level PARSER_PROPERTIES configuration. In addition to the existing natural language mode for full-text index queries, a boolean mode has been added. It can be enabled 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 optimizes update/delete scenarios for full-text indexed columns in primary tables, 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. Incremental materialized views in the new version support the LOB type. It also provides the ability to directly modify materialized views or their attributes, using commands like ALTER MATERIALIZED VIEW/ALTER MATERIALIZED VIEW LOG 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 main table data in the same table, optimizing primary key query speed and uniqueness verification performance. However, this model has 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 data eliminates the need to sort 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 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, 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 workloads' needs, a new String data type is introduced, which does not require specifying a length and has a default maximum size of 16 MB. When a column's length is less than 16 KB and does not exceed lob_inrow_threshold, it can serve as a primary key or index.

• Enhancements to ARRAY type-related functions

  OceanBase Database supported the ARRAY data type in version 4.3.3, along with some common functions and operators. The new version further improves 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, for data without intersection—where no rowid matches between the major SSTable and other sources—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, thereby improving 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, allows direct full bypass import of columnar data into a C replica, and introduces the system view CDB/DBA_OB_CS_REPLICA_STATS to display conversion progress for partition-level and log stream-level columnar replicas, facilitating user monitoring of columnar replica status.

Behavioral changes

• AP parameter template disables NLJ

  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 default behavior is changed to generate a hash join plan, 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 prior to V4.3.5, materialized views could only be created on 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 supports creating new materialized views based on existing ones, known as nested materialized views. Nested materialized views support the same refresh methods as non-nested materialized views, 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 prior to V4.3.5, OBServer only supported using the direct load path for full-table data imports to accelerate the import process. If you wanted to import data from only a subset of partitions, you had to perform a partition exchange operation: first, use a full direct load to import the partition data into a non-partitioned table, then perform a partition exchange between the corresponding non-partitioned table and the target partition. This process was cumbersome for users. To better support partition-level data import, V4.3.5 supports specifying partitions to use the direct load path with the LOAD DATA and INSERT INTO SELECT syntax, but 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 indexes

  Building upon V4.3.4, V4.3.5 continues to refine the full-text index functionality, mainly including:

  • Support for creating full-text indexes using the CREATE FULLTEXT INDEX or ALTER TABLE ADD FULLTEXT INDEX statement.
  • Cost-based selection of full-text index execution plans. For SQL statements containing multiple MATCH AGAINST filters, it now supports selecting the index with lower cost for scanning.
  • Support for Functional Lookup:
    • Supports multiple MATCH AGAINST expressions in query statements.
    • Supports using other indexes alongside full-text indexes.
    • Supports outputting MATCH AGAINST without filter semantics as projection columns.
    • Supports filtering with filter-semantic MATCH AGAINST using symbols like <=/<.
    • Supports logical AND/OR chaining of filter-semantic 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: row-based, pure columnar, and hybrid row-column. Converting a row-based table to a hybrid row-column or columnar table required offline DDL. To reduce the impact of offline DDL on customers, V4.3.5 supports asynchronous online conversion from row-based to columnar storage. 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 performed asynchronously during a major compaction. V4.3.5 supports converting row-based tables to columnar tables and converting row-based tables to hybrid row-column tables via online DDL.

Performance optimization

• Vectorization of direct load write paths

  Prior to V4.3.5, direct load implementations were not vectorized; write functions processed data row by row, resulting in significant function call overhead. Furthermore, writing to SSTables was a background process that lacked targeted optimization for certain operations. V4.3.5 vectorizes the direct load path and optimizes columnar encoding, thereby improving direct load performance. Verification shows that direct load performance in scenarios without primary key columnar tables can be optimized by approximately 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 usage of the ARRAY type, V4.3.5 adds support for 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 to establish 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 vector execution and extended TAAT processing strategies, removes the token count limit for the MATCH AGAINST predicate, and supports creating full-text indexes on partitioned tables without primary keys. Furthermore, the new version allows viewing tokenization results using the tokenize function, aiding in debugging the tokenization system.

  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 usage, V4.3.4 has lifted some of these limitations 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 data writing phase and the sorting and merging phase. If data is not fully written, the subsequent sorting and merging 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 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, small-specification tenants will not experience a noticeable performance regression.

Data type and storage optimization

• Bitmap feature enhancements

  Bitmap, also known as a bitmap index, 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 upon this, 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 format 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 T1 is a hybrid row-column table, then 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 this zone, all user tables are stored in columnar format. AP services 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 query analysis using weak-consistency reads, without affecting the original TP services. Additionally, a deployment model like 3+1 zones can save 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 logic rewriting, 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 use the automatic rewrite capability by specifying ENABLE QUERY REWRITE when creating a materialized view. The system can then rewrite queries against the original table into queries against the materialized view. V4.3.1 supported rewriting for non-aggregated materialized views where the FROM clause fully matches and the WHERE clause partially matches. 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 rewriting.

  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 rowstore format. Starting from V4.3.3, support for materialized views in columnstore 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. However, V4.3.2 only supported writing to an entire table; it did not provide partition-level or specified-column replacement write capabilities. V4.3.3 complements and enhances this feature by allowing you to specify the target table as a partition or subpartition in INSERT OVERWRITE statements, and also supports specifying partial column information for the target table. This makes data replacement writing more flexible and applicable to a wider range of business scenarios.

• Load Data/external table support for compressed files

  Load Data is a commonly used method for data import, covering scenarios such as regular server-side import, direct load, and client-side import, all of which can import formatted text files into a database. However, previous versions only supported standard text files; compressed files like GZIP required decompression before import, making the operation more complicated. The new version now supports importing compressed files, allowing GZIP, DEFLATE, and ZSTD format files to be loaded, decompressed, and written simultaneously. Furthermore, CSV external tables have also been extended to 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 business scenarios, 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 allow nested arrays; it supports constructing expressions for querying or writing to array objects, supports the array_contains expression and the ANY operator to check if an element is present in the array; it also supports operators like +/-/=/!= for array element computation and judgment.

• RoaringBitmap performance optimization

  V4.3.2 introduced support for the RoaringBitmap data type and related expressions to meet multidimensional analysis needs 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 computations, optimizing memory allocation and expression execution logic, and eliminating unnecessary performance overhead, resulting in several-fold improvements in execution performance for cardinality, and/or/xor/andnot operations, as well as aggregation scenarios.

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 query-level resource group binding. 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

Optimized data import and export

• Enhanced incremental direct load feature

  Starting from V4.3.1, incremental direct load is 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 range 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 columnar storage (which pre-aggregates SUM values for specified columns within a storage layer range). Combined with disabling microblock verification (by 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 file external tables. However, as AP business has expanded, it has become common to need to read Parquet format external data sources 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 file list refresh method (manual, real-time, periodic) 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 100 GB 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 performance for large-scale set computation and deduplication. To meet multi-dimensional analysis requirements, this version supports over twenty expressions for cardinality calculation, set operations, bitmap checks, bitmap construction, bitmap output, and aggregation operations.

Data operation optimization

• Table-level overwrite

  In data warehousing scenarios involving regular data refresh, data transformation, and data cleansing, table-level overwrite is a common requirement. 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 in large-scale data import scenarios. The new version provides asynchronous task scheduling capabilities based on DBMS_SCHEDULER. Users can use commands such as 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 V4.3.0 introduced support for materialized views, which precompute and store query results to reduce real-time computation and improve query performance. This simplifies complex query logic and meets the needs of analytical workloads. 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 tasks 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 cost of manual rewriting. 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 application 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 V4.1.0 introduced support for the direct load feature, which significantly improves data import efficiency by streamlining the data loading execution path, skipping modules such as SQL, transactions, and memtables, and persisting data directly as SSTables. 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 the Incremental direct load section in Overview of 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 to control 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 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 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 nearly 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) partition type for a partitioned table.
  • Supports a RANGE (Range Columns) partition type for a subpartitioned table.
  • Supports the including indexes behavior, which means 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 complies with 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 due to lack of pruning, resulting in poor performance. V4.3.1 introduces external table partitioning, supporting a partitioning method similar to LIST partitioning for 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. With this approach, external table queries can achieve 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 for JSON documents and other collection data types. This allows users to build indexes on arrays or collections to efficiently retrieve elements. 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 query capabilities for complex JSON data structures, balancing data model flexibility with high-performance data querying. 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 on JSON array elements of types INT, UINT, DOUBLE, FLOAT, CHAR, etc.
  • Applicable to partitioned tables.
  • Supports using multi-valued indexes with the MEMBER_OF(), JSON_CONTAINS(), and JSON_OVERLAPS() functions.

• MySQL JSON Partial Update

  Some users store business data in JSON documents. When updating such documents, the current method 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 specific fields of a JSON document using expressions like json_set, json_replace, or 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, memory insufficiency may occur, forcing some operators to materialize temporary intermediate results. If the materialized data volume is too large and disk space fills up, 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 larger computational workload query tasks.

V4.3.0 Beta

Version information

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

New features

• Columnar storage engine

  In scenarios involving large-scale data analytics 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, analysis queries can scan only the columns required for computation, 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 high compression ratios, which reduces storage space and network transmission bandwidth.

  However, common columnar storage engines are often implemented assuming minimal random data updates, striving to keep the data organized in a static manner. When a significant amount of random data updates 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 further extends support for the columnar storage engine based on the current architecture, 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, multiple modules have been adapted and optimized around the columnar storage engine, from the optimizer to the executor, from DDL to transaction processing. This includes a new cost model and vectorized engine based on columnar storage, extended and enhanced query pushdown functionality, Skip Index, a new columnar encoding algorithm, adaptive compaction, and more.

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

• New vectorized engine

  OceanBase has implemented a vectorized engine based on the Uniform data description method in earlier versions, achieving significant performance improvements over non-vectorized engines. However, there were still 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 ObDatum maintenance. 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 like HashJoin, AGGR, HashGroupBy, 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, aiming 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, including 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 table 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 detailed information about materialized views, see Materialized view (MySQL-compatible mode) and Materialized view (Oracle-compatible mode).