問題タブ [non-clustered-index]

私はこのように定義されたテーブルを持っています

上記のPK_MyTableNONCLUSTEREDインデックスとは別に、SomeTable2IdおよびSomeTable3Idに対する他のNONCLUSTEREDインデックスはほとんどありません。

上記のCLUSTEREDインデックスを作成する方が理にかなっていると思いますが、CLUSTEREDインデックスを作成せず、代わりにNONCLUSTEREDを作成する正当な理由があるのでしょうか。

PSこれらのトピックに関して多くの質問がありますが、関連する質問が見つかりませんでした（トップ20リスト）。これが尋ねられた場合は、関連する質問の投稿にリダイレクトしてください。

編集：MyTableが他の2つのテーブルSomeTable2をマッピングSomeTable3していて、複合キーを使用する代わりに、これを使用している場合を考えてみます。MyTableIdしたがって、ほとんどの場合、クエリにはSomeTable2IdまたはSomeTable3Idと他のIDの取得を要求します。したがって、このテーブルの使用法に照らして、クラスター化されたインデックスを作成する必要があるのでしょうか、MyTableIdそれとも2つの非クラスター化されたインデックスSomeTable2Idを作成する必要があるのSomeTable3Idでしょうか。

私は人々のタイトル（「Mr」、「Mrs」など）を格納する非常に単純なテーブルを持っています。これが私がやっていることの簡単なバージョンです（この例では一時テーブルを使用していますが、結果は同じです）：

テーブルの主キーはクラスター化され (例のために明示的に)、タイトル列にはクラスター化されていない一意性制約があることに注意してください。

選択操作の結果は次のとおりです。

実行計画を見ると、SQL はクラスター化された主キーよりも非クラスター化インデックスを使用しています。結果がこの順序で返される理由はこれで説明できると思いますが、なぜこれが行われるのかはわかりません。

何か案は？さらに重要なことに、この動作を止める方法はありますか? 行が挿入された順序で返されるようにします。

ありがとう！

次のようないくつかの列でフィルター処理された非クラスター化を作成したテーブルがあります。

と：

エラーなしでテーブルにこのインデックスを作成しますが、新しい列を追加しようとすると、次のエラーが発生します。

ステートメントは終了されました。

私のテーブルデータは次のとおりです。

最初のインデックスによると、行 No. 1 と No. 4 は where 節を満たしていないため、行にインデックスを作成しないでください。なぜ上記のエラーが発生するのですか?

ありがとう

編集1）：

興味深い点があります。そのインデックスを削除して列を追加すると、そのインデックスを再作成すると、インデックスはエラーなしで作成されます.STRANGE!!!!

私には、彼が「マトリックス」と呼んでいるものに非常に熱心な新進の開発者がいます</p>

ピアインサイトを探しています

簡単に言うと、これが私たちが持っているものです:
- 約 120 列の 1 つの高度に非正規化されたテーブル
- アカウント、顧客、世帯、関係、製品、従業員などのデータ ポイントの範囲...<br> - 列ごとに 1 つのインデックス: 約 120 の非-クラスタ化されたインデックス - 現在
インデックスで使用されているデータベース内の全領域の約 90% は、このテーブルのインデックスです
- 現在、多くの null を含む約 150 万行
- 動的 SQL をコアとするストアド プロシージャをロードしたテーブル
- すべてのフィールド名は汎用的ですデータを記述しない
- データ ディクショナリ タイプのテーブルを動的 SQL で使用して、任意のデータ ポイントを任意のフィールドにロードします
- フィールド マッピングは静的ではありません。今日は列 dim_0001 が顧客名ですが、明日は別の名前になる可能性があります
- 主キー
なし - 外部キー
なし - 実際の制約なし (たとえば、すべてのフィールドが null 可能)

テーブルの引数:
- 結合を記述する必要がなくなるため、クエリの記述が簡単になります。

使用目的:
- End User Layer であり、Business Objects のユニバース ビルドのコア コンポーネントとなる
- ETL プロセス開発 後

私の推奨事項は、現在のプロセスを強制終了するか (テスト環境での初期開発)、テストの次のステップに移行することです。

私が行った調査、教育、および経験に基づいて、私はそれをサポートしていません。これらのテーブルに依存する 1 つまたは 2 つのプロセスが別のソリューションに移行されたら、すぐにテーブルを削除したいと考えています。

以下のスクリプトを参照してください (インデックスの例を 1 つに限定しました)。

あなたが提供できる洞察は（たとえ一言の意見であっても）価値があります

3 つのテーブルの内部結合を行うクエリがあります。

言及されたテーブルに存在するデータ->

• テーブル A: 8000 行
• 表 B: 900000 行
• 表 C: 10,00,000 行

以下は、SQL Server クエリ プランから明らかになった統計です。

ここでは、コストのかかる 2 つのインデックス シークが使用されています。上位のインデックス シークには、次の統計があります。

ボトム インデックス シークには次の統計があります。

現在、このクエリの実行には平均で 5 分かかりますが、クエリが既にインデックス シークを使用しているため、実行を高速化するために何をすべきかを理解できません。{結果セットにはすべての結合が必要です}。助けが必要 ！

400 ～ 500 行しかないテーブルがありますが、このテーブルは頻繁にアクセスされるため、列の 1 つに非クラスター化インデックスを追加して改善を確認する必要があるかどうか疑問に思っていました。

このテーブルは常に同じデータを保持し、めったに更新されません。

これがテーブルの構造です

このクラスター インデックスを使用すると、次のようになります。

region 列がnullになる可能性があるため、このテーブルには主キーがありません。そのため、まだキーを使用していません。

そのため、パフォーマンスを向上させるために、タイムゾーン列に非クラスターインデックスを追加したいと考えています。

SQL 用語では、HEAP は非クラスター化インデックスを持つテーブルを表しますか?

それともニュアンスがあるのか​​、全く違う意味なのか？

SQL Server 2008 R2を使用していて、一意ではないnull許容フィールドに非クラスター化インデックスを追加したいと思います。クラスタ化されたインデックスへのアクセスを回避するために、インデックスにはもう1つの列が含まれます。

の実際のデータにmyBasicFieldはたくさんありますが、NULLsこれらをスキャンしないことでパフォーマンスを向上させる方法NULLsやNULL、インデックスに値が保存されないようにする方法があるのではないかと考えていました。

前もって感謝します。

独自のインデックスを開発しようとしています。

私のエラーは

これが別の試みです。これは、ISNULL（MyField、''）の部分を削除しました。なぜこれは持つことができないのORですか？

エラーは次のとおりです。

昨日、次の行に沿って update ステートメントを実行しました。

ここで、SubsetTableは のサブセットでMainTableあり、同じ主キー フィールドを持ちます。MainTableおよそ 2 億件のレコードがあり、 SubsetTable500 万件のレコードがあります。MainTableKeyGUID です。

これらのテーブルの両方に、クラスター化インデックスがありMainTableKeyます。

このクエリを初めて実行したとき、なんと 14 時間かかりました。

MainTableKey次に、両方のテーブルに非クラスター化インデックスを追加しました。今では30分かかります。

なぜパフォーマンスの向上がそれほど劇的になるのかについて、誰か考えがありますか?