MySQLのパフォーマンスの危険性に注意してください

This article is relevant to MYSQL. Other flavours of SQL (eg SQL Server , PostgreSQL , SQLite) may be slightly different, SQL Server in particular has Indexed Views which can improve performance.

最近、私は私のデータベースと統合するいくつかのサードパーティのBIツールを試す機会がありました.私は注意の側でerr傾向があります、そして、私のテーブル構造をこれらのアプリケーションに暴露したくありません.
これらのBIツールのいくつかはまた、ユーザーがスキーマを知っている習慣として混乱することができるテーブルで独自の“クエリ”を作成することができます.
両方の問題に対するドキュメント全体の共通の解決策は、テーブルを簡素化するためのビューを作成することです.
これはあなたのデータベースの絶対的な災害パフォーマンスを賢くすることができます素晴らしいですが.

見解とは

最初のデータベースビューを正確に何ですか?
それはデータベースサーバーの格納されたクエリの結果セットです.
この例のクエリーを使用して、それらが入っているアクターとフィルムを返します.

select 
    first_name , last_name, title,description,release_year
from actor a
inner join film_actor fa on fa.actor_id = a.actor_id
inner join film f on f.film_id = fa.film_id;

このクエリから追加することでビューを作成できますCreate View 'View_name' as 以下のようなクエリの開始に.

CREATE VIEW `actor_films` AS
select 
    first_name , last_name, title,description,release_year
from actor a
inner join film_actor fa on fa.actor_id = a.actor_id
inner join film f on f.film_id = fa.film_id;

このように、テーブルのような問い合わせを行うことができます

select * from actor_films ;

かなりまっすぐ前方に見えるか.

処理アルゴリズムの種類

Create Viewステートメント-アルゴリズムの追加オプション句があります.これには3つの可能な値があります.Merge , Temptable and Undefined . この句は、MySQLがView Queryをどのように処理するかを定義します、そして、これはあなたのパフォーマンスがトールのハンマーによって打たれるかのように激しく打つことができるところです.

合併する
あなたは私たちの新しいビューを問い合わせる必要があると言うことができます-どのように正確にMySQLはこれを行うでしょうか?マージアルゴリズムを使用すると、ビューを作成するクエリを使用してクエリを単純にマージします.
例- WHERE条件を追加してビューを問い合わせる

select * 
from actor_films
where release_year > 2006 ;

これはビュークエリと組み合わせられます.

CREATE VIEW `actor_films` AS
select 
    first_name , last_name, title,description,release_year
from actor a
inner join film_actor fa on fa.actor_id = a.actor_id
inner join film f on f.film_id = fa.film_id
where release_year > 2006 

離れていることの1つのものは、あなたがmerge 以下のどれかをあなたのView Queryに持っているならば、アルゴリズム
1 .集約関数(sum ()、min ()、max ()、count ()など)
2別個
3グループby
4.有
制限
ユニオンまたはユニオン
7 .選択リストの副問い合わせ
ユーザ変数への代入
これらのいずれかを使用しようとすると、以下のようにMySQLを強制しますTemptable アルゴリズム.
それで、使用するときMerge アルゴリズムは、あなたのビューのパフォーマンスは、それを作成するクエリと同じくらい良いです.

誘惑できる
とTemptable オプションmysqlはビューのクエリを実行し、結果を一時テーブルに格納します.クエリをこのテーブルに対して実行します.
ビュークエリ内の結果セットを大幅に絞り込んだWHERE句を持っていない場合は、パフォーマンスのために絶対的に恐れることがあります.
顧客の注文と詳細を含む例ビューを考えます.日付の場合は、最近の2年間の注文のEGに結果を制限せずに、すべての時間のすべての注文を取得します.このビューをクエリするときに、いくつかの節を追加しようとすると、基本的にクエリを2回実行することになります.一時テーブルが作成され、再度クエリが使用されるときにもう一度.
大きなデータセットを使用する場合、これは災害になります.

未定義
これはCreateステートメントでアルゴリズムが設定されていない場合に設定されるデフォルトのオプションです.これは、MySQLを自動的にMerge and Temptable オプションを使用するMerge オプション.

何？より多くの危険？！

それで、ユーザーが新しい見解に一緒にいろいろな見解に加わるために始めるとき、何が起こりますか?彼らが使用するならばMerge しかし、彼らが使うならばTemptable その後、パフォーマンスの問題は、カスケードに開始するとパフォーマンスを再びヒットを開始します.
そして、それはより悪くなります.より悪い.より悪い.

ソリューション

ビューを正しく計画し、使用するクエリを避けるTemptable アルゴリズム.

CREATEViewステートメントではなく、ビューにクエリを適用する場合は、集約関数を使用します.

追加Where ビュー結果セットを減らす条件.

そして、あなたが寛大であるならば、あなたは以下のリンクで私にコーヒーを買うことができます☕ )