MySQL ビューはインデックスの拡張機能を利用してパフォーマンスを向上できますか?

MySQL ビューの使用は有害な慣行ですか?

反対を示唆するアドバイスにもかかわらず、ビューは MySQL 内で使用される場合、確かにインデックス拡張を活用できます。 。このような機能をどのように実装できるかという疑問が生じます。

答え: 適切なインデックスを提供する

解決策は、MySQL が積極的に利用できるインデックスを提供することにあります。この場合、次のような「カバーする」インデックスが最も適切です。

CREATE INDEX highscores_IX3 ON highscores (player, happened_in, score)

このインデックスを適切に配置すると、MySQL のオプティマイザはそれを SELECT クエリに使用できるようになり、結果として「インデックスを使用中」という結果が得られます。 " 宣言は WHERE player = 24 述語に起因します。

ただし、MySQL は内部の「ビュー クエリ」実行を外部から分離する動作のため、ビュー クエリに happens_in インデックスを利用する可能性は低いことを認識することが重要です。クエリ。したがって、happen_in に定義されたインデックスは、クエリ形成フェーズでは使用されません。

カバレッジ インデックスによるパフォーマンスの最適化

ビュー クエリのパフォーマンスを最適化するには、「カバリング インデックス」クエリで参照されるすべての列 (例: ON highscores (player、happen_in、score)) を含む「index」が推奨されます。このタイプのインデックスを使用すると、基になるテーブルでのページ検索を必要とせずに、インデックス ページから直接データを取得できるため、「インデックスを使用する」アクセス方法になります。

派生テーブルのないスタンドアロン クエリとの比較

比較のために、ビュー クエリと同等のスタンドアロン クエリを考えてみましょう:

SELECT player, MAX(score) AS highest_score, happened_in
FROM highscores
WHERE player = 24 AND happened_in = 2006
GROUP BY player, happened_in

このクエリのカバー インデックス (例: ON ハイスコア (プレーヤー、ハプニング_イン、スコア))また、中間の「派生」テーブルの必要性を排除して利用することもできます。

注意と考慮事項

ビューは本質的に有害ではありませんが、その仕組みを理解することが重要です。 MySQL はビュー クエリを処理しますが、これは他のデータベースで採用されているアプローチとは異なります。この知識により、開発者はパフォーマンスの落とし穴を軽減しながら、ビューの可能性を効果的に活用できるようになります。

以上がMySQL ビューはインデックスの拡張機能を利用してパフォーマンスを向上できますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。