問題タブ [non-clustered-index]

クラスター化インデックスと非クラスター化インデックスの概要-DB固有ではありません(私が理解しているように):

クラスター化インデックス: データの物理的な順序。その結果、テーブルは 1 つのクラスター化インデックスしか持つことができません。

非クラスター化インデックス: テーブルごとに 1 つ以上の非クラスター化インデックスを構成できます。データ ページの編成には直接影響しません。

Microsoft SQL Server と Oracle がクラスター化インデックスと非クラスター化インデックスを「管理」する方法に違いはありますか? それともDBS全体で同じですか？

どんなガイダンスも素晴らしいでしょう！

時間範囲内で行を選択するのに時間がかかりすぎる理由を理解しようとしています。

500 万行を超えるデータベース テーブルが 1 つあります。

FooTimestamp 列には、DateTimeOffset のタイプである非一意で非クラスター化のインデックスがあります。

時間範囲内でいくつかの行を取得しようとすると、2 分以上かかります。(再度実行すると、MS-SQL Server 2008 のキャッシュ機能により、比較的高速になると思います)

質問: 何百万ものレコードを持つテーブルから行を取得する場合、クエリ結果をより速く取得するにはどうすればよいですか? (このような簡単なクエリに 2 分は多すぎると思います)

Foo テーブルに、 ColA とColB に非クラスター化インデックスがあり、ColC、ColD にインデックスがないことを想像してください。

約 30 秒かかります。

約 2 分かかります。

Foo テーブルには 500 万行以上あります。

質問: インデックスの一部ではない列を含めると、クエリが遅くなる可能性はありますか? はいの場合、なぜですか? -既に読まれたページの一部ではありませんか?

INCLUDE 句を使用し、いくつかの列を非クラスター化インデックスに追加すると、データを INDEX とその PAGE の両方に格納するということですか?つまり、消費されるスペースが少なくとも 2 倍になりますか?

いくつかのフィールドに対して非クラスター化インデックスを作成しました。インデックス内の各キーのサイズを表示するにはどうすればよいですか? または、これは単にインデックスで使用したフィールド バイト サイズの合計ですか?

ありがとうトーマス

要件は、テーブル「empl」の 65 列すべてを最小 IOでページングに 50 レコードをロードすることです。テーブルには 280000 件以上のレコードがあります。PK 上のクラスター化インデックスは 1 つだけです。

ページネーションクエリは次のとおりです。

以下は、プロファイラーから上記のクエリを実行した後の統計です。

CPU: 1500、読み取り: 25576、期間: 25704

次に、テーブル empl に次のインデックスを配置します。

インデックスを配置した後、CPU と読み取りはさらに高くなります。インデックスのどこが悪いのか、クエリのどこが悪いのかわかりませんか?

編集：

次のクエリも、インデックスを配置した後に高い読み取りを行っています。そして、3 つの列と 1 つのカウントしかありません。

2番目の編集:

これで、「uon」列に次のインデックスを配置しました。

しかし、それでも CPU と読み取りは高くなっています。

3 番目の編集:

DTA は、最初のクエリにすべての列を含むインデックスを提案しているので、提案されたインデックスを変更して、基本的な 4 つのフィルターのフィルター インデックスに変換し、より効果的にしました。

インデックスの作成中にインクルードの後に​​以下の行を追加しました。

それでも、開発マシンと本番マシンの両方で読み取りが高くなっています。

4番目の編集:

今、私はパフォーマンスを改善するソリューションにたどり着きましたが、それでも目標には達していません. 重要なのは、それがALL THE DATAではないということです。

クエリは次のとおりです。

キー列を変更してインデックスを再作成し、インクルードとフィルター処理を行います。

パフォーマンスは向上しますが、目標には達しません。