This topic describes how to create a materialized view by using SQL statements.
Note
OceanBase Database does not support directly modifying the properties of a materialized view, such as the refresh time and refresh strategy. In this case, you can delete the materialized view and create a new one to achieve the desired modifications.
Privilege requirements
You must have the CREATE TABLE privilege to create a materialized view. For more information about the privileges of OceanBase Database, see Privilege classification in Oracle mode.
Syntax
The syntax for creating a materialized view is as follows:
CREATE MATERIALIZED VIEW view_name [([column_list] [PRIMARY KEY(column_list)])]
[table_option_list]
[partition_option]
[mv_column_group_option]
[refresh_clause [query_rewrite_clause] [on_query_computation_clause]]
AS view_select_stmt;
Parameters:
view_name: the name of the materialized view to be created.column_list: optional. The list of columns in the materialized view. If you want to specify the names of the view columns, you can use thecolumn_listclause and separate the column names with commas.PRIMARY KEY(column_list): optional. The primary key of the materialized view.table_option_list: optional. The table options of the materialized view.partition_option: optional. The partition options of the materialized view.mv_column_group_option: optional. The storage format of the materialized view. If this option is not specified, a rowstore materialized view is created by default.refresh_clause [query_rewrite_clause] [on_query_computation_clause]: optional. The details are as follows:refresh_clause: the refresh method of the materialized view.query_rewrite_clause: optional. Whether to enable automatic rewriting for the current materialized view.on_query_computation_clause: optional. Whether the current materialized view is a regular or real-time materialized view.
AS view_select_stmt: the query statement (SELECT) that defines the data of the materialized view. This statement is used to retrieve data from the base table and store the results in the materialized view.Note
- OceanBase Database supports creating full-refresh materialized views with external tables as the base tables.
- When creating a materialized view, you can add the
AS OF PROCTIME()clause to the base table. If you useAS OF PROCTIME()outside the base table of the materialized view, an error will be returned.AS OF PROCTIME()is used to specify that the refresh should skip this table during incremental refreshes. Additionally, tables usingAS OF PROCTIME()do not require an mlog. - OceanBase Database supports using regular views declared as dimension tables (
AS OF PROCTIME()) as the base tables for incremental-refresh materialized views.
For more information about the parameters of the CREATE MATERIALIZED VIEW statement, see CREATE MATERIALIZED VIEW.
Create a materialized view
Create a regular materialized view
To create a regular materialized view, you can omit or specify the DISABLE ON QUERY COMPUTATION clause.
Notice
In OceanBase Database in Oracle mode, when you create a materialized view and specify the DISABLE ON QUERY COMPUTATION clause (on_query_computation_clause), you must also specify the refresh method (refresh_clause).
Here is an example:
Create a table named
tbl1as the base table for the materialized view. The following example shows how to do this:CREATE TABLE tbl1 (col1 NUMBER PRIMARY KEY, col2 VARCHAR2(20), col3 NUMBER);Create a materialized view named
mv_tbl1based on thetbl1table. The following example shows how to do this:CREATE MATERIALIZED VIEW mv_tbl1 AS SELECT col1, col2 FROM tbl1 WHERE col3 >= 20;or
CREATE MATERIALIZED VIEW mv_tbl1 REFRESH FORCE DISABLE ON QUERY COMPUTATION AS SELECT col1, col2 FROM tbl1 WHERE col3 >= 20;
Create a nested materialized view
A nested materialized view is a materialized view built on an existing materialized view. For example, in the following figure, the materialized view mv1 is built on the tbl1 and tbl2 tables, which is a typical materialized view. The materialized view mv2 is built on the mv1 materialized view and the tbl3 table, making it a nested materialized view. Similarly, the materialized view mv3 is built on the mv1 and mv2 materialized views, which also makes it a nested materialized view.
When creating a nested materialized view in OceanBase Database, you can specify the refresh strategy. The valid values are as follows:
INDIVIDUAL: the default value, indicating independent refresh.INCONSISTENT: indicating cascading inconsistent refresh.CONSISTENT: indicating cascading consistent refresh.
Note
For non-nested materialized views, there is no cascading refresh behavior. Therefore, the specified refresh strategy is irrelevant and the default independent refresh will be applied. The specified refresh strategies only take effect in background tasks. When you manually use the PL package (DBMS_MVIEW.REFRESH) to schedule a refresh, the refresh will be executed based on the specified PL parameters.
Limitations on nested materialized views
- To support incremental refresh for nested materialized views, you need to create mlogs on the materialized view (base table).
- If a materialized view is fully refreshed, any dependent materialized views (nested materialized views) must be fully refreshed before they can perform incremental refresh. Otherwise, an error will be reported.
- Nested materialized views cannot be created as real-time materialized views. In other words, you cannot specify the
ENABLE ON QUERY COMPUTATIONclause when creating a nested materialized view.
Here is an example:
Create a table named
tbl3as the base table for the materialized view. The following example shows how to do this:CREATE TABLE tbl3(id INT, name VARCHAR2(30), PRIMARY KEY(id));Create a table named
tbl4as the base table for the materialized view. The following example shows how to do this:CREATE TABLE tbl4(id INT, age INT, PRIMARY KEY(id));Create a materialized view named
mv1_tbl3_tbl4based on thetbl3andtbl4tables. The following example shows how to do this:CREATE MATERIALIZED VIEW mv1_tbl3_tbl4 (PRIMARY KEY (id1, id2)) REFRESH COMPLETE AS SELECT tbl3.id id1, tbl4.id id2, tbl3.name, tbl4.age FROM tbl3, tbl4 WHERE tbl3.id = tbl4.id;Create a materialized view (nested materialized view) named
mv_mv1_tbl3_tbl4based on themv1_tbl3_tbl4materialized view. The following example shows how to do this:CREATE MATERIALIZED VIEW mv_mv1_tbl3_tbl4 REFRESH COMPLETE AS SELECT SUM(AGE) age_sum FROM mv1_tbl3_tbl4;Create a materialized view (nested materialized view) named
mv1_mv1_tbl3_tbl4based on themv1_tbl3_tbl4materialized view, with the refresh strategy set toINCONSISTENT. The following example shows how to do this:CREATE MATERIALIZED VIEW mv1_mv1_tbl3_tbl4 REFRESH COMPLETE INCONSISTENT AS SELECT SUM(AGE) age_sum FROM mv1_tbl3_tbl4;
Create a real-time materialized view
To create a real-time materialized view, you can specify the ENABLE ON QUERY COMPUTATION clause.
Notice
In OceanBase Database in Oracle mode, when you create a real-time materialized view, you must also specify the refresh method (refresh_clause).
Considerations for creating a real-time materialized view
Before you create a real-time materialized view, you must create a materialized view log for each base table on which the materialized view depends.
Note
OceanBase Database supports automatic management of materialized view logs. If you enable automatic management of materialized view logs, you do not need to create a materialized view log for a base table before you create a real-time materialized view. OceanBase Database automatically creates a materialized view log for the base table or updates the definition of an existing materialized view log to include the columns required by the new real-time materialized view. For more information, see Automatic management of materialized view logs.
Only materialized views of specific types can be specified as real-time materialized views. If you specify a materialized view that does not meet the requirements as a real-time materialized view, an error will be returned. The requirements for a real-time materialized view are the same as those for a materialized view with incremental refresh. For more information, see the Basic requirements for incremental refresh section in Refresh a materialized view.
- A materialized view that uses the
MINorMAXfunction cannot be specified as a real-time materialized view. - An aggregate materialized view with an outer join cannot be specified as a real-time materialized view.
- A materialized view with a set query cannot be specified as a real-time materialized view.
- A nested materialized view cannot be specified as a real-time materialized view.
- A materialized view that uses the
If the values of system variables in the session that executes the query do not match the values of session variables that are solidified in the materialized view, you must modify the values of system variables in the session to match the values of session variables that are solidified in the real-time materialized view. Otherwise, the real-time materialized view will not be available. That is, query rewriting will not be performed on the real-time materialized view, or an error will be returned when you directly query the real-time materialized view.
Here is an example:
Create the
tbl2table as a base table for a materialized view.CREATE TABLE tbl2(col1 INT, col2 INT, col3 INT);Create a materialized view log on the
tbl2table.CREATE MATERIALIZED VIEW LOG ON tbl2 WITH PRIMARY KEY, ROWID, SEQUENCE (col1, col2, col3) INCLUDING NEW VALUES;Create a real-time materialized view
mv_tbl2based on thetbl2table.CREATE MATERIALIZED VIEW mv_tbl2 REFRESH COMPLETE ON DEMAND ENABLE ON QUERY COMPUTATION AS SELECT col1, count(*) AS cnt FROM tbl2 GROUP BY col1;After you create a real-time materialized view, you can query the DBA_MVIEWS view to check whether the materialized view is a real-time materialized view.
SELECT MVIEW_NAME, ON_QUERY_COMPUTATION FROM sys.DBA_MVIEWS WHERE MVIEW_NAME = 'MV_TBL2';Notice
When the
MVIEW_NAMEfield in thesys.DBA_MVIEWSview in Oracle mode matches the table name, the table name must be in uppercase.The returned result is as follows:
+------------+----------------------+ | MVIEW_NAME | ON_QUERY_COMPUTATION | +------------+----------------------+ | MV_TBL2 | Y | +------------+----------------------+ 1 row in setView the execution plan of the real-time materialized view.
EXPLAIN BASIC SELECT * FROM mv_tbl2;From the following execution plan, you can see that data is simultaneously read from the materialized view and the materialized view log of the base table on which the view depends. The two parts of data are then calculated and integrated to obtain the real-time data of the materialized view.
The returned result is as follows:
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Query Plan | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | ============================================== | | |ID|OPERATOR |NAME | | | ---------------------------------------------- | | |0 |HASH GROUP BY | | | | |1 |└─SUBPLAN SCAN |INNER_RT_MV$$| | | |2 | └─UNION ALL | | | | |3 | ├─TABLE FULL SCAN |MV_TBL2 | | | |4 | └─HASH GROUP BY | | | | |5 | └─SUBPLAN SCAN |DLT_T$$ | | | |6 | └─WINDOW FUNCTION | | | | |7 | └─TABLE FULL SCAN|MLOG$_TBL2 | | | ============================================== | | Outputs & filters: | | ------------------------------------- | | 0 - output([INNER_RT_MV$$.COL1], [cast(T_FUN_SUM(INNER_RT_MV$$.CNT), NUMBER(38, 0))]), filter([T_FUN_SUM(INNER_RT_MV$$.CNT) > cast(0, NUMBER(-1, -85))]), rowset=16 | | group([INNER_RT_MV$$.COL1]), agg_func([T_FUN_SUM(INNER_RT_MV$$.CNT)]) | | 1 - output([INNER_RT_MV$$.COL1], [INNER_RT_MV$$.CNT]), filter(nil), rowset=16 | | access([INNER_RT_MV$$.COL1], [INNER_RT_MV$$.CNT]) | | 2 - output([UNION([1])], [UNION([2])]), filter(nil), rowset=16 | | 3 - output([MV_TBL2.COL1], [MV_TBL2.CNT]), filter(nil), rowset=16 | | access([MV_TBL2.COL1], [MV_TBL2.CNT]), partitions(p0) | | is_index_back=false, is_global_index=false, | | range_key([MV_TBL2.__pk_increment]), range(MIN ; MAX)always true | | 4 - output([DLT_T$$.COL1], [T_FUN_SUM(CASE WHEN DLT_T$$.OLD_NEW$$ = cast('N', VARCHAR2(1048576 )) THEN cast(1, NUMBER(-1, -85)) ELSE (T_OP_NEG, cast(1, | | NUMBER(-1, -85))) END)]), filter(nil), rowset=16 | | group([DLT_T$$.COL1]), agg_func([T_FUN_SUM(CASE WHEN DLT_T$$.OLD_NEW$$ = cast('N', VARCHAR2(1048576 )) THEN cast(1, NUMBER(-1, -85)) ELSE (T_OP_NEG, | | cast(1, NUMBER(-1, -85))) END)]) | | 5 - output([DLT_T$$.OLD_NEW$$], [DLT_T$$.COL1]), filter([DLT_T$$.OLD_NEW$$ = cast('N', VARCHAR2(1048576 )) AND DLT_T$$.SEQUENCE$$ = DLT_T$$.MAXSEQ$$ OR | | DLT_T$$.OLD_NEW$$ = cast('O', VARCHAR2(1048576 )) AND DLT_T$$.SEQUENCE$$ = DLT_T$$.MINSEQ$$]), rowset=16 | | access([DLT_T$$.OLD_NEW$$], [DLT_T$$.SEQUENCE$$], [DLT_T$$.MAXSEQ$$], [DLT_T$$.MINSEQ$$], [DLT_T$$.COL1]) | | 6 - output([MLOG$_TBL2.OLD_NEW$$], [MLOG$_TBL2.SEQUENCE$$], [T_FUN_MAX(MLOG$_TBL2.SEQUENCE$$)], [T_FUN_MIN(MLOG$_TBL2.SEQUENCE$$)], [MLOG$_TBL2.COL1]), filter(nil), rowset=16 | | win_expr(T_FUN_MAX(MLOG$_TBL2.SEQUENCE$$)), partition_by([MLOG$_TBL2.M_ROW$$]), order_by(nil), window_type(RANGE), upper(UNBOUNDED PRECEDING), lower(UNBOUNDED | | FOLLOWING) | | win_expr(T_FUN_MIN(MLOG$_TBL2.SEQUENCE$$)), partition_by([MLOG$_TBL2.M_ROW$$]), order_by(nil), window_type(RANGE), upper(UNBOUNDED PRECEDING), lower(UNBOUNDED | | FOLLOWING) | | 7 - output([MLOG$_TBL2.M_ROW$$], [MLOG$_TBL2.SEQUENCE$$], [MLOG$_TBL2.OLD_NEW$$], [MLOG$_TBL2.COL1], [ORA_ROWSCN]), filter([cast(ORA_ROWSCN, NUMBER(-1, | | -1)) > last_refresh_scn(500155)]), rowset=16 | | access([MLOG$_TBL2.M_ROW$$], [MLOG$_TBL2.SEQUENCE$$], [MLOG$_TBL2.OLD_NEW$$], [MLOG$_TBL2.COL1], [ORA_ROWSCN]), partitions(p0) | | is_index_back=false, is_global_index=false, filter_before_indexback[false], | | range_key([MLOG$_TBL2.M_ROW$$], [MLOG$_TBL2.SEQUENCE$$]), range(MIN,MIN ; MAX,MAX)always true | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 40 rows in set
Create a materialized view with query rewriting enabled
When you create a materialized view, you can specify the ENABLE QUERY REWRITE clause to enable automatic query rewriting for the materialized view. For more information about query rewriting and query rewriting control, see Query rewriting for materialized views.
Notice
Specifying the ENABLE QUERY REWRITE clause for a materialized view does not guarantee that the query will be rewritten. If a materialized view does not meet the query rewriting conditions, no error will be returned, but the materialized view will not be used for query rewriting. The default value of the system variable query_rewrite_enabled is false, so by default, a materialized view that specifies the ENABLE QUERY REWRITE clause will not be used for query rewriting.
Here is an example:
Create a materialized view
mv_spj_tbl1based on thetbl1table and enable automatic query rewriting.CREATE MATERIALIZED VIEW mv_spj_tbl1 NEVER REFRESH ENABLE QUERY REWRITE AS SELECT * FROM tbl1;After you create a materialized view, you can query the DBA_MVIEWS view to check whether query rewriting is enabled for the materialized view.
SELECT MVIEW_NAME, REWRITE_ENABLED FROM sys.DBA_MVIEWS WHERE MVIEW_NAME = 'MV_SPJ_TBL1';Notice
When the
MVIEW_NAMEfield in thesys.DBA_MVIEWSview in Oracle mode matches the table name, the table name must be in uppercase.The returned result is as follows:
+-------------+-----------------+ | MVIEW_NAME | REWRITE_ENABLED | +-------------+-----------------+ | MV_SPJ_TBL1 | Y | +-------------+-----------------+ 1 row in set
Create a columnstore materialized view
OceanBase Database supports materialized views in rowstore, columnstore, and rowstore-columnstore redundant formats. You can specify the mv_column_group_option option to explicitly create a columnstore or rowstore-columnstore redundant materialized view. If a materialized view is a wide table that is formed by joining multiple tables, creating a columnstore materialized view can improve the performance of certain queries. You can specify the WITH COLUMN GROUP(each column) clause to create a columnstore materialized view.
Note
If you do not specify the mv_column_group_option option, a rowstore materialized view is created by default.
Here is an example:
Create a columnstore materialized view mv_ec_tbl1 based on the tbl1 table.
CREATE MATERIALIZED VIEW mv_ec_tbl1
WITH COLUMN GROUP(each column)
AS SELECT *
FROM tbl1;
Add a primary key when you create a materialized view
Notice
If you specify a primary key for a materialized view, the maintenance or update of the materialized view will fail if the data does not meet the primary key constraints.
Here is an example:
Create a materialized view named mv_pk_tbl1 based on the tbl1 table and specify a primary key for the materialized view.
CREATE MATERIALIZED VIEW mv_pk_tbl1(v_id, v_name, PRIMARY KEY(v_id))
AS SELECT col1, col2
FROM tbl1
WHERE col3 >= 20;
Specify table options and partitioning options when you create a materialized view
You can specify table options and partitioning options when you create a materialized view. This way, you can improve query performance and management efficiency by designing and configuring partitioning options based on data characteristics and access patterns.
For more information about the table options and partitioning options, see CREATE TABLE.
Here is an example:
Create a materialized view named mv_pp_tbl1 based on the tbl1 table. Set the parallelism of the materialized view to 5. Hash partition the materialized view by the col1 column and divide it into 8 partitions. Query the records in the tbl1 table that meet the condition col3 >= 20 as the base table, and use the query results as the data of the materialized view.
CREATE MATERIALIZED VIEW mv_pp_tbl1
PARALLEL 5
PARTITION BY HASH(col1) PARTITIONS 8
AS SELECT col1, col2
FROM tbl1
WHERE col3 >= 20;
Add an index to a materialized view
You cannot directly create an index in the statement for creating a materialized view. Instead, you can use the CREATE INDEX statement to create an index for the materialized view.
Here is an example:
Create an index named idx_mv_tbl1 on the col1 column of the materialized view mv_tbl1.
CREATE INDEX idx_mv_tbl1 ON mv_tbl1(col1);
Refresh a materialized view
OceanBase Database supports the following refresh modes for materialized views: full refresh, incremental refresh, hybrid refresh, and never refresh.
- Full refresh: Recalculate all data in the materialized view to ensure that the data in the view is consistent with that in the source table.
- Incremental refresh: Refresh only the data that is related to the changes in the source table. This avoids the need to recalculate the entire view.
- Hybrid refresh: The default mode. First, it attempts an incremental refresh. If the incremental refresh fails, it performs a full refresh.
- Never refresh: The materialized view is refreshed only when it is created. After it is created, it cannot be refreshed again.
For more information about how to refresh a materialized view, see Refresh a materialized view.
Create a materialized view with a complete refresh strategy
When creating a materialized view, use the REFRESH COMPLETE clause to set the refresh strategy to complete refresh.
Notice
If a materialized view is completely refreshed, any dependent materialized views (nested materialized views) must be completely refreshed before they can be incrementally refreshed. Otherwise, an error will occur.
Here is an example:
Create a materialized view named mv_rc_tbl1 based on the tbl1 table, set the refresh strategy to complete refresh (REFRESH COMPLETE), and specify that the data source of the materialized view consists of the col1 and col2 columns from the tbl1 table where col3 is greater than or equal to 20.
CREATE MATERIALIZED VIEW mv_rc_tbl1
REFRESH COMPLETE
AS SELECT col1, col2
FROM tbl1
WHERE col3 >= 20;
Create a materialized view with a complete refresh strategy based on an external table
OceanBase Database supports creating materialized views with a complete refresh strategy based on external tables.
For more information about external tables, see External tables.
Here is an example:
Notice
The IP addresses in the example have been desensitized. When verifying, replace them with the actual IP addresses of your machine.
The following example demonstrates how to create an external table in two scenarios: when the external file is stored locally and when it is stored in the Oracle mode of OceanBase Database.
Prepare the external file.
Execute the following command to create a file named
ext_tbl1.csvin the/home/admin/external_csvdirectory on the machine where the OBServer node is located.[admin@xxx /home/admin/external_csv]# vi ext_tbl1.csvThe content of the file is as follows:
1,'A1' 2,'A2' 3,'A3'Set the import file path.
Notice
For security reasons, when setting the
secure_file_privsystem variable, you can only modify the global variable by executing an SQL statement through a local socket connection. For more information, see secure_file_priv.Execute the following command to log in to the machine where the OBServer node is located.
ssh admin@10.10.10.1Execute the following command to connect to the
oracle001tenant using a local Unix socket.obclient -S /home/admin/oceanbase/run/sql.sock -usys@oracle001 -p******Execute the following SQL statement to set the import path to
/home/admin/external_csv.SET GLOBAL secure_file_priv = "/home/admin/external_csv";
Reconnect to the
oracle001tenant.Here is an example:
obclient -h10.10.10.1 -P2881 -usys@oracle001 -p****** -ACreate an external table named
ext_tbl1.CREATE EXTERNAL TABLE ext_tbl1 ( id INT, name VARCHAR2(50) ) LOCATION = '/home/admin/external_csv' FORMAT = ( TYPE = 'CSV' FIELD_DELIMITER = ',' FIELD_OPTIONALLY_ENCLOSED_BY ='''' ) PATTERN = 'ext_tbl1.csv';Create a materialized view named
mv_ext_tbl1with a complete refresh strategy based on the external tableext_tbl1.CREATE MATERIALIZED VIEW mv_ext_tbl1 REFRESH COMPLETE AS SELECT * FROM ext_tbl1;View the data of the materialized view
mv_ext_tbl1.SELECT * FROM mv_ext_tbl1;The return result is as follows:
+------+------+ | ID | NAME | +------+------+ | 2 | A2 | | 1 | A1 | | 3 | A3 | +------+------+ 3 rows in set
Create a materialized view with incremental refresh
When you create a materialized view, use the REFRESH FAST option to set the refresh strategy to incremental refresh.
Considerations
At present, incremental refresh is supported for materialized views based on the following types of SQL statements: non-aggregated single-table statements, aggregated single-table statements, joined multi-table statements, joined aggregated multi-table statements, and
UNION ALLstatements. For other types of SQL statements, incremental refresh is not supported. For more information about incremental refresh, see the Incremental refresh section in Refresh a materialized view.The
REFRESH FASTmethod uses the records in the materialized view log to determine the content to be incrementally refreshed. Therefore, you must create a materialized view log for the base table before you create a materialized view with incremental refresh. For more information, see Materialized view log.Note
OceanBase Database supports automatic management of materialized view logs. If automatic management of materialized view logs is enabled, you do not need to create a materialized view log for the base table before you create a materialized view with incremental refresh. OceanBase Database automatically creates a materialized view log or updates the definition of an existing materialized view log table to include the columns required by the newly created materialized view. For more information, see Automatic management of materialized view logs.
When you create a materialized view, you can add the
AS OF PROCTIME()option to the base table. If you useAS OF PROCTIME()in a location other than the base table, an error is returned.AS OF PROCTIME()specifies to skip the refresh of the table during incremental refresh, thereby accelerating the incremental refresh of the materialized view. A table specified byAS OF PROCTIME()does not require a materialized view log. If you want to use an alias for the table, you must specify the alias after theAS OF PROCTIME()option.When you use a regular view declared as a dimension table with the
AS OF PROCTIME()option as the base table of a materialized view with incremental refresh, the following limitations apply:- All tables in the materialized view cannot be dimension tables, similar to the base table of the materialized view.
Here is an example:
Create a table named
tbl5as the base table of the materialized view.CREATE TABLE tbl5 (col1 INT PRIMARY KEY, col2 INT, col3 INT);Create a materialized view log for the
tbl5table. Set the materialized view log option toSEQUENCE, which indicates that the changes are identified by sequence numbers. Specify the columns to be recorded, includingcol2andcol3.CREATE MATERIALIZED VIEW LOG ON tbl5 WITH SEQUENCE (col2, col3) INCLUDING NEW VALUES;Create a materialized view named
mv_tbl5based on thetbl5table. Set the refresh strategy to incremental refresh (REFRESH FAST). In the query part, specify to group the records in thetbl5table by thecol2column, and calculate the number of records in each group (cnt), the number of non-null records in thecol3column (cnt_col3), and the sum of thecol3column (sum_col3) as the results of the materialized view.CREATE MATERIALIZED VIEW mv_tbl5 REFRESH FAST AS SELECT col2, COUNT(*) cnt, COUNT(col3) cnt_col3, SUM(col3) sum_col3 FROM tbl5 GROUP BY col2;Create a materialized view named
mv2_tbl5_tbl1based on thetbl5andtbl1tables. Set the refresh strategy to incremental refresh. Join the two tables by thecol1field. UseAS OF PROCTIME()to specify to skip thetbl1table during incremental refresh of the materialized view.CREATE MATERIALIZED VIEW mv2_tbl5_tbl1 REFRESH FAST ON DEMAND AS SELECT t5.col1 tbl5_c1, t1.col1 tbl1_c1, t5.col2 tbl5_c2, t1.col2 tbl1_c2 FROM tbl5 t5 INNER JOIN tbl1 AS OF PROCTIME() t1 ON t5.col1 = t1.col1 WHERE t5.col2 = 3;Create a materialized view with incremental refresh based on a regular view declared with the
AS OF PROCTIME()option.Create a view named
v1_tbl5based on thetbl5table.obclient> CREATE VIEW v1_tbl5 AS SELECT * FROM tbl5;Create a materialized view named
mv3_tbl5_v_tbl5based on thetbl5andv1_tbl5tables. Set the refresh strategy to incremental refresh. Join the two tables by thecol1field. UseAS OF PROCTIME()to specify thev1_tbl5view as a dimension table.obclient> CREATE MATERIALIZED VIEW mv3_tbl5_v_tbl5 AS SELECT a.col1 a_c1, b.col1 b_c1 FROM tbl5 a JOIN v1_tbl5 AS OF PROCTIME() b ON a.col1 = b.col1;
Create a materialized view with hybrid refresh (default option)
When you create a materialized view, omit or specify the REFRESH FORCE option to set the refresh strategy to hybrid refresh.
Here is an example:
Create a materialized view named mv_rf_tbl1 based on the tbl1 table. Set the refresh strategy to hybrid refresh (REFRESH FORCE). Specify to select the col1 and col2 columns that meet the condition col3 >= 20 from the tbl1 table as the data source of the materialized view.
CREATE MATERIALIZED VIEW mv_rf_tbl1
REFRESH FORCE
AS SELECT col1, col2
FROM tbl1
WHERE col3 >= 20;
Create a materialized view that never refreshes
When you create a materialized view, use the NEVER REFRESH option to specify that the materialized view does not need to be refreshed. This means that the materialized view is only refreshed when it is created and cannot be refreshed again after it is created.
Here is an example:
Create a materialized view named mv_nr_tbl1 based on the tbl1 table. Set the refresh strategy to NEVER REFRESH. Specify to select the col1 and col2 columns that meet the condition col3 >= 20 from the tbl1 table as the data source of the materialized view.
CREATE MATERIALIZED VIEW mv_nr_tbl1
NEVER REFRESH
AS SELECT col1, col2
FROM tbl1
WHERE col3 >= 20;
Create a materialized view with automatic refresh
When you create a materialized view, you can specify the START WITH datetime_expr and NEXT datetime_expr clauses to create a background automatic refresh task for the materialized view.
Notice
If you specify the NEXT clause, the time expression of the refresh schedule must be set to a future time. Otherwise, an error will be returned.
Here is an example:
Create a materialized view named mv_rc_swn_tbl1 based on the tbl1 table. Set the refresh strategy of the materialized view to full refresh. Set the initial refresh time of the materialized view to the current date, and set the refresh interval to 1 hour.
CREATE MATERIALIZED VIEW mv_rc_swn_tbl1
REFRESH COMPLETE
START WITH current_date NEXT current_date + INTERVAL '1' HOUR
AS SELECT col1, col2
FROM tbl1
WHERE col3 >= 20;
