問題タブ [composite-index]

レガシーデータベース（SQL Server 2000）には、次のようなクラスター化インデックスがあります。

私の知る限り、これらのフィールドはいずれもWHERE句で一緒に使用されていません。また、それらのいずれかを一緒に使用する理由も実際にはありません。このようなクラスター化されたインデックスを持つ理由はありますか？

次の 2 つのインデックスに違いはありますか?

• IDX_IndexTables_1
• IDX_IndexTables_2

ある場合、違いは何ですか？

1. データベースで複合インデックスを使用する必要があるのはいつですか？
2. 複合インデックスを使用することによるパフォーマンスへの影響は何ですか？
3. なぜ複合インデックスを使用する必要があるのですか？

たとえば、次のhomesテーブルがあります。

次のように、geolatとの両方に複合インデックスを使用することは意味がありますか？geolng

交換します：

と：

もしそうなら：

• なんで？
• 複合インデックスを使用することによるパフォーマンスへの影響は何ですか？

アップデート：

多くの人が私が実行するクエリに完全に依存していると述べているので、以下は実行される最も一般的なクエリです。

更新2：

次のデータベーススキーマを使用します。

次のSQLを使用します。

EXPLAINは以下を返します：

EXPLAINコマンドの読み方がよくわかりません。これは良く見えますか、それとも悪く見えますか。現在、geolatとgeolngの複合インデックスは使用していません。私はすべきですか？

sys.dm_db_index_usage_stats DMVは、SQLサーバーのインデックスに対するシークとスキャンの数に関する情報を提供します

複数の列を含む複合インデックスが多数あります。これらのインデックスは、多くのメンテナンスオーバーヘッドを引き起こしていると思われます。アンは列の数を絞りたいと考えています。

複合インデックスの個々の列に対するシークとスキャンを見つける方法はありますか？

この問題は、明らかに 2007 年にさかのぼる DataMapper のチケット #58で議論されていましたが、最新バージョン (dm-core-0.10.2) でそれを行う方法が見つかりません。それぞれが特定のプロパティに部分的に基づいている 2 つの複合インデックスを定義したいと考えています。私はこれができることを望んでいました...

それを行う正しい方法は何ですか？

主キー (従来の ID 列) として IDENTITY 列を持つテーブルがあります。

SQL Server は、その主キーのクラスター化インデックスを自動的に作成します。

私の質問は：

• より多くの列を持つ CLUSTERED INDEX コンポジットを 1 つだけ持つことはできますか?

はいの場合、デフォルトのクラスター化インデックスを削除して、この属性で新しいクラスター化インデックスを再作成するにはどうすればよいですか。

ご協力ありがとうございました

私はこのクラスを持っています

とコレクションIEnumerable<Item>

このコレクションのアイテムに、 Key1、Key2、または複合インデックス（Key1とKey4 ）でインデックスを作成したいと思います。収集品数は約1万点以上です。主な目標はパフォーマンスです。複数の発信者は、多くの読み取り/1回の書き込みアクセスを持つことができます。返されたコレクションは保護する必要があります（外部からの変更から保護します）。誰かがソリューション、パターン、実装に使用する必要のあるコレクションクラスについて説明してもらえますか。

いくつかの理由（パフォーマンスなど）のために、データベーステーブルのインデックスを使用するバリアントを拒否しました。

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

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

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

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

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

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

（a、b）に複合インデックスがある場合、「a」のみに関係するクエリは引き続き複合インデックスを使用することを理解しています（ただし、「b」に関係するクエリは使用しません）

私の質問は、(a, b) インデックスがある場合、「a」に単一列インデックスを持つ正当な理由があるかどうかです。私が読んだものは、(a,b) インデックスが a の完全な代替物なのか、単に「何もないよりはまし」なインデックスなのか、漠然としているように見えました。

これは、a と a,b の両方でフィルタリングを行うことを前提としています。書き込みパフォーマンスを低下させているインデックスが多すぎるテーブルがあり、インデックスを削除する前に再確認したいと考えています。

また、InnoDb と MyISAM のどちらを使用しているかによって、この回答は変わりますか? 関連するテーブルは MyISAM ですが、テーブルのほとんどは InnoDb です。

利点？なぜフィールドを個別にインデックス化しないのでしょうか? 誰でも私を簡単な言葉で説明できますか？