問題タブ [clustered-index]

プライマリ、一意、クラスター化インデックスなどについて読みましたが、例を使用して理解する必要があります。

以下の画像は、SQLServerWeb管理パネルからキャプチャされた自動生成されたaspnet_Usersテーブルです。

自動生成されたASP.NETユーザーテーブルhttp://eggshelf.com/capture.jpg

これをモデルとして取り上げます。Companiesというカスタムテーブルを作成し、フィールドがID、Name、ShortName、Address、City、Countryであるとします。ID、Name、ShortNameの各フィールドに値を複製することはできません。

このテーブルのインデックスを作成するためのアプローチは何ですか？クラスター化するか、クラスター化しないか。以下のインデックスはあなたにとって論理的ですか？

よろしく。

時系列が多い環境データにはH2データベースを使用しています。時系列は、データベースに定期的に（たとえば、1時間に1回）記録されるセンサーの単なる測定値です。

テーブルに保存されているデータ：

テーブルに対して範囲クエリを実行したいと思います。次に例を示します。

パフォーマンスを向上させるために、dt列上にクラスター化インデックスを作成したいのですが、H2がクラスター化インデックスをサポートしているかどうかがわかりません。クラスタ化インデックスがH2でサポートされて いるかどうか誰かが知っていますか？

私は次の鍵を持っています：

だから私はID列にクラスター化インデックスと主キーを持っています。次に、クラスター化インデックスを削除する必要があります（別の列に新しいクラスター化インデックスを作成したい）が、主キーは保持します。出来ますか？

一意ではない非クラスター化インデックスであるフィールドに where 句があるいくつかの SQL クエリから少し余分なパフォーマンスを引き出しようとしています。これはテーブル A の外部キーでもあります。その外部キーは主キーです。テーブル B にあり、クラスター化インデックスです。

私が疑問に思っているのは、テーブル A からテーブル B への結合を追加し、クラスター化インデックスであるフィールドに where 句がある場合 (追加の結合のない非クラスター化インデックスとは対照的に)、パフォーマンスが向上するかどうかです。 )?

ありがとう

INFORMIX-SE:

私のユーザーは定期的に SQL スクリプト [REORG.SQL] を実行します。このスクリプトは、テーブルからすべての行をソートされた順序で 2 つの別々のファイル (アクティブと非アクティブ) にアンロードし、テーブルを削除し、テーブルを再作成し、ソートされたロードファイルをそこにロードします。アンロードファイルをソートしたのと同じ列にクラスターインデックスを作成し、他のサポートインデックスを作成し、その統計を更新します。

( SE: 'bcheck -y' anomaly のREORG.SQL スクリプトを参照してください )

( クラスターインデックスが pk_id[serial]=fk_id[int] ではなく名前による理由については、customer.pk_name Join transactions.fk_name 対 customer.pk_id [serial] Join transactions.fk_id [integer]も参照してください)

私の REORG.SQL スクリプトでは、インデックス ファイルの一貫性の問題が発生していたので、CLUSTER INDEX が関係しているのではないかと疑い、クラスタリングなしでインデックスを作成したところ、問題は解消されました。

ここで私の質問は次のとおりです。顧客のフルネームでソートされたすべてのトランザクションデータを新しく作成されたテーブルにロードできた場合、実際には行がすでに同じ順序でソートされている場合に CLUSTER INDEX を作成する必要がありますか?クラスタリングが達成することは?..新しい行が追加されると、クラスタ化インデックスがクラスタリングを失い始めることを知っています.それで、クラスタインデックスを作成する利点は何ですか?..クエリオプティマイザはクラスタリングと非クラスタリングを利用しますか.行が本質的に同じクラスター化された順序である場合のインデックス?..テーブルをクラスター化するときに IDX/DAT ファイルの問題に遭遇した人はいますか?..おそらく私の SQL スクリプトに何か問題がありますか? (SQL スクリプト コードを確認して、何か間違っているかどうかを確認してください。)

レポートを作成するには、データベースを操作する必要があります。DB は非常に大きいです: 416 055 104 行 各行は非常に軽量ですが、ブール値と int id だけです。

