タグ付けされた質問 「nonclustered-index」

1
行を削除すると、非クラスター化インデックスがより多くのスペースを使用するのはなぜですか？
75億行と5つのインデックスを持つ大きなテーブルがあります。約1,000万行を削除すると、非クラスター化インデックスが格納されているページ数を増やすように見えることに気付きました。 私はdm_db_partition_statsページの違いを報告するためのクエリを書きました（後-前）： インデックス1はクラスター化インデックス、インデックス2は主キーです。その他は非クラスター化され、一意ではありません。 これらの非クラスター化インデックスでページが増えているのはなぜですか？ 数値は最悪でも同じままになると予想していました。 削除中にパフォーマンスカウンターがページ分割の増加を報告するのを見ます。 削除するとき、ゴーストレコードは別のページに移動する必要がありますか？これは「一意性」と関係がありますか？ 私たちはRCSIの展開を進めていますが、現在、RCSIはオフになっています。 これは、可用性グループのプライマリノードです。私はスナップショットがセカンダリで何らかの形で使用されていることを知っています。それが関連していた場合、私は驚くでしょう。これを掘り下げて（dbccページの出力を調べて）詳細を調べる予定です。誰かが似たようなものを見たことを願っています。
1
非クラスター化インデックスにクラスター化インデックス列を含める必要がありますか？
非クラスター化インデックスはクラスター化インデックスに基づいていることを考慮すると、非クラスター化インデックスには、クラスター化インデックスに含まれる列のいずれかをリストする必要がありますか？ 言い換えると、ProductsテーブルにProductIDのクラスター化インデックスが含まれている場合、ProductID列を含めることが望ましい非クラスター化インデックスを作成するときに、列として追加する必要がありますか？ そうでない場合、非クラスター化インデックスに列名を追加するとよいシナリオはありますか？
2
SELECT TOPでインデックスが使用されないのはなぜですか？
要約は次のとおりです。選択クエリを実行しています。WHEREand ORDER BY句のすべての列IX_MachineryId_DateRecordedは、キーの一部として、またはINCLUDE列として、単一の非クラスター化インデックスに含まれます。すべての列を選択しているので、ブックマークルックアップTOP (1)になりますが、を取得するだけなので、サーバーはルックアップを最後に一度だけ実行する必要があることを確認できます。 最も重要なことは、クエリでindexを使用するように強制するとIX_MachineryId_DateRecorded、1秒未満で実行されることです。使用するインデックスをサーバーに決定させると、サーバーが選択しIX_MachineryId、最大1分かかります。これは、私がインデックスを正しく作成したことを本当に示唆しており、サーバーは単に悪い判断を下しています。どうして？ CREATE TABLE [dbo].[MachineryReading] ( [Id] INT IDENTITY (1, 1) NOT NULL, [Location] [sys].[geometry] NULL, [Latitude] FLOAT (53) NOT NULL, [Longitude] FLOAT (53) NOT NULL, [Altitude] FLOAT (53) NULL, [Odometer] INT NULL, [Speed] FLOAT (53) NULL, [BatteryLevel] INT NULL, [PinFlags] BIGINT NOT NULL, [DateRecorded] DATETIME NOT …
1
未使用のNONCLUSTERED INDEXでクエリの速度を向上させることはできますか？
これは奇妙な状況ですが、誰かが答えを持っていることを望んでいます。 いくつかのパフォーマンストラブルシューティング中に、NONCLUSTERED INDEXをテーブルに追加しましたsp_BlitzIndex。翌日にその使用状況を確認したところ、読み取り数が0（スキャン/シークが0、シングルトンルックアップが0）であったため、無効にしました。 すぐに、INDEXを追加したときに最初にチェックして解決しようとしていたのと同じアプリの遅さ（パフォーマンスの問題）の苦情を受け取ります。 さて、理論的には、これはまったく偶然のように聞こえます。インデックスは、証明可能、測定可能、使用されていません。無効にしても、クエリのパフォーマンスが低下することはありません。しかし、それはほとんどだTOO偶然。 質問 したがって、私の質問は、単純に十分なものです。 それはすべての可能で、その利用統計情報（のDMVから/非クラスタ化インデックスは、こと、sp_BlitzIndex）まだされており、NOの使用状況を表示しません助けて影響を受けたテーブルの上に何らかの形でクエリのパフォーマンスを？
3
高選択性フィールドと低選択性フィールドを持つ複合インデックス順のフィールド順
30億行を超えるSQL Serverテーブルがあります。クエリの1つに非常に長い時間がかかるため、最適化を検討しています。クエリは次のようになります。 SELECT [Enroll_Date] ,Count(*) AS [Record #] ,Count(Distinct UserID) AS [User #] FROM UserTable GROUP BY [Enroll_Date] [Enroll_Date]は選択可能な値が50未満の選択性の低い列ですが、UserID列は2億を超える個別の値を持つ選択性の高い列です。私の研究に基づいて、私はこれらの2つの列に非クラスター化複合インデックスを作成する必要があると考えています。理論的には、高選択性の列が最初の列である必要があります。しかし、私の場合、group by句で低選択性カラムを使用しているため、うまくいくかどうかはわかりません。 このテーブルにはクラスター化インデックスがありません。
2
IPアドレスの保存-varchar（45）とvarbinary（16）
2つのフィールド（IDas BIGINTおよびIPAddressas varchar(45)またはor）を持つテーブルを作成しますvarbinary(16)。アイデアは、すべての一意のIPアドレスを保存し、他のテーブルのID実際のIPアドレスの代わりに参照を使用することIP addressです。 一般的に、ID与えられたforを返す、IP addressまたは（アドレスが見つからなかった場合は）アドレスを挿入して生成されたを返すストアドプロシージャを作成しますID。 多くのレコードがあることを期待しています（正確な数はわかりません）が、上記のストアドプロシージャをできるだけ速く実行する必要があります。それで、実際のIPアドレスをテキストまたはバイト形式で保存する方法を知りたいです。どっちがいいの？ SQL CLRIPアドレスのバイトを文字列に変換したり、その逆を行ったりするための関数をすでに作成しているため、変換は問題ではありません（IPv4およびの両方で機能しますIPv6）。 検索を最適化するためにインデックスを作成する必要があると思いIP addressますが、クラスター化インデックスにフィールドを含める必要があるのか、または別のインデックスを作成し、どのタイプで検索を高速化するのかわかりませんか？
3
オプティマイザが非クラスタ化インデックスの代わりにクラスタ化インデックス+ソートを選択するのはなぜですか？
次の例を考えてみましょう： IF OBJECT_ID('dbo.my_table') IS NOT NULL DROP TABLE [dbo].[my_table]; GO CREATE TABLE [dbo].[my_table] ( [id] int IDENTITY (1,1) NOT NULL PRIMARY KEY, [foo] int NULL, [bar] int NULL, [nki] int NOT NULL ); GO /* Insert some random data */ INSERT INTO [dbo].[my_table] (foo, bar, nki) SELECT TOP (100000) ABS(CHECKSUM(NewId())) …
3
非クラスター化インデックスは行の順序について何か保証しますか？
私は、order byなしのselectステートメントを実行するときに、テーブルの行が挿入された順序になるようにしたいと考えている開発者がいます。開発者は、クラスター化インデックスから非クラスター化インデックスへの変更を提案しました。 インデックスをクラスター化から非クラスター化に変更することで、テーブルに行が表示される順序について何か保証はありますか？ この質問は主に私の好奇心です。代わりにID列を使用することをお勧めしますが、このリクエストは私に考えさせられました。タイムスタンプを使用できますが、行を同時に挿入できる可能性があります。 よろしくお願いします。
1
「警告：操作により、残留I / Oが発生しました」とキールックアップの比較
SQL Server 2017実行プランでこの警告を見てきました： 警告：操作によりIOが残りました[sic]。実際に読み取られた行数は（3,321,318）でしたが、返された行数は40でした。 SQLSentry PlanExplorerからのスニペットは次のとおりです。 コードを改善するために、SQL Serverが関連する行にアクセスできるように、非クラスター化インデックスを追加しました。これは正常に機能しますが、通常は（大きな）列が多すぎてインデックスに含めることができません。次のようになります。 インデックスのみを追加し、列を含めない場合、次のようになります。インデックスを強制的に使用すると、 明らかに、SQL Serverは、キールックアップは残りのI / Oよりもはるかにコストがかかると考えています。（まだ）多くのテストデータを含まないテストセットアップがありますが、コードが運用環境に入ると、より多くのデータを処理する必要があるため、何らかの非クラスター化インデックスが必要だとかなり確信しています。 SSDで実行する場合、キールックアップは本当に高価ですが、私は（多くのインクルード列を含む）全脂肪インデックスを作成する必要がありますか？ 実行計画： https : //www.brentozar.com/pastetheplan/?id=SJtiRte2Xこれは、長いストアドプロシージャの一部です。を探しIX_BatchNo_DeviceNo_CreatedUTCます。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.