Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


D.5 ビューの制約

ビューの処理は最適化されていません。

  • ビューにはインデックスを作成できません。

  • マージアルゴリズムを使用して処理されたビューに、インデックスを使用することは可能です。ただし、TEMPTABLE アルゴリズムで処理されたビューは、そのベースとなるテーブルのインデックスを利用できません (ただし、一時テーブルの作成中にはインデックスを使用できます)。

ビューの FROM 句ではサブクエリーは使用できません。

一般的な原則では、テーブルを変更することも、サブクエリーの同じテーブルから選択することもできません。セクションD.4「サブクエリーの制約」を参照してください。

テーブルから選択するビューを選ぶ場合、ビューがサブクエリーのテーブルから選択される場合や、ビューがマージアルゴリズムを使用して評価される場合にも、同じ原則が適用されます。例:

CREATE VIEW v1 AS
SELECT * FROM t2 WHERE EXISTS (SELECT 1 FROM t1 WHERE t1.a = t2.a);

UPDATE t1, v2 SET t1.a = 1 WHERE t1.b = v2.b;

一時テーブルを使用してビューが評価される場合、ビューサブクエリーのテーブルから選択し、さらに外部クエリーでそのテーブルを変更することが可能です。この場合、ビューは一時テーブルに格納されるため、実際にはビューをサブクエリーのテーブルから選択して同時に変更しているのではありません。(これは、ビュー定義で ALGORITHM = TEMPTABLE を指定することによって、MySQL で TEMPTABLE アルゴリズムを強制的に使用させる 1 つの理由です。)

DROP TABLE または ALTER TABLE を使用すると、ビュー定義で使用されているテーブルを削除または変更できます。ビューを無効化する場合でも、DROP または ALTER 操作によって警告が発せられることはありません。代わりに、あとからビューを使用するときにエラーが発生します。CHECK TABLE は、DROP または ALTER 操作で無効化されたビューのチェックに使用できます。

MySQL 5.6.5 より前では、ビュー定義は特定のステートメントによって固定されます。PREPARE で準備されたステートメントがビューを参照する場合、あとでステートメントが実行されるたびに確認されるビュー定義は、準備された時点のビュー定義になります。これは、ステートメントが準備されたあと、実行される前に、ビュー定義が変更されても同じことです。次の例で、EXECUTE ステートメントで返される結果は、現在の日時ではなく、ランダムな数値になります。

CREATE VIEW v AS SELECT RAND();
PREPARE s FROM 'SELECT * FROM v';
ALTER VIEW v AS SELECT NOW();
EXECUTE s;

ビューの更新可能性に関しては、どのビューでも理論的に更新可能であれば、実際に更新可能である必要があるというのがビューの全体的な目的です。これには、定義に UNION が記されているビューも含まれています。現時点では、理論的に更新可能なすべてのビューが、実際に更新可能というわけではありません。最初のビュー実装は、使用可能で更新可能なビューをできるだけ迅速に MySQL に提供するため、故意にこのように書かれていました。現在、理論的に更新可能なビューの多くは更新できますが、制限はまだ存在します。

  • WHERE 句以外の場所にサブクエリーがある更新可能なビュー。SELECT リストにサブクエリーがあるビューの中には、更新可能な場合があります。

  • UPDATE を使用して、結合として定義されたビューの複数のベースとなるテーブルは更新できません。

  • DELETE を使用して、結合として定義されたビューは更新できません。

ビューの現在の実装には欠点があります。ビューの作成に必要な基本権限 (CREATE VIEW 権限と SELECT 権限) がユーザーに付与されていても、SHOW VIEW 権限も付与されていない場合、オブジェクトで SHOW CREATE VIEW を呼び出すことはできません。

権限の不足のために mysqldump が失敗する可能性があるという欠点によって、このコマンドを使用したデータベースのバックアップで問題が発生する場合があります。この問題については Bug #22062 で説明しています。

問題の回避策として、ビューが作成されたときに MySQL が暗黙的に SHOW VIEW 権限を与えないため、CREATE VIEW を認められているユーザーに、管理者が手動でこの権限を付与します。

ビューにはインデックスがないので、インデックスのヒントは適用されません。ビューからの選択時のインデックスヒントの使用は許可されていません。

SHOW CREATE VIEW は、カラムごとに AS alias_name 句を使用してビュー定義を表示します。式からカラムを作成する場合、デフォルトのエイリアスは式テキストになり、かなり長くなることがあります。CREATE VIEW ステートメント内のカラム名に対するエイリアスは、(256 文字の最大のエイリアス長ではなく) 64 文字の最大のカラム長に対してチェックされます。その結果、いずれかのカラムエイリアスが 64 文字を超えた場合、SHOW CREATE VIEW の出力から作成されたビューは失敗します。これによって、長すぎるエイリアスを持つビューに対し、次の環境で問題が起きる可能性があります。

  • ビュー定義は、カラム長の制約を強制する新しいスレーブに複製できません。

  • mysqldump で作成されたダンプファイルは、カラム長の制約を強制するサーバーにロードできません。

これらの問題を回避するには、短いカラム名を提供するエイリアスを使用するように、問題のある各ビュー定義を変更します。この場合、ビューは正しく複製され、エラーを生成しないでダンプおよびリロードできます。定義を変更するには、DROP VIEW および CREATE VIEW でビューを削除してから再度作成するか、CREATE OR REPLACE VIEW を使用して定義を置き換えます。

ダンプファイルのビュー定義リロード時に問題が発生する場合は、CREATE VIEW ステートメントを変更するようにダンプファイルを編集するとこの問題を回避できます。ただし、これは元のビュー定義を変更しないので、その後のダンプ操作の問題を引き起こす可能性があります。


User Comments
Sign Up Login You must be logged in to post a comment.