問題タブ [covering-index]

データベースでいくつかのクエリを実行していて、パフォーマンスを向上させたいと考えており、いくつかのインデックスを作成しましたが、それでも応答時間が長すぎると思うので、速度を上げるために、より良いインデックスまたは別のインデックスを作成できるかどうかを確認したいと考えています。

私が考えるテーブルのスキーマには、次のような最大のボトルネックがあると思います。

興味深いのは、日付 (例: 2010-05-20) を含むSDD属性で、私のクエリでは次のような範囲検索を行います: SDD >= '2010-05-03' and SDD < '2010-05-08'

私が持っている、実際にパフォーマンスを向上させるインデックスは、

問題は、2010-05-03 と 2010-06-04 のように距離の長い範囲検索を行うと、クエリの実行に約 6 ～ 10 秒かかることです。

SDD でいくつかのインデックスとクラスター インデックスを試してみましたが、これまでのところ、上記のインデックスが最良の結果でした。

アドバイスをいただければ幸いです。

心から

メスティカ

SQL Server 2005 には、複数の非キー列を選択して既存の非クラスター化インデックスに含めることができる「カバリング インデックス」機能が含まれています。

たとえば、次の列があります。

以下に 2 つのシナリオを示します。

• EmployeeIDはクラスター化インデックスを持つ主キーであり、残りの列 ( DepartmentID、DesignationID、 BranchID) は非クラスター化インデックス (複合インデックス) として取得されます。

• EmployeeIDはクラスター化インデックスを持つ主キーであり、DepartmentIDは非クラスター化インデックスの非クラスター化インデックスであり DesignationID、非クラスター化インデックスBranchIDの「含まれる列」です。

上記の2つの違いは何ですか？両方が同じである場合、「カバリング インデックス」の概念を導入するための新機能は何ですか?

SQL Server (またはその他の RDBMS) でのインデックス作成のベスト プラクティスについて質問があります。次の表を見てください。

ProfileIDテーブルに結合されProfileます。プロファイルごとに、それぞれTextが一意である必要があります。したがって、両方の列にプライマリ カバー キーを配置します。罰金。

ただし、上記のテーブルを でクエリできるようにしたいですProfileID。ということで、インデックスもつけましたProfileID。

これは、重複するインデックスがあることを意味します。カバー インデックスが既に存在するため、これが完全な無駄なのか、それともカバー インデックスが 2 つの列のハッシュになるため正しいのか (または、カバー インデックスを誤解しているのですか) はわかりません。

編集：

順番に索引を作成しました(ProfileID, Text)。仮に、3 つの列 A、B、および C があり、その 3 つすべてにカバー インデックスがあった場合はどうなるでしょうか。「A」または「A、B、および C」に対してクエリを実行した場合にのみメリットがありますが、 「B」、または「C」、または「B and C」?

SQL Server2008Expressを使用しています。問題のDBには、dboという1つのスキーマしかありません。

次のスクリプトを実行すると、次のようになります。

...正常に実行されますが、DBダイアグラムに移動してこのテーブルのインデックスを表示すると、インデックスが表示されません。さらに、非クラスター化インデックスを指定した場合でも、「含める」フィールドは常にグレー表示されます（したがって、スクリプトを使用します）。

何か案は？

(ExternalProductId、SourceId、AnotherField) にインデックスがあります。Explain は、索引が使用されていることを示しています。これは、説明の「追加」列に出力されます。

クエリを実行すると、SHOW PROCESSLIST で次のように表示されます。

このクエリを微調整して、インデックスで機能するようにすることはできますか? 他のプロセスがこのテーブルで同時に作業しているために、取得した結果が多少不正確であっても構いません。分離レベルを変更して、クエリのパフォーマンスを向上させることはできますか?

MySQLでテーブルのカバーインデックスを作成する標準的な順序はありますか？つまり、where句、order by、およびselectステートメントのフィールドを持つクエリがある場合、カバーするインデックスを適切に作成するために、インデックスへのフィールドはどのような順序で使用されますか？

