問題タブ [covering-index]

私はこのテーブルを持っています：

このテーブルに 10 000 000 行を入力します。日付による再分割は均一です

これが結果です

=> 説明なしで 3.6 秒 (約) 3000 行の結果

ご覧のとおり、インデックスは使用されておらず、possible_keys 列の一部ではありません!

カバリング インデックス ウェイを使用した同じリクエスト

結果：

=> 説明なしで 3000 行の結果に対して 2.8 秒 (約)

MySQL がこのインデックス (DATE) を適切に使用しないのはなぜですか ???

情報: - VM サーバー (私たちの開発環境、ハードウェア構成はわかりません) - MySQL 5.5.8

結果：

• 日付 2014-03-04 => 3134 行
• 合計 (ロールアップ) => 7 875 488
• テーブルには 2556 個の異なる「日付」値があります

私はこれまでインデックスをカバーすることを聞いたことがなく、ただそれらに出くわしました。私は彼らについてこのページを読んでいました、そしてそれは言います。

「カバーするインデックスはデータの取得を劇的にスピードアップできますが、キーが追加されるためデータの挿入と更新が遅くなるため、それ自体が大きくなる可能性があります。このようなインデックスサイズを減らすために、一部のシステムではキー以外のフィールドをインデックスに含めることができます。 -キーフィールド自体はインデックスの順序付けの一部ではなく、リーフレベルでのみ含まれるため、全体的なインデックスサイズを小さくしてカバーするインデックスを作成できます。」

だから私の質問は、あなたのシステムが非キーフィールドをインデックスに含めることを許可しているかどうかをどうやって知るのですか？

EF Code First Migrations の CreateIndex 構文を使用してカバリング インデックスを作成することは可能ですか (*カバリング インデックスとは何かについては以下を参照してください)。

たとえば、次のように手動移行で単純なインデックスを作成できます。

基になるプロバイダーがサポートするものは何でも処理できることを指定する「匿名引数」という名前の最後の引数がありますが、そのサポートが何であるかをどのように判断するかは明確ではありません。これは可能ですか、それともフラット SQL に頼る必要がありますか?

*カバリング インデックスとは、RDB がメイン テーブルへのポインタだけでなく、重複データをリーフ ノードに格納するインデックスです。これは基本的に、そのタイプの検索で最もよく使用される列のみを含む、インデックス内の列によって並べ替えられたテーブルの複製です。

複数のテーブルで結合を実行するクエリがあります。テーブルの外部キーに非クラスター化インデックスがあり、主キーにクラスター化インデックスがあります。クエリ プランを分析したところ、クエリ オプティマイザーがすべてのテーブルでクラスター化インデックス スキャンを選択しているか、非クラスター化インデックス スキャンとキー ルックアップを組み合わせて他の非キー列をフェッチしていることがわかりました。これを修正するために、このクエリで必要な非キー列を非クラスター化インデックスに含めました (カバーしました)。この結果、非クラスター化インデックスのシーク/スキャンが期待どおりに実行されていることがわかりました。

私の質問は、他の多くの非キー列を結果セットの一部にする必要がある他のクエリがある場合、すべての列を非クラスター化インデックスに追加 (INCLUDING) して、すべてのクエリのパフォーマンスを向上させる可能性があることです。 . これは良い考えでしょうか？

ありがとう。

MySQL クエリがカバリング インデックスを使用しており、必要なすべてのデータをそのインデックスだけから取得しているかどうかを確認するにはどうすればよいでしょうか?