問題タブ [clustered-index]

プログラムのアップグレードコンポーネントに取り組んでいます。これには、インデックスの名前を変更する必要があります

N'Sig_Summary3Index.IX_Sig_Summary1Index1_StartTime', N'INDEX';

（SQL SERVER 2005との互換性を維持する必要があります）

次に、それが同じトランザクションに存在するかどうかを確認します。

これにより、インデックスが作成されます。:(どういうわけか、トランザクション中にsys.indexesテーブルはまだ更新されていません。このインデックスの作成を回避する他の方法はありますか？

編集：sysテーブルを「フラッシュ」して更新する方法はありますか？レコードを手動で挿入しますか？「チェック」が変更されないように何かしますか？

私は次のクエリを持っています：

ご想像のとおり、「STID」は「SecondTable」の主キーです...そして「FirstTable」にはその2番目のテーブルへのポインタがあります。これが私が持っているインデックスです：

FirstTable：列「STID」のNONCLUSTERED INDEX

SecondTable：CLUSTERED PRIMARY KEY「STID」のINDEX

上記のクエリでは、サブツリーのコストは19.90で、2秒かかります。

そのクエリに対してデータベースチューニングアドバイザーを実行した後、彼らは私が2番目のテーブルに持っていたものとまったく同じインデックスを作成することを提案しました...しかしクラスター化されていません。だから私はこれらの結果でそれを試しました。

FirstTable：列「STID」のNONCLUSTERED INDEX

SecondTable：NONCLUSTERED「STID」のINDEX

さて、上記のクエリは私に10.97のサブツリーコストを与え、 1秒未満かかります！

この100％は私の脳を粉砕します...このシナリオでNONCLUSTEREDインデックスがCLUSTEREDインデックスよりも高速に実行されるのはなぜですか？

面接の質問の知識と私の知識のためだけに。

ClusterSQL-との違いNon-cluster index？

Productテーブル、Orderテーブル、および（ジャンクションテーブル）ProductOrderがあるとします。

ProductOrderには、ProductIDとOrderIDがあります。
ほとんどのシステムでは、これらのテーブルにはIDと呼ばれる自動番号列もあります。

主キー（およびそのためにクラスター化されたキー）を配置するためのベストプラクティスは何ですか？

• IDフィールドの主キーを保持し、外部キーペア（ProductIDとOrderID）の非クラスター化インデックスを作成する必要があります

• または、外部キーペアの主キー（ProductIDとOrderID）を配置し、ID列に非クラスター化インデックスを配置する必要があります（必要な場合でも）

• または...（あなたの一人による賢い発言:)）

多くの場所で、BETWEEN ステートメントを使用して行の範囲を選択するためにクラスター化インデックスを使用することをお勧めします。このクラスター化インデックスが使用されるような方法で外部キー フィールドによる結合を選択すると、クラスター化も役立つはずです。これは、すべて同じクラスター化キー値があり、BETWEEN が使用されていないにもかかわらず、行の範囲が選択されているためです。

join を使用して選択したものだけを気にし、他には何も気にしないことを考えると、私の推測は間違っていますか?

クラスター化されたインデックスのポイントがわかりません。いつメリットがありますか？

ある日付タイプのテーブルにフィールドがあり、常に のような比較を使用して検索することがわかっている場合between、>またはそれにインデックスを追加しない正当な理由はあり<ませんか?=

アルバイトの渋々DBAです。既存の主キー インデックスをクラスター化から非クラスター化に変更したいと考えています。そして、構文は私を逃れています。

これが現在スクリプト化されている方法です。

オンライン ドキュメントに ALTER CONSTRAINT ステートメントがありません。

すべての PK が GUID であるデータベースがあり、ほとんどの PK はテーブルのクラスター化インデックスでもあります。これが悪いことであることはわかっています (GUID のランダムな性質のため)。したがって、ここには基本的に 2 つのオプションがあるようです (GUID を PK として完全に破棄することを除けば、これはできません (少なくとも現時点ではできません))。

• この記事で詳しく説明されているように、GUID 生成アルゴリズムを NHibernate が使用するアルゴリズムなどに変更することもできます。
• 最も頻繁に使用されているテーブルについては、別のクラスター化インデックス (IDENTITY 列など) に変更し、「ランダムな」GUID を PK として保持することができます。

そのようなシナリオで一般的な推奨事項を与えることは可能ですか?

問題のアプリケーションには 500 以上のテーブルがあり、最大のものは現在約 1,500 万行、いくつかのテーブルは約 500,000 行で、残りは大幅に少なくなります (ほとんどのテーブルは 10K をはるかに下回っています)。

さらに、アプリケーションはすでにいくつかの顧客サイトにインストールされているため、既存の顧客への悪影響を考慮する必要があります。

ありがとう！

SQL Serverにテーブルがあり、テーブルの最後に挿入を追加します（中央に挿入されるクラスタリングキーとは対照的です）。これは、テーブルが常に増加する列によってクラスター化されることを意味します。

datetimeこれは、列でクラスタリングすることで実現できます。

しかし、私は2つThingsが同じ時間を持たないことを保証することはできません。したがって、私の要件は、日時列では実際には達成できません。

ダミーのID int列を追加し、その上にクラスター化することができます。

しかし、私のテーブルにはすでに列が含まれていることに気付くでしょうtimestamp。単調に増加することが保証されている列。これはまさに、候補クラスターキーに必要な特性です。

したがって、テーブルをrowversion（aka timestamp）列にクラスター化します。

順序を確認するためにダミーのID 列（RowID）を追加するのではなく、intすでに持っているものを使用します。

私が探しているのは、なぜこれが悪い考えなのかという考えです。そして他にどんなアイデアが良いのか。

注：回答は主観的なものであるため、コミュニティwiki。