All Products
Search
Document Center

AnalyticDB:Refresh materialized views

Last Updated:Mar 06, 2025

Materialized views can be used to accelerate complex queries or simplify extract, transform, load (ETL) operations. A materialized view stores precomputed query results, and the stored query results are refreshed based on different business requirements. You can select refresh policies for materialized views based on the write modes of base tables, the SQL computing complexity of materialized view queries, and the data timeliness of materialized views.

Select a refresh policy

Materialized views support two refresh policies: complete refresh and fast refresh.

  • Complete refresh executes a materialized view query to scan data in all involved base table partitions and uses the query results to overwrite the original data of the materialized view.

  • Fast refresh rewrites a materialized view query to scan only updated data in base tables and updates the data of the materialized view. This prevents all data of base tables from being scanned and reduces refresh overheads.

The following table describes the applicable scenarios, advantages, and limits of the two refresh policies.

Refresh policy

Scenario

Feature

Complete refresh

Batch processing scenarios:

  • Data is batch updated on a daily basis in T+1 mode.

  • Data is updated on an hourly basis.

  • A small amount of data is computed with low complexity. A minute-level latency is allowed.

Advantages: Materialized view queries support all SQL statements.

Limits: Complete data can be updated only in batches.

Fast refresh

Real-time analysis scenarios:

  • Data is updated in real time.

  • Reports or ETL operations are updated in real time.

  • A second-level latency is required.

Advantages:

  • A small amount of data is computed with low overheads.

  • Development and maintenance costs are reduced compared with stream computing.

Limits:

  • Limits are imposed on versions, base tables, and materialized view queries.

  • Manual refresh and automatic refresh when base tables are overwritten are not supported.

Select a refresh trigger mechanism

Besides a refresh policy, you must define a refresh trigger mechanism when you create a materialized view. The refresh trigger mechanisms of materialized views can be divided into on-demand refresh (specified by the ON DEMAND clause) and automatic refresh when base tables are overwritten (specified by the ON OVERWRITE clause). On-demand refresh is divided into automatic refresh at scheduled intervals and manual refresh. If you do not specify a refresh trigger mechanism, on-demand refresh is used.

When you select a refresh trigger mechanism, you must consider the data timeliness of materialized views and cluster workloads. The following section describes the features and scenarios of different refresh trigger mechanisms:

  • Manual refresh: Materialized views are not automatically refreshed. You must execute the REFRESH MATERIALIZED VIEW statement to manually refresh the materialized views. This refresh trigger mechanism is suitable for scenarios in which data consistency requirements are not high or data is not frequently changed.

  • Automatic refresh at scheduled intervals: Materialized views are automatically refreshed at scheduled intervals. If the last refresh is still in progress when the specified refresh time arrives, this refresh is skipped and waits for the next scheduled refresh time. This refresh trigger mechanism is suitable for scenarios in which the data of base tables periodically changes. For example, new transaction records are generated within a specific time range on a daily or weekly basis.

  • Automatic refresh when base tables are overwritten: Materialized views are automatically refreshed when base tables are overwritten by executing the INSERT OVERWRITE statement. This refresh trigger mechanism is suitable for scenarios in which data timeliness and consistency requirements are high.

The following table describes the refresh trigger mechanisms supported by each refresh policy.

Refresh policy

On-demand refresh (specified by the ON DEMAND clause)

Automatic refresh when base tables are overwritten (specified by the ON OVERWRITE clause)

Manual refresh

Automatic refresh at scheduled intervals (specified by the NEXT clause)

Complete refresh

✔️

✔️

✔️

Fast refresh

✔️

Define refresh policies and refresh trigger mechanisms for materialized views

The following examples show how to define refresh policies and refresh trigger mechanisms when you create materialized views based on the customer, sales, and product tables.

CREATE TABLE customer (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(255),
    is_vip Boolean
);
CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    product_id INT,
    customer_id INT,
    price DECIMAL(10, 2),
    quantity INT,
    sale_date TIMESTAMP
);
CREATE TABLE product (
    product_id INT PRIMARY KEY,
    product_name VARCHAR,
    category_id INT,
    unit_price DECIMAL(10, 2),
    stock_quantity INT
);

Create a materialized view that supports complete refresh

When you create a materialized view, you can use the REFRESH COMPLETE clause to set the refresh policy to complete refresh.

