MySQL ビューの原則分析

ビューは MySQL 5.0 以降で導入されました。ビューは、実際にはデータ自体を格納しない仮想データ テーブルです。この仮想テーブルのデータは、実際にはビューにアクセスする SQL クエリの結果から取得されます。 MySQL はテーブルを処理するのと同様の方法でビューを処理し、このアプローチを使用して多くのニーズを満たすことができます。 MySQL ではビューとテーブルは同じ名前空間を共有しますが、MySQL ではそれらを異なる方法で処理します。たとえば、ビューにはトリガーがなく、DROP TABLE を使用してビューを削除することはできません。

以下では、ビューの動作メカニズムを説明するために、ワールド サンプル データベースを例として使用します。

ビューの作成 オセアニア AS
	Country から * を選択、Continent が 'Oceania' の場合
  チェックオプション付き;

ビューを実装する最も簡単な方法は、SELECT クエリを実行し、その結果を一時テーブルに格納することです。その後は、ビューが表示される場所であればどこでもこの一時テーブルを参照できます。たとえば、次のクエリ:

SELECT Code, Name FROM Oceania WHERE Name = 'Australia';

以下は、上記のステートメントを実行するサーバーの可能な形式です (一時テーブル名は任意であり、実際の内部コンテンツは不明です)。

一時テーブルTMP_Oceania_123 ASを作成します 
	SELECT * FROM Country WHERE Con​​tinent = 'オセアニア';
SELECT Code, Name FROM TMP_Oceania_123 WHERE NAME = 'Australia';

この形式には明らかにパフォーマンスの問題があります。最善の方法は、次に示すように、ビューとクエリの分散クエリを 1 つの SQL ステートメントに変更することです。

国からコード、名前を選択
大陸 = 'オセアニア'、名前 = 'オーストラリア';

MySQL では、MERGE と TEMTABLE という 2 つのアルゴリズムが使用され、可能な限り MERGE アルゴリズムが使用されます。 MySQL ではネストされたビューをマージすることもできます。次の図は、2 つのアルゴリズムの違いを示しています。

MySQL は、ビューに GROUP BY、DISTINCT、集計関数、UNION、サブクエリ、または 1 対 1 の関係を持たないその他のテーブルがある場合に TEMPTABLE アルゴリズムを使用します。ビューが MERGE または TEMPTABLE を使用しているかどうかを知りたい場合は、EXPLAIN コマンドを使用して確認できます。

EXPLAIN SELECT * FROM <ビュー名>;

select_type に DERIVED がある場合は、TEMPTABLE アルゴリズムが使用されていることを意味します。したがって、非表示の派生テーブルの生成にコストがかかる場合、派生テーブルを実際に実行して構築する必要があるため、EXPLAIN は非常に非効率になり、実行速度が遅くなります。このアルゴリズムはビューのプロパティであり、クエリ タイプの影響を受けません。たとえば、ビューの作成時にアルゴリズムが指定されている場合、最適化の余地があっても、このビューに対する後続のクエリではアルゴリズムは変更されません。

CREATE ALGORITHM=TEMPTABLE VIEW v1 AS
Country から * を選択;

更新可能なビュー

更新可能なビューは、ビューによって隠されている基になるテーブルを更新できます。指定された条件が満たされている限り、通常のテーブルを操作するのと同じように、UPDATE、DELETE、さらには INSERT 操作を使用できます。たとえば、次の操作は有効です。

オセアニアを更新 SET Population = Population * 1.1 WHERE NAME = 'Australia';

ビューに GROUP BY、UNION、集計関数、またはその他の概念が含まれている場合、ビューは更新できません。 TEMPTABLE アルゴリズムを使用するすべてのビューは更新できません。

CHECK OPTION 句は、ビューを通じて変更されたデータ行が、変更後もビューの WHERE 条件と一致し続けることを確認するために使用されます。たとえば、上記の例では、異なる大陸値を持つ行が挿入されると、サーバーはエラーを報告します。

ビューのパフォーマンス

多くの人は、パフォーマンスを向上させるためにビューを使用することを考えませんが、場合によってはそれが可能です。さらに、ビューは他の領域のパフォーマンスを向上させるためにも使用できます。たとえば、テーブル構造が再構築された場合、変更されたデータ テーブルのビューを変更せずに使用できます。列権限を作成するオーバーヘッドを追加せずに、ビューを使用してフィールド権限制御を実装することもできます。

VIEW public.employeeinfo AS を作成します
	SELECT firstname, lastname --ID 番号を除く FROM private.employeeinfo;
public_user に public.* の SELECT 権限を付与します。

TEMPTABLE アルゴリズムを使用するビューのパフォーマンスは非常に低くなる可能性があります (ただし、同等の SQL クエリよりも優れている可能性があります)。このビューには最適化の余地があまりありません。

ビューは実際には非常に複雑であるにもかかわらず、開発者を騙してシンプルだと思わせる可能性があります。開発者がビューの複雑さを理解していない場合、ビューと通常のテーブルクエリの違いに気付かないでしょう。 EXPLAIN コマンドを使用すると、数百行の分析結果が出力されることがあります。これは、データ テーブルのように見えるクエリが実際にはビューであり、そのビューが他のデータ テーブルや他のビューを参照する可能性があるためです。

ビューを使用してパフォーマンスを向上させるには、慎重な分析とテストが必要です。 MERGE アルゴリズムを使用したビューでも余分なオーバーヘッドが追加される可能性があり、パフォーマンスへの影響を予測することは困難です。ビューは実際には MySQL の別の最適化アプローチを使用します。同時実行性の高いシナリオでは、ビューによってクエリ オプティマイザーが計画と統計に多くの時間を費やすようになり、サーバー側の遅延が発生することもあります。このとき、ビューを置き換えるには通常の SQL を使用する必要があります。

ビューの制限

MySQL は、他のデータベース サーバーのように物理ビューをサポートしていません (物理ビューは、非表示のテーブルに結果を生成して保存し、ソース データからビューを更新するために定期的に更新されるビューです)。 MySQL はビューのインデックスもサポートしていません。 MySQL はビューの元の SQL も保持しません。SHOW CREATE VIEW コマンドを実行してビューを編集し、返される結果の SQL を変更すると、結果が非​​常に奇妙であることがわかります。クエリ SQL は仕様に従って展開され、書式設定、コメント、インデントのない内部形式でラップされます。

以上はMySQLビュー（View）の原理の詳細な分析です。MySQLビュー（View）の原理の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。