すべてのプロダクト
Search
ドキュメントセンター

AnalyticDB:マテリアライズドビューのリフレッシュ

最終更新日:Jul 03, 2026

マテリアライズドビューは、複雑なクエリの高速化や ETL プロセスの簡素化によく使用されます。これは、ユーザー定義のクエリを事前に計算し、その結果を保存することで動作します。ベーステーブルの書き込みパターン、クエリの計算量(query_body)、およびデータ新鮮さの要件に基づいて、マテリアライズドビューのリフレッシュポリシーを定義できます。

リフレッシュポリシーの選択

マテリアライズドビューは、完全リフレッシュ(COMPLETE)と高速リフレッシュ(FAST)の 2 種類のリフレッシュポリシーをサポートしています。

  • 完全リフレッシュでは、元のクエリ SQL を実行してベーステーブルのすべての対象パーティションのデータをスキャンし、新たに計算されたデータで古いデータを完全に上書きします。

  • 高速リフレッシュを実行します。システムはビューのクエリ(query_body)を書き換えて、ベーステーブル内の変更されたデータ(INSERTDELETE、および UPDATE 操作によるもの)のみをスキャンし、これらの変更をマテリアライズドビューに適用します。これにより、各サイクルでベーステーブル全体をスキャンする必要がなくなり、各リフレッシュの計算コストが削減されます。

次の表は、2 種類のリフレッシュポリシーのユースケース、メリット、および制限事項を比較したものです。

リフレッシュポリシー

ユースケース

特徴

完全リフレッシュ

オフラインシナリオ:

  • 日次バッチ更新(T+1)

  • 時間単位のデータ更新

  • 計算量が少なく、分単位の遅延が許容される小規模データセット。

メリット: query_body は任意の SQL クエリをサポートします。

制限事項: 完全な一括更新しか実行できません。

高速リフレッシュ

リアルタイムシナリオ:

  • リアルタイムデータインジェスト。

  • リアルタイム更新を必要とするレポートまたは ETL パイプライン。

  • 秒単位のデータ新鮮さを要求するユースケース。

メリット:

  • 通常、処理するデータ量が小さく、オーバーヘッドが低くなります。

  • ストリーム処理を置き換えることができ、開発およびメンテナンスコストを削減します。

制限事項:

  • エンジンバージョン、ベーステーブル、および query_body に関する制限事項があります。

  • 手動リフレッシュおよび上書きトリガーリフレッシュはサポートされていません。

リフレッシュトリガーの選択

マテリアライズドビューを作成する際には、リフレッシュポリシーとリフレッシュトリガーの両方を定義します。マテリアライズドビューは、オンデマンドリフレッシュ(ON DEMAND)および上書きトリガーリフレッシュ(ON OVERWRITE)をサポートしています。オンデマンドリフレッシュはさらに、スケジュールリフレッシュと手動リフレッシュに分けられます。リフレッシュトリガーを指定しない場合、デフォルトはオンデマンドリフレッシュになります。

リフレッシュトリガーを選択する際は、データ新鮮さの要件とクラスターロードを考慮してください。各トリガーの特徴とユースケースは以下のとおりです。

  • 手動リフレッシュ: マテリアライズドビューは自動的にデータをリフレッシュしません。REFRESH MATERIALIZED VIEW を実行して、手動でデータをリフレッシュする必要があります。これは、データ整合性の優先度が高くない、またはデータの変更がまれなシナリオに適しています。

  • スケジュールリフレッシュ: マテリアライズドビューは指定された時刻に自動的にリフレッシュされます。次のリフレッシュのスケジュール時刻になっても前回のリフレッシュがまだ実行中の場合、システムは新しいリフレッシュをスキップし、次の間隔まで待ちます。これは、ベーステーブルのデータが定期的に変更されるシナリオ(例:毎日または毎週の固定期間中に生成される新しいトランザクションレコード)に適しています。

  • 上書きトリガーリフレッシュ: ベーステーブルが INSERT OVERWRITE を使用して上書きされると、マテリアライズドビューが自動的にリフレッシュされます。これは、リアルタイムデータと整合性に対する要件が高いシナリオに適しています。

