問題タブ [clustered-index]

シーケンシャルGUIDを使用する目的は、通常のGUIDの場合にクラスター化インデックスに通常存在する高レベルの断片化なしに、クラスター化インデックスを使用できるようにすることです。

次のように luTab から myTab を更新する必要があるとします。

luTab は 2 つの列 (idLookup(unique)、LookupValue) で構成されます。

idLookup の一意のクラスター化インデックス、または idLookup と Lookupvalue の組み合わせのどちらが望ましいですか? この状況でカバリングインデックスは何か違いを生むでしょうか?

（私は主にSQLサーバーに興味があります）

エピローグ :

以下の Krips テストを、myTab で 2700 万行、luTab で 150 万行でフォローアップしました。重要な部分は、インデックスの一意性にあるようです。インデックスが一意として指定されている場合、更新ではハッシュ テーブルが使用されます。一意として指定されていない場合、更新は最初に idLookup (ストリーム アグリゲート) によって luTab を集約し、次にネストされたループを使用します。これははるかに遅いです。拡張インデックスを使用すると、その LookupValue が一意であると SQL が保証されなくなり、はるかに低速なストリーム集約ネスト ループ ルートが強制されます。

クエリからパフォーマンスの最後の一滴まで絞り込もうとしている場合、これらのタイプのインデックスが結合で使用されると、どのような影響がありますか。

• クラスタ化インデックス。
• 非クラスター化インデックス。
• 結合に関与しない可能性のある余分な列を持つクラスター化または非クラスター化インデックス。

結合に関係する列のみを含み、他には何も含まないクラスター化インデックスを作成した場合、パフォーマンスは向上しますか?

（クラスター化されたインデックスは1つしか持てないため、別のインデックスから移動する（そのインデックスを非クラスター化する）必要があるかもしれません。）

このコードは私のマシンでは約0.9秒かかり、392Kを占めるdbファイルを作成します。2行目を次のように変更すると、これらの数値は1.4秒と864Kになります。

なぜそうなのですか？

私は数百のテーブルを含む非常に大規模なデータベースを持っており、多くの製品をアップグレードした後、それらの半分はもう使用されていないと確信しています。テーブルがアクティブに選択されているかどうかを確認するにはどうすればよいですか？プロファイラーを使用することはできません。数日以上監視したいだけでなく、何千ものストアドプロシージャもあり、プロファイラーはSP呼び出しをテーブルアクセス呼び出しに変換しません。

私が考えることができる唯一のことは、対象のテーブルにクラスター化されたインデックスを作成し、クラスター化されたインデックスにsys.dm_db_index_usage_statsシークまたはスキャンがあるかどうかを監視することです。これは、テーブルからのデータがロードされたことを意味します。ただし、実際には実行可能ではないため、すべてのテーブルにクラスター化インデックスを追加することは（さまざまな理由で）悪い考えです。

他に選択肢はありますか？私は常に「SELECTトリガー」のような機能が必要でしたが、SQLServerにその機能がない理由はおそらく他にもあります。

解決：

レムス、私を正しい方向に向けてくれてありがとう。これらの列を使用して、次のSELECTを作成しました。これは、まさに私が望むことを実行します。

テーブルにクラスター化インデックスを作成した後、そのテーブルの統計を更新する意味はありますか?

乾杯。

クラスター化インデックスはどのようにハード ディスクに格納されますか? 論理的な順序は何ですか？

非クラスター化インデックスはどのように機能しますか?

通常、クラスター化インデックスは SQL Server Management Studio で主キーを設定することによって作成されますが、PK <-> クラスター化インデックス ( Microsoft SQL Server 2008 の主キーの意味)に関する私の最近の質問では、PK を設定する必要がないことが示されています。クラスター化インデックスが等しくなるようにします。

では、クラスター化インデックスをどのように選択すればよいでしょうか。次の例を見てみましょう。

通常は両方の ID 列に PK/CI を作成しますが、CustomerID の注文用に作成することを考えました。それが最良の選択ですか？

GUID 列にクラスター化された主キーの作成を間違えました。定義された外部キーでそのテーブルを参照する多くのテーブルがあります。テーブルのサイズは重要ではありません。

外部キーや主キーの制約を手動で削除して再作成せずに、クラスター化されたものから非クラスター化されたものに変換したいと思います。

MS SQL2005 でそれを達成することは可能ですか?

はいの場合、そのオンライン（データベースのダウンタイムなし）を達成することは可能ですか？

SQL2005 データベースをスキャンすると、テーブルに次の 2 つのインデックスが表示されました。

私の最初の考えは、PK_CLUSTERED_INDEX には既にこれらの列が含まれているため、最後のインデックスを削除し、正しい順序と並べ替えを行うことです。最後のインデックスはまったく利益をもたらしますか?