Materialized views that support complete refresh can use the following refresh trigger mechanisms: manual refresh, automatic refresh at scheduled intervals, and automatic refresh when base tables are overwritten.

  • Create a materialized view named compl_mv1 that supports complete refresh. No refresh trigger mechanism or NEXT clause is configured for the materialized view. In this case, manual refresh is used.

    CREATE MATERIALIZED VIEW compl_mv1
    REFRESH COMPLETE
    AS
    SELECT * FROM customer;
  • Create a materialized view named compl_mv2 that supports complete refresh. The ON DEMAND, START WITH, and NEXT clauses are configured for the materialized view. In this example, the materialized view is automatically refreshed at 02:00:00 every day.

    CREATE MATERIALIZED VIEW compl_mv2
    REFRESH COMPLETE ON DEMAND
     START WITH DATE_FORMAT(now() + interval 1 day, '%Y-%m-%d 02:00:00')
     NEXT DATE_FORMAT(now() + interval 1 day, '%Y-%m-%d 02:00:00')
    AS
    SELECT * FROM customer;
  • Create a materialized view named compl_mv3 that supports complete refresh. The ON OVERWRITE clause is configured for the materialized view. In this case, the NEXT clause is not required.

    CREATE MATERIALIZED VIEW compl_mv3
    REFRESH COMPLETE ON OVERWRITE
    AS
    SELECT * FROM customer;

Create a materialized view that supports fast refresh

When you create a materialized view, you can use the REFRESH FAST clause to set the refresh policy to fast refresh. Materialized views that support fast refresh can use only automatic refresh at scheduled intervals.

Enable the binary logging feature

Before you create a materialized view that supports fast refresh in an AnalyticDB for MySQL cluster, you must enable the binary logging feature for the cluster and base tables.

SET ADB_CONFIG BINLOG_ENABLE=true; --For AnalyticDB for MySQL clusters earlier than V3.2.0.0, you must execute the statement to enable the binary logging feature. For AnalyticDB for MySQL clusters of V3.2.0.0 or later, the binary logging feature is automatically enabled. 
ALTER TABLE customer binlog=true;
ALTER TABLE sales binlog=true;
ALTER TABLE product binlog=true;
Important
  • You can perform INSERT OVERWRITE INTO and TRUNCATE operations on tables for which the binary logging feature is enabled only in AnalyticDB for MySQL clusters of V3.2.0.0 or later.

  • After you create a materialized view that supports fast refresh, you cannot disable the binary logging feature for base tables.

  • After you delete a materialized view that supports fast refresh, you can execute the SET ADB_CONFIG BINLOG_ENABLE=false; and ALTER TABLE <table_name> binlog=false; statements to disable the binary logging feature for the AnalyticDB for MySQL cluster and base tables.

Single-table materialized views

  • Create a single-table materialized view named fast_mv1 that supports fast refresh at 10-second intervals. The materialized view query does not involve an aggregate function.

    CREATE MATERIALIZED VIEW fast_mv1
    REFRESH FAST NEXT now() + INTERVAL 10 second
    AS
    SELECT sale_id, sale_date, price
    FROM sales
    WHERE price > 10;
  • Create a single-table materialized view named fast_mv2 that supports fast refresh at 5-second intervals. The materialized view query involves an aggregate function with GROUP BY.

    CREATE MATERIALIZED VIEW fast_mv2
    REFRESH FAST NEXT now() + INTERVAL 5 second
    AS
    SELECT
       customer_id, sale_date,                 -- The system uses the GROUP BY columns as the primary key of the materialized view. 
       COUNT(sale_id) AS cnt_sale_id,          -- Perform an aggregate operation on a column. 
       SUM(price * quantity) AS total_revenue, -- Perform an aggregate operation on a column. 
       customer_id / 100 AS new_customer_id    -- You can use an expression to define columns that are not involved in aggregate operations. 
    FROM sales
    WHERE ifnull(price, 1) > 0                 -- You can use an expression to define WHERE conditions. 
    GROUP BY customer_id, sale_date;
  • Create a single-table materialized view named fast_mv3 that supports fast refresh at 1-minute intervals. The materialized view query involves an aggregate function without GROUP BY.

    CREATE MATERIALIZED VIEW fast_mv3
    REFRESH FAST NEXT now() + INTERVAL 1 minute
    AS
    SELECT count(*) AS cnt   -- The system generates a constant as the primary key to ensure that only one record is contained in the materialized view. 
    FROM sales;

Multi-table materialized views

  • Create a multi-table materialized view named fast_mv4 that supports fast refresh at 5-second intervals. The materialized view query does not involve an aggregate function.

    CREATE MATERIALIZED VIEW fast_mv4
    REFRESH FAST NEXT now() + INTERVAL 5 second
    AS
    SELECT 
        c.customer_id,
        c.customer_name,
        p.product_id,
        s.sale_id,
        (s.price * s.quantity) AS revenue
    FROM 
        sales s
    JOIN 
        customer c ON s.customer_id = c.customer_id
    JOIN 
        product p ON s.product_id = p.product_id;
  • Create a multi-table materialized view named fast_mv5 that supports fast refresh at 10-second intervals. The materialized view query involves an aggregate function with GROUP BY.

    CREATE MATERIALIZED VIEW fast_mv5
    REFRESH FAST NEXT now() + INTERVAL 10 second
    AS
    SELECT 
        s.sale_id,
        c.customer_name,
        p.product_name,
        COUNT(*) AS cnt,           
        SUM(s.price * s.quantity) AS revenue,         
        SUM(p.unit_price) AS sum_p          
    FROM 
        sales s
    JOIN 
        (SELECT customer_id, customer_name FROM customer) c ON c.customer_id = s.customer_id
    JOIN 
        (SELECT * FROM product WHERE stock_quantity > 0) p ON p.product_id = s.product_id
    GROUP BY 
        s.sale_id, c.customer_name, p.product_name;