SQL2008 を使用して、日付が特定のターゲット日付に最も近い行を見つけるための効率的なクエリを見つけようとしています。

私のテーブルには日付が最初の列であるカバリング インデックスが既にあるため、私が気にしなかった明らかな非効率的な解決策 (たとえば、ABS および DATEDIFFを使用したテーブル スキャン) があります。どの行が最も近いかを正確に把握する前に、そのインデックスを使用して結果を絞り込むことができます。

理論的には、1 回のインデックス ルックアップと、そのインデックスからの 2 行のデータの連続プルを使用して、クエリを満たすことができるはずです。

しかし、これまでのところ、これよりも最適なソリューションを見つけることができませんでした:

これは高速ですが (以下のテスト スキーマでは 4 回の論理読み取り、実際のテーブルでは 9 回の論理読み取り)、それでも 2 回のスキャン カウント ソリューションです。このインデックスに一度だけヒットするより効率的なソリューションはありますか?

または、2 番目のインデックス シークが最初のシークによってアクセスされるキャッシュされたページをプルするため、私の既存のソリューションは「十分」ですか?

スキーマといくつかのサンプル データを次に示します。どちらも実際のスキーマから単純化されていますが、結果のクエリ プランはより複雑なテーブルと同じになります。

次のような国のドキュメントがあります。

クエリを実行するときにのみインデックスにアクセスするには、次のようにします。

次のインデックスを追加しました。

私の理解では、クエリはインデックスのみにアクセスする必要があります。ただし、 .explain() は、クエリがインデックスをまったく使用していないことを示しています。

その理由は、完全なデータベース (247 か国) が出力されるためではないかと考えましたが、それは私には意味がありません。国がインデックス内で利用可能な場合、インデックスを使用する必要がありますよね?

誰にもアイデアがありますか？

乾杯

これは、インデックス最適化理論に関する長く複雑な質問です。これは宿題ではありませんが、Microsoftの70-432のサンプル試験でこの質問に最初にさらされました。元々の質問は一般的なクエリの最適化に関するものでしたが、その後、説明できないこの独特の動作を見つけました。

まず、テーブル：

ここで、クラスター化インデックスと、テスト用の2つのインデックス：

また、ランダムなテストデータをテーブルに追加しました（100000行）。Invoice_id、Customer_id、およびAmount_totalは、それぞれ独自のランダムな値（1000〜9999の範囲）を受け取り、Invoice_dateはGETDATE（）とランダムな秒数（1000〜9999の範囲）を受け取りました。私が使用した実際のルーチンを提供することはできますが、詳細が適切であるとは思いませんでした。

そして最後に、クエリ：

明らかに、クエリの最初のステップは非クラスター化インデックススキャンです。使用されるインデックスに関係なく、その最初のステップは同じ数のインデックス行を返します。「元の」インデックスを使用する場合、次のステップは、クラスター化インデックスを介してInvoice_dateを取得するためのルックアップと、それに続く2つのセット間の内部JOINです。「最適化された」インデックスを使用すると、そのフィールドはインデックスリーフに含まれるため、プランナーは直接結果を返します。

どのインデックスがより高速な実行をもたらしますか、そしてその理由は何ですか？

次のクエリでは

col3に 1 つ、 col4にもう1 つの2 つの個別のインデックスがある場合、このクエリではどちらが使用されますか?

クエリ内の各テーブルに対して 1 つのインデックスのみが使用されていることをどこかで読みました。クエリが両方のインデックスを使用する方法がないということですか?

第 2 に、 col3とcol4の両方を一緒に使用して複合インデックスを作成し、WHERE句でcol3のみを使用すると、パフォーマンスが低下しますか? 例：

Lastly, Is it better to just use Covering indexes in all cases ? and does it differ between MYISAM and innodb storage engines ?