各行は 3 つの列で識別されますが、驚いたことに、主キーはありません。一意の制約を持つクラスター化インデックスのみ。

それを知って、私は2つの質問があります。

1. それには何か正当な理由がありますか？
2. これを主キーに変える方法はありますか。

質問2について

新しい主キーを作成すると、関連付ける非クラスター化インデックスも作成されます (既存のクラスター化インデックスが既に存在します)。
これは私が探しているものではありません。同じインデックスを保持したいだけでなく、主キーにもします。

• 出来ますか？
• インデックス全体を再度作成するよりも高速でしょうか? （そうだといい）
• どのような結果になる可能性がありますか? (ロック? クラッシュ? 破損したデータ?)

Sql Server は、複合主キーにクラスター化インデックスを持つテーブルの FILL FACTOR をどのように処理しますか?

キー ノードの値は、クラスター化インデックスを構成するフィールドに基づいて生成されると思います。これは、挿入された新しい各行が効果的にインデックスの最後に挿入されることを意味しますか?

3 台以上のサーバーの SQL Server クラスタリングを実行できますか? マスターは複数のスレーブを持つことができますか? 制限は何ですか？

SQL Serverデータベース（2005および2008）であるレガシーデータベースがあります。

テーブル内のすべての主キーはUniqueIdentifiersです。

現在、テーブルにはクラスター化インデックスが作成されておらず、75万レコードしかないテーブルでパフォーマンスの問題が発生しています。これは私が唯一の主キーとして一意の識別子を使用して作業した最初のデータベースであり、SQLサーバーがデータを返すのにこれほど遅いのを見たことがありません。

一意の識別子にクラスター化されたインデックスを作成したくないのは、それらがシーケンシャルではないため、データの挿入に関してアプリの速度が低下するためです。

リモートサイトレコードのID管理の目的で使用されているため、uniqueidentifierを削除することはできません。

テーブルに大きな整数のID列を追加し、この列にクラスター化インデックスを作成し、一意のID列を含めることを考えていました。

すなわち

intidentity-挿入速度を維持する最初の列一意の識別子-アプリケーションが期待どおりに動作し続けることを保証します。

目標は、IDクエリと結合テーブルクエリのパフォーマンスを向上させることです。

Q1：これにより、データベースのクエリパフォーマンスが向上しますか、それとも遅くなりますか？

Q2：私がリストしていないこれに代わるものはありますか？

ありがとうピート

編集： パフォーマンスの問題は、特に「トランザクション/変更」テーブルのいくつかが一緒に結合されている場合、selectステートメントを介してデータをすばやく取得することです。

編集2：テーブル間の結合は、通常、すべて主キーと外部キーの間です。外部キーを持つテーブルの場合、よりカバーするインデックスを提供するために、非クラスター化インデックスに含まれます。

すべてのテーブルには、適切なクラスター化インデックスを提供する他の値はありません。

高負荷の各テーブルにID列を追加し、クラスター化インデックス内に現在のGuid PK列を含めて、最高のクエリパフォーマンスを提供することに傾倒しています。

編集3：クエリの80％は、データアクセスメカニズムを介して主キーと外部キーのみで実行されると推定します。通常、データモデルには、アクセス時にクエリを実行する遅延読み込みオブジェクトがあります。これらのクエリは、オブジェクトIDとPK列を使用します。タイプXの基準に基づくフィルターとして外部キー列を使用する、ユーザー主導のデータ除外/包含クエリが大量にあり、次のIDを除外します。残りの20％は、列挙型（int）列または日付範囲列のwhere句であり、システムで実行されるテキストベースのクエリはごくわずかです。

可能であれば、最も重いクエリをカバーするためにカバーインデックスをすでに追加しましたが、それでもパフォーマンスには失望しています。bluefootedが言うように、データはヒープとして保存されています。

SQL Server 2005でクラスター化インデックスを非クラスター化インデックスに、または非クラスター化インデックスをクラスター化インデックスに変換することは可能ですか.

このクエリをクラスター化インデックスに変換してください:

このクエリを非クラスター化インデックスに変換してください: