このページは機械翻訳したものです。

8.2.1 SELECT ステートメントの最適化

8.2.1.1 WHERE 句の最適化

8.2.1.2 range の最適化

8.2.1.3 インデックスマージの最適化

8.2.1.4 ハッシュ結合の最適化

8.2.1.5 エンジンコンディションプッシュダウンの最適化

8.2.1.6 インデックスコンディションプッシュダウンの最適化

8.2.1.7 Nested Loop 結合アルゴリズム

8.2.1.8 ネストした結合の最適化

8.2.1.9 外部結合の最適化

8.2.1.10 外部結合の単純化

8.2.1.11 Multi-Range Read の最適化

8.2.1.12 Block Nested Loop 結合と Batched Key Access 結合

8.2.1.13 条件フィルタ

8.2.1.14 定数 - フォールディングの最適化

8.2.1.15 IS NULL の最適化

8.2.1.16 ORDER BY の最適化

8.2.1.17 GROUP BY の最適化

8.2.1.18 DISTINCT の最適化

8.2.1.19 LIMIT クエリーの最適化

8.2.1.20 関数コールの最適化

8.2.1.21 ウィンドウ機能最適化

8.2.1.22 行コンストラクタ式の最適化

8.2.1.23 全テーブルスキャンの回避

SELECT ステートメントの形式のクエリーは、データベースのすべてのルックアップ操作を実行します。 動的 Web ページの 1 秒未満の応答時間を達成するためでも、または巨大な夜間のレポートを生成するための時間から数時間を取り除くためでも、これらのステートメントのチューニングは最優先です。

SELECT ステートメントに加えて、クエリーのチューニング手法は DELETE ステートメントの CREATE TABLE...AS SELECT、INSERT INTO...SELECT、WHERE 句などの構成要素にも適用されます。 これらのステートメントは、書込み操作と読取り指向クエリー操作を組み合せるため、パフォーマンスに関する追加の考慮事項があります。

NDB Cluster は結合プッシュダウン最適化をサポートしており、そこで適格な結合が NDB Cluster データノードに完全に送信され、そこでそれらのノード間で分散して並列で実行できます。 この最適化の詳細は、NDB プッシュダウン結合の条件 を参照してください。

クエリーの最適化の主な考慮事項は次のとおりです。

• 遅い SELECT ... WHERE クエリーを高速化するため、最初に確認することは、インデックスを追加できるかどうかです。 WHERE 句で使用するカラムにインデックスをセットアップし、評価、フィルタリング、および最終的な結果の取得を高速化します。 無駄なディスク領域を避けるため、アプリケーションで使用される多くの関連クエリーを高速化する少数のインデックスのセットを構築します。

  インデックスは、結合や外部キーなどの機能を使用して、さまざまなテーブルを参照するクエリーに特に重要です。 EXPLAIN ステートメントを使用して、SELECT に使用するインデックスを判断できます。 セクション8.3.1「MySQL のインデックスの使用の仕組み」およびセクション8.8.1「EXPLAIN によるクエリーの最適化」を参照してください。

• 過度な時間がかかる関数呼び出しなどのクエリーの部分を特定し、チューニングします。 クエリーの構築の仕方によっては、関数が結果セットのすべての行に対して 1 回ずつ、さらにはテーブル内のすべての行に対して 1 回ずつ呼び出されるなど、大幅に非効率性を拡大させていることがあります。

• 特に大きなテーブルの場合に、クエリーでの完全テーブルスキャンの回数を最小にします。

• ANALYZE TABLE ステートメントを定期的に使用して、テーブル統計を最新に維持し、オプティマイザが、効率的な実行プランを立てるために必要な情報が得られるようにします。

• チューニング技法、インデックス作成技法、および各テーブルのストレージエンジンに固有の構成パラメータについて学習します。 InnoDB と MyISAM のどちらでも、クエリーの高いパフォーマンスを可能にし、維持するための一連のガイドラインがあります。 詳細については、セクション8.5.6「InnoDB クエリーの最適化」およびセクション8.6.1「MyISAM クエリーの最適化」を参照してください。

• セクション8.5.3「InnoDB の読み取り専用トランザクションの最適化」 の手法を使用して、InnoDB テーブルの単一クエリートランザクションを最適化できます。

• 特にオプティマイザで同じ変換の一部を自動的に実行する場合、理解が困難になるようなクエリーの変換を避けます。

• いずれかの基本ガイドラインによって、パフォーマンスの問題が簡単に解決されない場合、EXPLAIN プランを読み、インデックス、WHERE 句、結合句などを調整して、特定のクエリーの内部の詳細を調査します。 (ある程度の専門技術に達している場合は、EXPLAIN プランを読むことがすべてのクエリーの最初の手順になると考えられます。)

• MySQL がキャッシュに使用するメモリー領域のサイズとプロパティーを調整します。 InnoDB バッファープール、MyISAM キーキャッシュ、および MySQL クエリーキャッシュの効率的な使用によって、2 回目以降、メモリーから結果が取得されるため、繰り返しのクエリーの実行が高速化します。

• キャッシュメモリー領域を使用して高速に実行するクエリーでも、必要なキャッシュメモリーを減らして、アプリケーションがよりスケーラブルになるように、さらに最適化できます。 スケーラビリティーは、パフォーマンスを大幅に低下させずに、アプリケーションでより多くの同時ユーザー、大きなリクエストなどを処理できることを意味します。

• クエリーの速度が、テーブルに同時にアクセスしているほかのセッションによって影響を受ける可能性があるロックの問題を処理します。