問題タブ [non-clustered-index]

私の SQL Server データベースでは、ビューとそれらのクラスター化および非クラスター化インデックスを作成しました。レコードの取得は高速になりましたが、テーブルから何か (名前など) を編集しようとすると、最大 20 秒かかりました。この時間の無駄を防ぐために何ができるでしょうか。何か案は。

クラスター化インデックスは、ディスク上のデータを物理的に並べ替えます。

テーブルemployeeとcolumd employee_idがあるとします。今9, 6, 10, 4、employee_id の下に値を保存します。employee_id にクラスター化インデックスを使用します。ディスク上の値は、4、6、9、10 などのように並べ替えられて格納されます。id が 9 の employee_id で検索すると、データベースはバイナリ検索などの検索アルゴリズムを使用して、id 9 のレコードをすばやく見つけることができます。バイナリ検索のように 1 回の操作でレコードを精査できない可能性があります。 あれは正しいですか？

非クラスター化インデックス 非クラスター 化インデックスには、実際のデータ行へのポインター (存在する場合はクラスター化インデックスへのポインター) と共に順序付けされたインデックス付き列からのデータの複製があります。したがって、上記と同じ例を考えてみましょう。この場合、データベースは別のオブジェクトを作成して、メモリの場所とともにデータを保存します。このようなもの

9 -- 物理的な場所

6 -- その物理的な場所

10 -- その物理的な場所

4 -- その物理的な場所

したがって、最初に新しく作成されたオブジェクトで 10 を検索し、そのメモリの場所を取得する必要があります。その後、元のメモリ位置に戻ります。 では、なぜ検索が高速になるのでしょうか?

また、私の理解によれば、select句の下ではなくwhere句の下にある列にインデックスを作成する必要があります。右？

ヒープ テーブルがあります - クラスター化インデックスが定義されていません ( と呼びますtable A)。null 非許容列に一意の非クラスター化インデックスがあります ( と を呼び出しますcolumn ID) index IX。

for でindex IX主キー制約を定義するときに使用したいと思います。column IDtable A

どこかのドキュメントには次のように書かれています：

データベース エンジンDatabase Engine は、一意のインデックスを自動的に作成して、PRIMARY KEY 制約の一意性の要件を適用します。テーブルにクラスター化インデックスがまだ存在しない場合、または非クラスター化インデックスが明示的に指定されていない場合は、PRIMARY KEY 制約を適用するために一意のクラスター化インデックスが作成されます。

ドキュメント全体を読みましたALTER TABLEが、「非クラスター化インデックスが...明示的に指定されている」という構文がないようです。

非クラスター化を定義してindex IX主キーを指定しようとしましたが、alter table ... add constraint ... primary key ステートメントのさまざまな組み合わせも試しましたが、役に立ちませんでした。

私のインデックス IX は、alter table .... add constraint .... 主キー (ID) ステートメントで ID 列を指定するだけで、SQL Server が作成する非クラスター化インデックスと同等であることは理にかなっていますが、私はそうしないことを好みます。 SQL Serverが私のために作成するこの冗長インデックスを持ち、むしろindex IX列のインクルードリストで構成される を使用します。

SQL Server が作成するインデックスを削除すると、主キー制約もなくなります。

SQL Server が作成するインデックスを変更できれば問題は解決しますが、それを変更するには削除して再作成する必要があります。

シナリオの簡単な概要:

私のデータベースは GUID を主キーとして使用しており、私が読んでいる限り、GUID にクラスター化されたインデックスを使用するのはやや悪いようです (断片化が増加し、挿入が遅くなるなど)。私のプロジェクトは休止状態を使用しているため、通常は jpql と完全なエンティティのフェッチを処理します (多くのクエリが最終的に に変わりますselect p.* from person p [...])

テーブルのすべての列をカバーする非クラスター化インデックスを作成するのが良い方法であるかどうかを知りたいです (RID ルックアップなどを避けるため)。

助けてくれてありがとう、すでに！

2 つの列でインデックスを作成することと、2 つの列で別のインデックスを作成することの違いは何ですか?

との差

と

私たちは、鳥の記録の大規模な（そして成長している）MySQL データベースを持っています。現在、次のように簡略化された 3 つのメイン テーブルがあります。

すべての ID は INT で、日付は DATE 型です。

パフォーマンスを向上させるために、日付と locid を RECORDS に複製することで非正規化を行うことにしました。

このようにして、多くのクエリで BIRDTRIPS と LOCATIONS への高価な結合を回避できます。

MySQL にはテーブルごとにクラスター化されたインデックスが 1 つだけあり、これが常に主キーになります。RECORDS
を試しPRIMARY KEY (date, id)て、クラスター化されたインデックスを活用して、日付列の範囲スキャンとテーブルのパーティション分割を高速化しようとしています。同じ日付に多くのレコードが存在する可能性があるため、ID はキーにのみ含まれています。理論的には、主キーは多くの場合、ID で「無駄」になることが多く、ルックアップにはクラスター化されていない UNIQUE インデックスで十分です。

そして今、私の質問：

このアプローチで実際の経験をお持ちの方はいらっしゃいますか? 私が見落としているかもしれない欠点はありますか？

私はまだSQLに精通していません。私は学んでいますが、それは遅いプロセスです。私は、SQL Server のデータベースに大量の情報を格納するプロジェクトに取り組んでいます。テーブルの 1 つである ContactInformation では、すべてのアドレス情報で構成される非クラスター化インデックスが 900 バイトを超えるため、エントリを変更しようとするとエラーが発生します。sys.dm_db_index_usage_statsテーブル内のエントリを変更すると 3user_seeksと 1になることを確認してきましたuser_update。

C# コードはインデックスを直接呼び出していないようです。19 個のパラメーターを持つさまざまなDbCommandストアド プロシージャ コマンドで構成される単一のコマンドを実行します。私の考えでは、インデックスを削除するか、操作するインデックスを小さくすることを期待して、パラメーターの数を減らして複数の更新に分割Updateしようとします。DbCommand

私は経験が不足しているため、少し海にいます。次の方向へのアドバイスを歓迎します。

インデックスは次のもので構成されています。

はい、ほとんどの列が特大です。このデータベースは別のプロジェクトから継承したようです。当社のソフトウェアでは、一部の外れ値はありますが、ほとんどの列が 100 文字以内に制限されています。

私の質問は、たとえば、次の列があります

ここで、非クラスター化インデックスを作成していると仮定しCl2ますが、クエリCl2を実行すると、常に取得Cl3しCl4ます。

Cl3検索操作を高速化するため、インデックスに含めることは論理的ですが、非常に大きくなる可能性があります。この列には、クロールされたページ ソースが保持されますCl4。nvarchar(max)

Cl4したがって、私の質問は次のとおりです。非クラスター化インデックスに含めるかどうかは論理的です

それを含めるとCl4、ハードドライブに正確に2回保存されますか?

回答ありがとうございました

SQL Server 2014

ヒープ テーブルを作成して、RID (以前のブックマーク) ルックアップを調べてみました。

次に、実行計画を調査するために次のクエリを試しました。

しかし、MSSMS を使用すると、実行計画に RID ルックアップが表示されません。

SQL Server 2008R2 (バージョン 10.50.4000.0) サービス パック 2 を使用しています。

PS: この質問は、Aaron Bertrand の記事に基づいています。