異なるリフレッシュポリシーでは、サポートされるリフレッシュトリガーが異なります。次の表をご参照ください。

リフレッシュポリシー

オンデマンドリフレッシュ (ON DEMAND)

上書きトリガーリフレッシュ (ON OVERWRITE)

手動リフレッシュ

スケジュールリフレッシュ

完全リフレッシュ

✔️

✔️

✔️

高速リフレッシュ

✔️

リフレッシュポリシーとトリガーの定義

以下の例では、customer、sales、および product テーブルを使用して、新しいマテリアライズドビューのリフレッシュポリシーとリフレッシュトリガーを定義する方法を示します。

/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- テーブルエンジンを XUANWU に設定します。
CREATE TABLE customer (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(255),
    is_vip Boolean
);

/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- テーブルエンジンを XUANWU に設定します。
CREATE TABLE sales (
    sale_id INT PRIMARY KEY,
    product_id INT,
    customer_id INT,
    price DECIMAL(10, 2),
    quantity INT,
    sale_date TIMESTAMP
);
/*+ RC_DDL_ENGINE_REWRITE_XUANWUV2=false */ -- テーブルエンジンを XUANWU に設定します。
CREATE TABLE product (
    product_id INT PRIMARY KEY,
    product_name VARCHAR,
    category_id INT,
    unit_price DECIMAL(10, 2),
    stock_quantity INT
);

完全リフレッシュマテリアライズドビューの作成

マテリアライズドビューを作成する際、完全リフレッシュポリシーを指定するために REFRESH COMPLETE キーワードを使用します。

完全リフレッシュを使用するマテリアライズドビューは、手動リフレッシュ、スケジュールリフレッシュ、および上書きトリガーリフレッシュをサポートしています。

  • compl_mv1 という名前の完全リフレッシュマテリアライズドビューを作成します。このビューはリフレッシュトリガーまたは NEXT パラメーターを定義していないため、デフォルトで手動でトリガーされるオンデマンドリフレッシュになります。

    CREATE MATERIALIZED VIEW compl_mv1
    REFRESH COMPLETE
    AS
    SELECT * FROM customer;
  • compl_mv2 という名前の完全リフレッシュマテリアライズドビューを作成します。このビューはオンデマンドリフレッシュ(ON DEMAND)を定義し、初期(START WITH)および後続(NEXT)のリフレッシュ時刻を指定しています。この例では、ビューは毎日午前 2 時に自動的にリフレッシュされます。

    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;
  • compl_mv3 という名前の完全リフレッシュマテリアライズドビューを作成します。このビューは上書きトリガーリフレッシュ(ON OVERWRITE)用に構成されています。このモードでは NEXT 句は不要です。

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

高速リフレッシュマテリアライズドビューの作成

マテリアライズドビューを作成する際、高速リフレッシュポリシーを指定するために REFRESH FAST キーワードを使用します。高速リフレッシュを使用するマテリアライズドビューは、スケジュールリフレッシュのみをサポートしています。

バイナリロギングの有効化

高速リフレッシュを使用するマテリアライズドビューを作成する前に、クラスターおよびそのベーステーブルに対してバイナリロギングを有効にする必要があります。

SET ADB_CONFIG BINLOG_ENABLE=true; -- エンジンバージョン 3.2.0.0 より前のクラスターでは、このコマンドを実行してバイナリロギングを有効にしてください。バージョン 3.2.0.0 以降ではデフォルトで有効になっています。
ALTER TABLE customer binlog=true;
ALTER TABLE sales binlog=true;
ALTER TABLE product binlog=true;
重要
  • INSERT OVERWRITE INTO および TRUNCATE 操作は、エンジンバージョン 3.2.0.0 以降でのみ、バイナリロギングが有効になっているテーブルでサポートされます。

  • 高速リフレッシュマテリアライズドビューを作成した後は、ベーステーブルのバイナリロギングを無効にすることはできません。

  • 高速リフレッシュを使用するマテリアライズドビューを削除した後は、SET ADB_CONFIG BINLOG_ENABLE=false; および ALTER TABLE <table_name> binlog=false; を実行して、クラスターおよびベーステーブルのバイナリロギングを手動で無効にできます。

