AP version update record

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

V4.4.2

Version information

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

New features and enhancements

• Enhanced materialized view capabilities

  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 and background redundant cleanup. The incremental refresh capability is greatly extended, newly supporting complex query patterns such as external joins, UNION ALL, non-aggregated single tables, and aggregated queries with LEFT JOIN. It strengthens the processing of MIN/MAX aggregate functions, supports repeated SELECT ITEM and GROUP BY columns, and adapts to scenarios without a primary key base table. It introduces the AS OF PROCTIME() syntax to enable dynamic exemption from refreshing for dimension tables (views that reference this syntax are supported), and improves the cascading refresh mechanism for nested materialized views. Additionally, it enhances support for UDT/UDF, minimal mode, and the md5_concat_ws function, optimizes view content display and creation error messages, comprehensively improving the flexibility, performance, and ease of use of materialized views in complex queries, real-time analysis, 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 or 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. It is a key infrastructure that enables OceanBase to advance from "storage-compute separation" to "metadata-driven governance" in data lakes.

• External tables support JDBC plugins

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

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. It retains Tunnel API compatibility to meet diverse access requirements.

• SELECT INTO OUTFILE supports HDFS paths

  V4.4.0 continues to improve external table capabilities, 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 introduces incremental refresh support for 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 that reference UDFs, supports the minimal refresh mode for incremental materialized views (where DML for incremental refresh only needs to read from and write data in 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 scope of skip index capability can be controlled by the tenant-level parameter default_skip_index_level.

• Expansion of 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, 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 not refreshing the dimension table during incremental refresh of a materialized view. 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() and MAX() aggregate functions. For ease of use, it supports automated MLOG management: when creating an incremental refresh materialized view, it automatically creates or 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 a second-level latency. This caused some queries that were otherwise very fast to consume significant time in session preparation. 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, 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 exchanges between partitions and subpartitions

  The partition exchange feature now supports exchanging a partition of a subpartitioned table with a partition of a non-subpartitioned 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 introduced significant error. The new version leverages the skip index capability of the storage layer to collect block-level, more accurate column aggregate data for all columns in columnar storage, helping the optimizer generate and optimize execution plans more precisely. It also introduces progressive statistics collection for partitions to address timeout issues caused by long collection times for large partitioned tables, improving system stability and data real-time performance.

Accelerated data import

• Direct load performance optimization

  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 unpartitioned 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

Data recovery capability enhancements

• Table-level restore now supports restoring columnar storage tables

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

Performance optimizations

• Heap table direct load performance optimization

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

• Hard parse performance optimization

  In some AP scenarios or for some large and small accounts, disabling the plan cache and using 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 during the resolver stage, replacing scenarios that do not require global cost verification with local cost verification, simplifying 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 application scenarios for materialized views.

• Materialized view diagnostics capability enhancements

  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 timestamps and refresh latency. The CDB/DBA/ALL/USER_MVIEW_LOGS view includes parallelism and duration information used for MLOG cleanup.

• Materialized view tasks access 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 capabilities for materialized view incremental refresh and MLOG purge based on 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, this requires DBAs 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 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 space.

Index and query optimization

• NGRAM2 tokenizer for full-text indexes

  Full-text indexes now support the built-in NGRAM2 tokenizer, which performs NGRAM segmentation 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 less critical and searches for tokens of different lengths are required. For fixed-length tokens, you can use the NGRAM tokenizer.

Data type 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 a low storage compression ratio. 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 non-splittable parts placed in a Binary column. Structured columns can leverage encoding to improve compression rates, and the non-splittable parts, having had their metadata extracted, will also occupy less space compared to 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, introducing major compaction overhead in scenarios requiring frequent reading of raw JSON data may lead to performance degradation. 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 in 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'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 for 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 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 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 error 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 for HASH partitions is supported. Concurrently, incremental direct load supports concurrent import of multiple partitions. However, when multiple import tasks have overlapping partitions, parallel import of those 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 into 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 data lake architectures and serves as a platform for multi-engine data sharing. Therefore, the new OceanBase version supports directly reading files from HDFS via external tables. It also supports connecting to 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 via external tables or URL external tables, and also supports writing OceanBase data back to MaxCompute.

• URL external tables

  When accessing external data sources in OceanBase, you typically need to create an external table first and then use 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 Database has supported full-text indexes in MySQL-compatible mode since V4.3.1, with gradual functional supplements and expansions over the 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 new tokenizers via plugins. Full-text indexes support tokenizer attributes, with table-level PARSER_PROPERTIES configuration. In addition to the existing natural language query mode for full-text indexes, a boolean mode has been 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 index union merge computation. It also 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 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 commands 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 the primary key or index key. In OceanBase Database, the char/varchar type can store strings and serve as the primary key or index key, but the length must be specified. LOB types such as mediumtext/text can store variable-length strings but cannot be used as the primary key or index key. To better meet AP workload requirements, a new String data type is introduced, which does not require a specified 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 the primary key or index key.

• 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 some scenarios. To enable large SQL queries to utilize 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. It also provides hints (PX_NODE_ADDRS, PX_NODE_COUNT) 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—i.e., 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, the scan theoretically could be pushed down. However, parsing failures of the new columns would 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 ease of use. 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 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, 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, namely 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, users 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 direct load paths for full-table data imports to accelerate the import process. If users wanted to import data from only some partitions, they 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 procedure was cumbersome for users. To better support partition-level data import, V4.3.5 supports specifying partitions to use direct load paths 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 specification of a compression algorithm when exporting to CSV format. New syntax is added for select into.

  • Use the format syntax 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 refine the full-text indexing feature, 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 AND/OR chaining of filter-semantic MATCH AGAINST with logical operations of 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. Subsequently, the baseline data reorganization for columnstore is executed asynchronously during the baseline data 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, the implementation of direct load did not employ vectorization; write functions processed data row by row, resulting in significant function call overhead. Moreover, writing to SSTables was a background process, and targeted optimizations were lacking for certain operations. 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 approximately 2 times.

Data type and storage optimization

• JSON multi-valued indexes support complex DML

  V4.3.5's JSON multi-valued indexes have improved support for complex DML statements. They now support multi-valued predicates in statements such as 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 requirements. 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 the full-text index feature since V4.3.1. By preprocessing text content and establishing 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 business operations. To better support business development, V4.3.4 has improved the 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 the debugging of 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 relaxes some usage restrictions and enhances the functionality. The main enhancements include support for complex DML operations, including INSERT INTO ON DUPLICATE KEY, REPLACE INTO, multi-table update/deletion, 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, 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 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 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 form 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 via weak-consistency reads, without affecting the original TP services. Additionally, a deployment form 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. In this case, the system can rewrite queries from the original table to queries on 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 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 OceanBase versions only supported materialized views in row storage format. Starting from V4.3.3, support for materialized views in column storage format will be extended, providing the opportunity for 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 conversion, and data cleansing and correction. However, V4.3.2 only supported writing to an entire table, without providing the ability to write to partitions or specified columns. 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 data replacement writing more flexible and applicable to more business scenarios.

• Load Data/external tables support compressed files

  Load Data is a commonly used method for data import, 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 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 also extend support for 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 to store multiple elements of the same type. It is an appropriate choice when managing and querying multi-valued attributes 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 computation, optimizing memory allocation and expression execution logic, and streamlining unnecessary performance overhead, achieving several times improved execution performance in cardinality, AND/OR/XOR/ANDNOT, and aggregation scenarios.

Resource management and isolation

• Query-level resource group configuration

  OceanBase Database currently supports configuring resource groups at the user level, background task level, and column parameter level using the DBMS_RESOURCE_MANAGER system package to achieve CPU and IOPS resource isolation. V4.3.3 introduces the ability 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 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 of 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

• Enhancements to external tables

  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 some data lake scenarios. Starting from V4.3.2, OceanBase supports Parquet file external tables. Users can import data from files into internal tables in OceanBase 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

• Performance optimization for typical AP scenarios

  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 need to mine and analyze user data. RoaringBitmap, with its space-saving and efficient computing capabilities, 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 set computation and deduplication on large datasets. To meet multi-dimensional analysis requirements, 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 such as 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 to 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 available 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 materialized views, which precompute and store query results to reduce real-time computation, improve query performance, simplify complex query logic, and support AP scenarios. Building on this, V4.3.1 extends support for real-time materialized views, providing real-time computing capabilities based on both materialized view and MLOG data, suitable for analytical workloads with high real-time requirements. It adds primary key constraints for materialized views, allowing users to specify a primary key for a materialized view to optimize performance in scenarios such as single-row searches, range queries, or joins based on the primary key. Additionally, it extends support for incremental updates of materialized views in inner join scenarios, improving materialized view refresh performance in some cases.

  Furthermore, when using materialized views in V4.3.0, manual rewriting of accesses to the original table in business scripts was required to query the corresponding materialized view, introducing a cost of manual refactoring. The new version supports materialized view rewrite capability in some scenarios. When the system variable QUERY_REWRITE_ENABLED is set to True, you can use the automatic rewrite capability of 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, thereby reducing the amount of business modification required. For more information about automatic materialized view rewrite, see Materialized view query rewrite (MySQL-compatible mode) and Materialized view query rewrite (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 directly persisting data 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 targets and optimizes incremental import scenarios. Incremental direct load does not require rewriting the original data; it only processes new data, making multiple imports perform as efficiently 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, 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 must be performed to perform a fuzzy search on each row of data, 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:

  Supports the full-text index feature 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, a table 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 subpartition of a subpartitioned table.
  • Supports the including indexes behavior, which means that when partitions are exchanged, the corresponding local indexes are also involved in the exchange and remain available after the exchange.
  • Supports the without validation mode, where users must ensure that the 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 single query theoretically only requires scanning a portion of the data files, non-partitioned external tables can only scan the entire set of files, making pruning impossible and leading to poor performance. V4.3.1 introduces the external table partitioning feature, 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 definition of the partitioning key. 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 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 the flexibility of the data model 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 where the JSON array element types are 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 using JSON documents. When updating such documents, 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 complete 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 data volume involved in SQL execution is too large, insufficient memory may occur, requiring 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 through 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 I/O and memory resource usage, thereby improving computation speed. Additionally, columnar storage inherently provides better conditions for data compression, often achieving higher compression ratios, which reduces storage space and network transmission bandwidth.

  However, common columnar storage engines are typically implemented with the assumption that there will be no significant amount of random updates, striving to keep the data organized in a static manner. When a large volume of random data updates does occur, system performance issues are inevitable. OceanBase's LSM-Tree architecture allows for separate processing of baseline data and incremental data, effectively 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, a single architecture, and a single OBServer, balancing both TP and AP query performance.

  To facilitate AP business migration and ensure smooth adoption of the new version by existing customers, extensive adaptation and optimization have been made across multiple modules, from the optimizer and executor to DDL and 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.

  For practical applications, users can flexibly configure tables as row-based tables, columnar tables, or hybrid row-column redundant tables based on their workload type. For detailed 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 the 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 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).