Limits

When you adjust the number of reserved resource nodes in an AnalyticDB for MySQL cluster, you cannot perform complete refresh operations on materialized views because complete refresh runs in an asynchronous manner. However, fast refresh operations are supported for materialized views.

  • You cannot use partitioned tables as base tables to create a materialized view that supports fast refresh in AnalyticDB for MySQL clusters earlier than V3.2.3.0.

  • You cannot execute the INSERT OVERWRITE or TRUNCATE statement on base tables of a materialized view that supports fast refresh in AnalyticDB for MySQL clusters earlier than V3.2.3.1. Otherwise, an error occurs.

  • Materialized views that support fast refresh can only be automatically refreshed at scheduled intervals, and cannot be manually refreshed. The scheduled interval of fast refresh ranges from 5 seconds to 5 minutes.

  • The following limits are imposed on materialized view queries:

    • Materialized views must provide the same data as the query results on base tables and must support all DML operations. In this case, not all materialized view queries allow materialized views to support fast refresh. If the materialized view that you want to create does not support fast refresh, an error occurs.

    • You cannot specify expressions that may produce indefinite values as conditions in materialized view queries. Examples: now() and rand().

    • Materialized view queries support only the following aggregate functions: COUNT(), SUM(), MAX(), MIN(), AVG(), APPROX_DISTINCT(), and COUNT(DISTINCT).

    • If you use the MAX(), MIN(), APPROX_DISTINCT(), or COUNT(DISTINCT) function in materialized view queries, you can perform only INSERT operations on base tables. You cannot perform operations that may result in data deletion on base tables, such as DELETE, UPDATE, REPLACE, and INSERT ON DUPLICATE KEY UPDATE.

    • Aggregate functions except COUNT(DISTINCT) do not support the DISTINCT keyword in materialized view queries.

    • The COUNT(DISTINCT) function supports only the INTEGER type in materialized view queries.

    • The AVG() function does not support the DECIMAL type in materialized view queries.

    • Aggregate functions do not support the HAVING keyword in materialized view queries.

    • Materialized view queries do not support window functions.

    • Materialized view queries do not support sorting operations.

    • Materialized view queries do not support set operations, such as UNION, EXCEPT, and INTERSECT.

  • The following limits are imposed on multi-table materialized views that support fast refresh:

    • Multi-table materialized views support only INNER JOIN operations.

    • By default, you can join up to five base tables to create a materialized view. To create a materialized view that references more than five base tables, contact technical support to increase the maximum number of base tables based on your cluster specifications.

    • The fields that are used to join base tables must be the original fields of the tables and must work as indexes. The fields must be of the same data type.

Manually refresh a materialized view

If you set the refresh policy to ON DEMAND and do not specify the NEXT clause when you create a materialized view, the materialized view is not automatically refreshed. You can manually refresh the materialized view.

REFRESH MATERIALIZED VIEW <mv_name>;

After you initiate a refresh request, the system places the refresh job in the background queue. You can continue to perform other operations before the refresh job is complete.

When the refresh job is complete, the Query OK or Success message is returned.

Query the refresh records of a materialized view

Query the automatic refresh records

You can execute the following statement to query the automatic refresh records of a materialized view, including the start time, end time, status, and query ID. For more information about the fields in the query result, see Manage materialized views.

SELECT * FROM information_schema.mv_auto_refresh_jobs where mv_name = '<mv_name>';

Query the manual refresh records

  • To query the manual refresh records of materialized views within the last 30 days, use the SQL audit feature. After you enter REFRESH MATERIALIZED VIEW mv_name in the Keyword field on the XIHE SQL Audit tab, you can view information about the manual refresh records, such as the time, duration, IP address, and database account.

    You must separately enable the SQL audit feature. SQL operations that are performed before the SQL audit feature is enabled are not included in the audit logs.

    image

  • To query the manual and automatic refresh records of materialized views within the last 14 days, use the SQL diagnostics and optimization feature. After you enter the name of a materialized view, such as compl_mv1, on the SQL Diagnostics and Optimization tab, you can view information about all SQL queries of the materialized view, such as the start time, database account, duration, and query ID.

    image

Stop an ongoing refresh job

If a refresh job of a materialized view runs for an extended period of time, you can contact technical support to stop the refresh job.

Usage notes

If you execute the KILL PROCESS <process_id>; statement to stop a refresh job, the next refresh is still triggered when the next refresh time arrives or when base tables are overwritten.

References