単一テーブルマテリアライズドビュー

  • 集約操作なしで高速リフレッシュを使用し、10 秒ごとにリフレッシュされる単一テーブルマテリアライズドビュー fast_mv1 を作成します。

    CREATE MATERIALIZED VIEW fast_mv1
    REFRESH FAST NEXT now() + INTERVAL 10 second
    AS
    SELECT sale_id, sale_date, price
    FROM sales
    WHERE price > 10;
  • GROUP BY 集約を使用して高速リフレッシュを行い、5 秒ごとにリフレッシュされる単一テーブルマテリアライズドビュー fast_mv2 を作成します。

    CREATE MATERIALIZED VIEW fast_mv2
    REFRESH FAST NEXT now() + INTERVAL 5 second
    AS
    SELECT
       customer_id, sale_date,                 -- システムは GROUP BY の列をマテリアライズドビューのプライマリキーとして使用します。
       COUNT(sale_id) AS cnt_sale_id,          -- 集計出力列。
       SUM(price * quantity) AS total_revenue, -- 集計出力列。
       customer_id / 100 AS new_customer_id    -- 非集計出力列では任意の式を使用できます。
    FROM sales
    WHERE ifnull(price, 1) > 0                 -- 条件では任意の式を使用できます。
    GROUP BY customer_id, sale_date;
  • GROUP BY 集約なしで高速リフレッシュを行い、1 分ごとにリフレッシュされる単一テーブルマテリアライズドビュー fast_mv3 を作成します。

    CREATE MATERIALIZED VIEW fast_mv3
    REFRESH FAST NEXT now() + INTERVAL 1 minute
    AS
    SELECT count(*) AS cnt   -- システムは定数プライマリキーを生成して、マテリアライズドビューに 1 つのレコードのみが含まれるようにします。
    FROM sales;

複数テーブルマテリアライズドビュー

  • 集約操作なしで高速リフレッシュを行い、5 秒ごとにリフレッシュされる複数テーブルマテリアライズドビュー fast_mv4 を作成します。

    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;
  • GROUP BY 集約を使用して高速リフレッシュを行い、10 秒ごとにリフレッシュされる複数テーブルマテリアライズドビュー fast_mv5 を作成します。

    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;

注記

ベーステーブルに対して TRUNCATE または INSERT OVERWRITE 操作が実行された場合、またはデータの正確性に影響を与える可能性のある内部アノマリーが発生した場合、増分マテリアライズドビューは自動的に一度だけ完全リフレッシュにフォールバックします。完全リフレッシュが成功すると、その後のリフレッシュは自動的に増分モードで再開されます。

制限事項

