MySQLビューは常に全表スキャンを実行しますか？
https://stackoverflow.com/questions/637328
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
MySQL 5.1のビューを使用するクエリを最適化しようとしています。ビューから1列を選択しても、常に全表スキャンが実行されるようです。それは予想される動作ですか？
ビューは、SELECT＆quot; All Columns From These Tables-NOT *＆quot;以下の最初のクエリで指定したテーブルの場合。
これは、ビューを構成するクエリからインデックス付きの列PromotionIDを選択したときのExplain出力です。ご覧のとおり、ビューの出力とは大きく異なります。
EXPLAIN SELECT pb.PromotionID FROM PromotionBase pb INNER JOIN PromotionCart pct ON pb.PromotionID = pct.PromotionID INNER JOIN PromotionCode pc ON pb.PromotionID = pc.PromotionID WHERE pc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: pc
type: const
possible_keys: PRIMARY,fk_pc_pb
key: PRIMARY
key_len: 302
ref: const
rows: 1
Extra:
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: pb
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra: Using index
*************************** 3. row ***************************
id: 1
select_type: SIMPLE
table: pct
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: const
rows: 1
Extra: Using index
3 rows in set (0.00 sec)
ビューから同じものを選択したときの出力
EXPLAIN SELECT vpc.PromotionID FROM vw_PromotionCode vpc WHERE vpc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: <derived2>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 5830
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DERIVED
table: pcart
type: index
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 33
Extra: Using index
*************************** 3. row ***************************
id: 2
select_type: DERIVED
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pcart.PromotionID
rows: 1
Extra:
*************************** 4. row ***************************
id: 2
select_type: DERIVED
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 5. row ***************************
id: 3
select_type: UNION
table: pp
type: index
possible_keys: PRIMARY
key: pp_p
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 6. row ***************************
id: 3
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pp.PromotionID
rows: 1
Extra:
*************************** 7. row ***************************
id: 3
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 8. row ***************************
id: 4
select_type: UNION
table: pcp
type: index
possible_keys: PRIMARY
key: pcp_cp
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 9. row ***************************
id: 4
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.pcp.PromotionID
rows: 1
Extra:
*************************** 10. row ***************************
id: 4
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 11. row ***************************
id: 5
select_type: UNION
table: ppc
type: index
possible_keys: PRIMARY
key: ppc_pc
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 12. row ***************************
id: 5
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.ppc.PromotionID
rows: 1
Extra:
*************************** 13. row ***************************
id: 5
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 14. row ***************************
id: 6
select_type: UNION
table: ppt
type: index
possible_keys: PRIMARY
key: ppt_pt
key_len: 4
ref: NULL
rows: 1
Extra: Using index
*************************** 15. row ***************************
id: 6
select_type: UNION
table: pb
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: readyinteractive.ppt.PromotionID
rows: 1
Extra:
*************************** 16. row ***************************
id: 6
select_type: UNION
table: pc
type: ref
possible_keys: fk_pc_pb
key: fk_pc_pb
key_len: 4
ref: readyinteractive.pb.PromotionID
rows: 249
Extra: Using where
*************************** 17. row ***************************
id: NULL
select_type: UNION RESULT
table: <union2,3,4,5,6>
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: NULL
Extra:
17 rows in set (0.18 sec)
解決
MySQLのビューはインデックス化されていないため、その性質上、アクセスするたびにフルスキャンが必要です。一般的に、これはビューが本当に便利なのは、小さな結果セットを返すかなり複雑な静的クエリがあり、毎回結果セット全体を取得する計画がある場合のみです。
編集：もちろん、ビューは基礎となるテーブルのインデックスを使用して、ビュー自体が最適化されるようにします（そうでなければ、使用してもまったく意味がありません）が、インデックスがないためビューでは、ビューのWHEREクエリを最適化することはできません。
ビューのインデックスの構築は、ビューのプロファイリングを試みたことがありませんが、一時テーブルがバックグラウンドで構築され、結果セットが返されることを確信しているため、とにかく高価になります。一時テーブルの構築にはすでにかなりの時間がかかります。どのインデックスが必要かを推測しようとするビューは必要ありません。 2番目のポイントは、MySQLが現在ビューに使用するインデックスを指定する方法を提供していないため、どのフィールドにインデックスを付ける必要があるかをどのように知るかということです。クエリに基づいて推測しますか？
一時テーブルの使用を検討することができます。その後、一時テーブルのフィールドにインデックスを指定できます。ただし、経験から、これは非常に遅くなる傾向があります。
このビューに含まれるすべてがSELECT ALL FROM table1、table2、table3の場合、次に、このクエリをビューに含める必要がある理由を尋ねる必要がありますか？何らかの理由で絶対に必要な場合は、ストアドプロシージャを使用してクエリをカプセル化し、結果セットのデータベースへの単純な呼び出しの利点を維持しながら、最適化されたパフォーマンスを得ることができます。
他のヒント
詳細を見て、重要な情報を見逃してしまった:(私のビュークエリは、実際には別のテーブルとの結合を持っています。これにより、ビューはMERGEアルゴリズムの代わりにTEMPORARY TABLEアルゴリズムを使用しています。
TEMPORARY TABLEアルゴリズムでは、基礎となるテーブルでインデックスを使用できません。
これはMySQLのバグのようで、2006年に報告されましたが、2009年に解決されたようには見えません！ http://forums.mysql.com/read.php?100,56681、 56681
クエリを外部結合として書き直す必要があるようです。
