マテリアライズドビューは、複雑なクエリの高速化や、抽出、変換、ロード (ETL) 操作の簡素化に使用できます。 マテリアライズドビューは、事前に計算されたクエリ結果を格納し、格納されたクエリ結果は、さまざまなビジネス要件に基づいてリフレッシュされます。 ベーステーブルの書き込みモード、マテリアライズドビュースキーマの SQL 計算の複雑さ、マテリアライズドビューのデータ適時性に基づいて、マテリアライズドビューのリフレッシュポリシーを選択できます。
リフレッシュポリシーを選択する
マテリアライズドビューは、完全リフレッシュと高速リフレッシュの 2 つのリフレッシュポリシーをサポートしています。
完全リフレッシュは、マテリアライズドビュースキーマを実行して、関連するすべてのベーステーブルパーティションのデータをスキャンし、クエリ結果を使用してマテリアライズドビューの元のデータを上書きします。
高速リフレッシュは、マテリアライズドビュースキーマを書き直して、ベーステーブルの更新されたデータのみをスキャンし、マテリアライズドビューのデータを更新します。 これにより、ベーステーブルのすべてのデータがスキャンされるのを防ぎ、リフレッシュのオーバーヘッドを削減します。
次の表は、2 つのリフレッシュポリシーの適用可能なシナリオ、利点、および制限を示しています。
リフレッシュポリシー | シナリオ | 特徴 |
完全リフレッシュ | バッチ処理シナリオ:
| 利点: マテリアライズドビュースキーマはすべての SQL 文をサポートしています。 |
制限: 完全なデータはバッチでのみ更新できます。 | ||
高速リフレッシュ | リアルタイム分析シナリオ:
| 利点:
|
制限:
|
リフレッシュトリガーメカニズムを選択する
リフレッシュポリシーに加えて、マテリアライズドビューを作成するときに、リフレッシュトリガーメカニズムを定義する必要があります。 マテリアライズドビューのリフレッシュトリガーメカニズムは、オンデマンドリフレッシュ (ON DEMAND 句で指定) と、ベーステーブルが上書きされた場合の自動リフレッシュ (ON OVERWRITE 句で指定) に分けることができます。 オンデマンドリフレッシュは、スケジュールされた間隔での自動リフレッシュと手動リフレッシュに分けられます。 リフレッシュトリガーメカニズムを指定しない場合は、オンデマンドリフレッシュが使用されます。
リフレッシュトリガーメカニズムを選択する場合は、マテリアライズドビューのデータ適時性とクラスタワークロードを考慮する必要があります。 次のセクションでは、さまざまなリフレッシュトリガーメカニズムの特徴とシナリオについて説明します。
手動リフレッシュ: マテリアライズドビューは自動的にリフレッシュされません。
REFRESH MATERIALIZED VIEW文を実行して、マテリアライズドビューを手動でリフレッシュする必要があります。 このリフレッシュトリガーメカニズムは、データ整合性要件が高くない、またはデータが頻繁に変更されないシナリオに適しています。スケジュールされた間隔での自動リフレッシュ: マテリアライズドビューは、スケジュールされた間隔で自動的にリフレッシュされます。 指定されたリフレッシュ時刻になったときに、最後のリフレッシュがまだ進行中の場合、このリフレッシュはスキップされ、次のスケジュールされたリフレッシュ時刻が待機されます。 このリフレッシュトリガーメカニズムは、ベーステーブルのデータが定期的に変更されるシナリオに適しています。 たとえば、新しいトランザクションレコードは、毎日または毎週の特定の時間範囲内に生成されます。
ベーステーブルが上書きされた場合の自動リフレッシュ: INSERT OVERWRITE 文を実行すると、ベーステーブルが上書きされたときに、マテリアライズドビューが自動的にリフレッシュされます。 このリフレッシュトリガーメカニズムは、データ適時性と整合性要件が高いシナリオに適しています。
次の表は、各リフレッシュポリシーでサポートされているリフレッシュトリガーメカニズムを示しています。
リフレッシュポリシー | オンデマンドリフレッシュ (ON DEMAND 句で指定) | ベーステーブルが上書きされた場合の自動リフレッシュ (ON OVERWRITE 句で指定) | |
手動リフレッシュ | スケジュールされた間隔での自動リフレッシュ (NEXT 句で指定) | ||
完全リフレッシュ | ✔️ | ✔️ | ✔️ |
高速リフレッシュ | ❌ | ✔️ | ❌ |
マテリアライズドビューのリフレッシュポリシーとリフレッシュトリガーメカニズムを定義する
次の例は、顧客、売上、製品テーブルに基づいてマテリアライズドビューを作成するときに、リフレッシュポリシーとリフレッシュトリガーメカニズムを定義する方法を示しています。
/*+ 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 句が構成されています。この例では、マテリアライズドビューは毎日 02:00:00 に自動的にリフレッシュされます。
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 句を使用して、リフレッシュポリシーを高速リフレッシュに設定できます。 高速リフレッシュをサポートするマテリアライズドビューは、スケジュールされた間隔での自動リフレッシュのみを使用できます。
バイナリロギング機能を有効にする
AnalyticDB for MySQL クラスターで高速リフレッシュをサポートするマテリアライズドビューを作成する前に、クラスターとベーステーブルのバイナリロギング機能を有効にする必要があります。
SET ADB_CONFIG BINLOG_ENABLE=true; --V3.2.0.0 より前の AnalyticDB for MySQL クラスターの場合、この文を実行してバイナリロギング機能を有効にする必要があります。 V3.2.0.0 以降の AnalyticDB for MySQL クラスターの場合、バイナリロギング機能は自動的に有効になります。
ALTER TABLE customer binlog=true;
ALTER TABLE sales binlog=true;
ALTER TABLE product binlog=true;V3.2.0.0 以降の AnalyticDB for MySQL クラスターでは、バイナリロギング機能が有効になっているテーブルに対してのみ、INSERT OVERWRITE INTO 操作と TRUNCATE 操作を実行できます。
高速リフレッシュをサポートするマテリアライズドビューを作成した後、ベーステーブルのバイナリロギング機能を無効にすることはできません。
高速リフレッシュをサポートするマテリアライズドビューを削除した後、
SET ADB_CONFIG BINLOG_ENABLE=false;文とALTER TABLE <table_name> binlog=false;文を実行して、AnalyticDB for MySQL クラスターとベーステーブルのバイナリロギング機能を無効にすることができます。
単一テーブルマテリアライズドビュー
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;5 秒間隔で高速リフレッシュをサポートする、fast_mv2 という名前の単一テーブルマテリアライズドビューを作成します。 マテリアライズドビュークエリには、GROUP BY を伴う集計関数が含まれます。
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 -- 式を使用して WHERE 条件を定義できます。 GROUP BY customer_id, sale_date;1 分間隔で高速リフレッシュをサポートする、fast_mv3 という名前の単一テーブルマテリアライズドビューを作成します。 マテリアライズドビュークエリには、GROUP BY を伴わない集計関数が含まれます。
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;10 秒間隔で高速リフレッシュをサポートする、fast_mv5 という名前の複数テーブルマテリアライズドビューを作成します。 マテリアライズドビュークエリには、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;
制限事項
高速リフレッシュをサポートするマテリアライズドビューの以下の制限事項に注意してください。
V3.2.3.0 より前の AnalyticDB for MySQL クラスターでは、パーティションテーブルをベーステーブルとして使用して、高速リフレッシュをサポートするマテリアライズドビューを作成することはできません。
V3.2.3.1 より前の AnalyticDB for MySQL クラスターでは、高速リフレッシュをサポートするマテリアライズドビューのベーステーブルに対して INSERT OVERWRITE 文または TRUNCATE 文を実行することはできません。実行すると、エラーが発生します。
高速リフレッシュをサポートするマテリアライズドビューは、スケジュールされた間隔で自動的にリフレッシュすることのみが可能で、手動でリフレッシュすることはできません。 高速リフレッシュのスケジュール間隔は 5 秒から 5 分です。
マテリアライズドビュークエリには、以下の制限が課せられます。
マテリアライズドビューは、ベーステーブルのクエリ結果と同じデータを提供し、すべての DML 操作をサポートする必要があります。 この場合、すべてのマテリアライズドビュークエリがマテリアライズドビューの高速リフレッシュをサポートできるわけではありません。 作成するマテリアライズドビューが高速リフレッシュをサポートしていない場合は、エラーが発生します。
不定の値を生成する可能性のある式 (例:
now()やrand()) をマテリアライズドビュークエリの条件として指定することはできません。マテリアライズドビュークエリは、COUNT()、SUM()、MAX()、MIN()、AVG()、APPROX_DISTINCT()、COUNT(DISTINCT) の集計関数のみをサポートします。
マテリアライズドビュークエリで MAX()、MIN()、APPROX_DISTINCT()、または COUNT(DISTINCT) 関数を使用する場合、ベーステーブルに対して INSERT 操作のみを実行できます。 DELETE、UPDATE、REPLACE、INSERT ON DUPLICATE KEY UPDATE など、データの削除につながる可能性のある操作は、ベーステーブルに対して実行できません。
COUNT(DISTINCT) 以外の集計関数は、マテリアライズドビュークエリで DISTINCT キーワードをサポートしていません。
COUNT(DISTINCT) 関数は、マテリアライズドビュークエリで INTEGER 型のみをサポートします。
AVG() 関数は、マテリアライズドビュークエリで DECIMAL 型をサポートしていません。
集計関数は、マテリアライズドビュークエリで HAVING キーワードをサポートしていません。
マテリアライズドビュークエリは、ウィンドウ関数をサポートしていません。
マテリアライズドビュークエリは、ソート操作をサポートしていません。
マテリアライズドビュークエリは、UNION、EXCEPT、INTERSECT などの集合演算をサポートしていません。
高速リフレッシュをサポートする複数テーブルマテリアライズドビューには、以下の制限が課せられます。
複数テーブルマテリアライズドビューは、INNER JOIN 操作のみをサポートします。
デフォルトでは、最大 5 つのベーステーブルを結合してマテリアライズドビューを作成できます。
ベーステーブルの結合に使用されるフィールドは、テーブルの元のフィールドである必要があり、インデックスとして機能する必要があります。 フィールドは同じデータ型である必要があります。
マテリアライズドビューを手動でリフレッシュする
マテリアライズドビューを作成するときに、リフレッシュポリシーを ON DEMAND に設定し、NEXT 句を指定しないと、マテリアライズドビューは自動的にリフレッシュされません。 マテリアライズドビューを手動でリフレッシュできます。
REFRESH MATERIALIZED VIEW <mv_name>;リフレッシュリクエストを開始すると、システムはリフレッシュジョブをバックグラウンドキューに配置します。 リフレッシュジョブが完了する前に、他の操作を続行できます。
リフレッシュジョブが完了すると、Query OK または Success メッセージが返されます。
マテリアライズドビューのリフレッシュレコードを照会する
自動リフレッシュレコードを照会する
次の文を実行して、開始時刻、終了時刻、ステータス、クエリ ID など、マテリアライズドビューの自動リフレッシュレコードを照会できます。 クエリ結果のフィールドの詳細については、「マテリアライズドビューを管理する」をご参照ください。
SELECT * FROM information_schema.mv_auto_refresh_jobs where mv_name = '<mv_name>';手動リフレッシュレコードを照会する
過去 30 日以内に行われたマテリアライズドビューの手動リフレッシュレコードを照会するには、SQL 監査機能を使用します。 [XIHE SQL 監査] タブの [キーワード] フィールドに REFRESH MATERIALIZED VIEW mv_name と入力すると、時刻、期間、IP アドレス、データベースアカウントなど、手動リフレッシュレコードに関する情報を表示できます。
SQL 監査機能は個別に有効にする必要があります。 SQL 監査機能が有効になる前に行われた SQL 操作は、監査ログには含まれません。

過去 14 日以内に行われたマテリアライズドビューの手動および自動リフレッシュレコードを照会するには、SQL 診断と最適化機能を使用します。 [SQL 診断と最適化] タブで compl_mv1 などのマテリアライズドビューの名前を入力すると、開始時刻、データベースアカウント、期間、クエリ ID など、マテリアライズドビューのすべての SQL クエリに関する情報を表示できます。

進行中のリフレッシュジョブを停止する
マテリアライズドビューのリフレッシュジョブが長時間実行されている場合は、テクニカルサポートに連絡してリフレッシュジョブを停止することができます。
使用上の注意
KILL PROCESS <process_id>; 文を実行してリフレッシュジョブを停止した場合でも、次のリフレッシュ時刻になったとき、またはベーステーブルが上書きされたときに、次のリフレッシュがトリガーされます。
参照
マテリアライズドビューを作成する: マテリアライズドビューの作成方法について説明します。
CREATE MATERIALIZED VIEW: マテリアライズドビューの構文について説明します。
マテリアライズドビューを管理する: マテリアライズドビューの定義とリフレッシュレコードの照会、マテリアライズドビューの変更、マテリアライズドビューの削除の方法について説明します。