高速リフレッシュを使用するマテリアライズドビューには、以下の制限事項が適用されます。

  • エンジンバージョンが 3.2.3.0 より前のクラスターでは、パーティションテーブルを高速リフレッシュを使用するマテリアライズドビューのベーステーブルにすることはできません。

  • エンジンバージョンが 3.2.3.1 より前のクラスターでは、高速リフレッシュを使用するマテリアライズドビューのベーステーブルに対して INSERT OVERWRITE および TRUNCATE 操作はサポートされていません。これらの操作を実行するとエラーが発生します。

  • 高速リフレッシュは、5 秒(s)~5 分(min)の間隔を持つスケジュールリフレッシュのみをサポートしています。

  • 高速リフレッシュを使用するマテリアライズドビューの query_body には、以下の制限事項があります。

    • マテリアライズドビューは、その結果がベーステーブルに対する直接クエリと同一であることを保証し、すべての DML 変更をサポートする必要があります。query_body が高速リフレッシュをサポートしていない場合、CREATE MATERIALIZED VIEW 文はエラーを返します。

    • 条件には、now()rand() などの非決定的式を含めることはできません。

    • サポートされる集計関数は、COUNT、SUM、MAX、MIN、AVG、APPROX_DISTINCT、および COUNT(DISTINCT) のみです。

    • query_body で MAX、MIN、APPROX_DISTINCT、または COUNT(DISTINCT) 集計関数を使用する場合、ベーステーブルに対して INSERT 操作のみが許可されます。DELETE、UPDATE、REPLACE、INSERT ON DUPLICATE KEY UPDATE などのデータ削除操作は禁止されています。

    • DISTINCT キーワードは、COUNT(DISTINCT) 以外の集計関数ではサポートされていません。

    • COUNT(DISTINCT) は INTEGER 型のみをサポートしています。

    • AVG は DECIMAL 型をサポートしていません。

    • 集約操作では HAVING キーワードはサポートされていません。

    • ウィンドウ関数はサポートされていません。

    • ソート操作はサポートされていません。

    • UNION、EXCEPT、INTERSECT などの集合演算はサポートされていません。

  • 高速リフレッシュを使用する複数テーブルマテリアライズドビューには、以下の追加の制限事項があります。

    • 複数テーブルマテリアライズドビューは現在、INNER JOIN のみをサポートしています。

    • デフォルトでは、複数テーブルマテリアライズドビューは最大 5 つのテーブルを結合できます。

    • 複数テーブルマテリアライズドビューの結合列は、テーブルの元の列であり、同じデータの型を持ち、各結合列にインデックスが存在している必要があります。

マテリアライズドビューの手動リフレッシュ

マテリアライズドビューが ON DEMAND リフレッシュポリシーで作成され、かつ NEXT 句が定義されていない場合、自動的にリフレッシュされません。マテリアライズドビューを手動でリフレッシュする必要があります。

REFRESH MATERIALIZED VIEW <mv_name>;

リフレッシュリクエストを送信すると、システムはリフレッシュジョブをバックグラウンドキューに追加します。リフレッシュが完了するのを待たずに、他の操作を継続できます。

Query OK または Success の戻りメッセージは、リフレッシュジョブがキューに正常に送信されたことを示します。

リフレッシュレコードの照会

自動リフレッシュレコードの照会

特定のマテリアライズドビューの自動リフレッシュレコード(開始時刻(start_time)、終了時刻(end_time)、ステータス(state)、プロセス ID(process_id)を含む)を照会するには、次の SQL ステートメントを実行します。戻り値のフィールドの詳細については、「マテリアライズドビューの管理」をご参照ください。

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

手動リフレッシュレコードの照会

  • 過去 30 日間の手動リフレッシュレコードを照会するには、SQL 監査機能を使用できます。照会時に、キーワード REFRESH MATERIALIZED VIEW mv_name を入力して、各手動リフレッシュの時刻、持続時間、IP アドレス、データベースアカウントなどの情報を検索します。

    SQL 監査機能は別途有効化する必要があります。有効化前に発生した SQL 操作は監査ログに記録されません。
  • 過去 14 日間の手動および自動リフレッシュレコードを照会するには、SQL 診断および最適化機能を使用できます。照会時に、compl_mv1 などのマテリアライズドビュー名を入力して、作成、手動リフレッシュ、自動リフレッシュ、変更など、関連するすべての SQL クエリの開始時刻、データベースアカウント、持続時間、プロセス ID などの情報を検索します。

実行中のリフレッシュジョブの停止

リフレッシュジョブの実行時間が長すぎる場合は、プロセス ID を使用して手動で停止できます。失敗した場合は、テクニカルサポートにお問い合わせください。

注記

KILL PROCESS <process_id>; を使用してリフレッシュジョブを停止した場合、次のリフレッシュは次のスケジュール時刻または次のベーステーブル上書き時に引き続きトリガーされることにご注意ください。

関連ドキュメント