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

SQL-Serverで主に使用されるインデックスの一種で、テーブルのデータをインデックスに揃えます。

3
SSDを使用する場合、DB設計のクラスター化インデックスの概念は意味がありますか?
SQLサーバーのデータスキーマと後続のクエリ、Sproc、ビューなどを設計するとき、クラスター化インデックスの概念とディスク上のデータの順序は、SSDプラットフォームに明示的に展開されるように設計されたDB設計について考慮する必要がありますか? http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx 「クラスター化インデックスは、テーブル内のデータの物理的な順序を決定します。」 物理ディスクプラットフォームでは、「シーケンシャル」行を取得するためのデータの物理スキャンは、テーブルをシークするよりもパフォーマンスが高いため、これらを考慮する設計は理にかなっています。 SSDプラットフォームでは、すべてのデータ読み取りアクセスで同一のシークが使用されます。「物理的順序」の概念はなく、データの読み取りは、ビットが同じシリコンに格納されるという意味で「シーケンシャル」ではありません。 それでは、アプリケーションデータベースを設計する過程で、クラスタ化インデックスの考慮事項はこのプラットフォームに関連していますか? 私の最初の考えは、「順序付けられたデータ」の概念がSSDストレージとシーク/リトライバルの最適化に適用されないためではないということです。 編集:私はSQL Server がそれを作成することを知っています、私はそれが設計/最適化中にそれを考えることが理にかなっているかどうかについて哲学的です。

6
テストケースでシーケンシャルGUIDキーがシーケンシャルINTキーよりも高速に実行されるのはなぜですか?
求めた後、このシーケンシャルおよび非シーケンシャルGUIDを比較する質問を、私はGUID主キーを持つテーブルがで順次初期化)1上のINSERTのパフォーマンスを比較してみましたnewsequentialid()主キーがで順次初期化INTと、および2)テーブルidentity(1,1)。整数の幅が小さいため、後者の方が高速であると予想されます。また、順次GUIDよりも順次整数を生成する方が簡単だと思われます。しかし、驚いたことに、整数キーを持つテーブルでのINSERTは、シーケンシャルGUIDテーブルよりも大幅に遅くなりました。 これは、テスト実行の平均時間使用量(ミリ秒)を示します。 NEWSEQUENTIALID() 1977 IDENTITY() 2223 誰でもこれを説明できますか? 次の実験が使用されました。 SET NOCOUNT ON CREATE TABLE TestGuid2 (Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID() PRIMARY KEY, SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100)) CREATE TABLE TestInt (Id Int NOT NULL identity(1,1) PRIMARY KEY, SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100)) DECLARE @BatchCounter INT = 1 DECLARE …

3
ヒープ上の非クラスター化インデックスとクラスター化インデックスのパフォーマンス
この2007年ホワイトペーパーでは、クラスター化インデックスとして構成されたテーブルと、CIと同じキー列に非クラスター化インデックスを備えたヒープとして構成されたテーブルの個々の選択/挿入/削除/更新および範囲選択ステートメントのパフォーマンスを比較しています表。 通常、クラスター化インデックスオプションは、維持する構造が1つだけであり、ブックマークの参照が不要なため、テストでのパフォーマンスが向上しました。 この論文で取り上げられていない興味深いケースの1つは、ヒープ上の非クラスター化インデックスとクラスター化インデックス上の非クラスター化インデックスの比較です。その場合、NCIリーフレベルでSQL Serverがクラスター化インデックスをトラバースする必要がなく、直接従うRIDを持っているため、ヒープのパフォーマンスがさらに向上することを期待していました。 この分野で行われた同様の正式なテストを知っている人はいますか?

2
PKインデックスの列の順序は重要ですか?
同じ基本構造を持ついくつかの非常に大きなテーブルがあります。それぞれにRowNumber (bigint)とDataDate (date)列があります。データは毎晩SQLBulkImportを使用してロードされ、「新しい」データはロードされません-その履歴レコード(エンタープライズではなくSQL標準なので、パーティショニングはありません)。 データの各ビットは他のシステムに結び付ける必要があり、各RowNumber/DataDate組み合わせは一意であるため、それが私の主キーです。 SSMS Table DesignerでPKを定義した方法により、RowNumber最初とDataDate2番目にリストされていることに気付きました。 また、私の断片化は常に非常に高い〜99%であることに気付きます。 今、それぞれDataDateが一度しか表示されないため、インデクサーが毎日ページに追加することを期待していますが、実際にはRowNumber最初に基づいてインデックス付けされているので、他のすべてを移動する必要がありますか? RownumberID列ではなく、外部システムによって(悲しいことに)生成されたintです。それぞれの開始時にリセットされますDataDate。 サンプルデータ RowNumber | DataDate | a | b | c..... 1 |2013-08-01| x | y | z 2 |2013-08-01| x | y | z ... 1 |2013-08-02| x | y | z 2 |2013-08-02| x | y | z ... …

3
HEAPテーブルの有効な使用シナリオは何ですか?
現在、いくつかのデータをレガシシステムにインポートしていますが、このシステムが単一のクラスター化インデックスを使用していないことがわかりました。簡単なGoogle検索でHEAPテーブルの概念を紹介しましたが、クラスター化されたテーブルよりもHEAPテーブルを優先する使用シナリオを知りたいのですが。 私が理解している限り、HEAPテーブルは監査テーブルおよび/または挿入が選択よりもはるかに頻繁に発生する場合にのみ役立ちます。維持するクラスター化インデックスがないため、ディスク領域とディスクI / Oが節約され、非常にまれな読み取りのため、追加の断片化は問題になりません。

3
インデックスREBUILDがインデックスの断片化を軽減しないのはなぜですか?
ALTER INDEX REBUILDを使用して、インデックスの断片化を削除しました。場合によっては、REBUILDはこのフラグメンテーションを削除しないようです。REBUILDがフラグメンテーションを削除しない理由は何ですか?これは特に小さなインデックスで発生するようです。

3
クラスタ化インデックス付きのテーブルへの効率的なINSERT
TRACKING_NUMBER列にクラスター化インデックスが設定されたテーブルに行を挿入するSQLステートメントがあります。 例えば: INSERT INTO TABL_NAME (TRACKING_NUMBER, COLB, COLC) SELECT TRACKING_NUMBER, COL_B, COL_C FROM STAGING_TABLE 私の質問は-クラスター化インデックス列のSELECTステートメントでORDER BY句を使用するのに役立ちますか、またはORDER BY句に必要な追加の並べ替えによってゲインが無効になりますか?

4
「増分キーに基づいたクラスター化インデックスの作成を避ける」ことは、SQL Server 2000日からの神話ですか?
私たちのデータベースは多くのテーブルで構成されており、そのほとんどは整数の代理キーを主キーとして使用しています。これらの主キーの約半分はID列にあります。 データベース開発は、SQL Server 6.0の時代に始まりました。 これらのインデックス最適化のヒントにあるように、最初から続いているルールの1つは、増分キーに基づいてクラスター化インデックスを作成しないことです。 現在、SQL Server 2005とSQL Server 2008を使用して、状況が変わったという強い印象を持っています。一方、これらの主キー列は、テーブルのクラスター化インデックスの完全な最初の候補です。

1
SQL Serverで、クラスター化インデックスの逆方向スキャンで並列処理を使用できないのはなぜですか?
私はSQL Serverの内部について読んでいますが、すべての本やブログでは後方スキャンについてこれに言及しています。 クラスター化インデックスの逆方向スキャンでは並列処理を使用できません 何かを言った唯一の投稿は、以下のこの投稿です。投稿によると、SQL Serverチームは後方スキャンに必要な最適化を実装していません。https://www.itprotoday.com/sql-server/descending-indexes リーフレベルのページは二重にリンクされたリストを使用してリンクされているため、後方スキャンが前方スキャンと異なる理由はわかりません。明確化をお願いします。

1
選択されているインデックス付きビューのクラスター化インデックスに含まれる要因は何ですか?
簡単に言えば、 オプティマイザによるインデックス付きビューのインデックスの選択をクエリする要因は何ですか? 私にとって、インデックス付きビューは、オプティマイザーがインデックスを選択する方法について理解していることに反しているようです。私が見てきた、これは前に尋ねたが、OPはあまり好評ではなかったです。 私は本当に道しるべを探していますが、擬似的な例を作成してから、多くのDDL、出力、例を含む実際の例を投稿します。 私はEnterprise 2008+を使用していると仮定し、理解します with(noexpand) 疑似の例 この擬似的な例を見てみましょう。22個の結合、17個のフィルター、1000万行のテーブルを横断するサーカスポニーを含むビューを作成します。このビューは、実現するのに高価です(ええ、大文字のE)。SCHEMABINDとビューのインデックスを作成します。それから SELECT a,b FROM AnIndexedView WHERE theClusterKeyField < 84。私を回避するオプティマイザーロジックでは、基になる結合が実行されます。 結果: ヒントなし:720行で4825の読み取り、76ミリ秒で47 CPU、0.30523の推定サブツリーコスト。 ヒントあり:17読み取り、720行、4ミリ秒で15 CPU、0.007253の推定サブツリーコスト ここで何が起こっているのでしょうか?Enterprise 2008、2008 -R2、および2012で試してみました。ビューのインデックスを使用すると考えられるすべてのメトリックで、はるかに効率的です。これはアドホックであるため、パラメータスニッフィングの問題やデータの偏りはありません。 実際の(長い)例 あなたが自虐的なタッチでない限り、おそらくこの部分を読む必要はないでしょう。 バージョン うん、企業。 Microsoft SQL Server 2012-11.0.2100.60(X64)2012年2月10日19:39:15 Copyright(c)Microsoft Corporation Enterprise Edition(64-bit)on Windows NT 6.2(Build 9200:)(ハイパーバイザー) 景色 CREATE VIEW dbo.TimelineMaterialized WITH SCHEMABINDING AS SELECT TM.TimelineID, …



2
多数の重複値で使用するインデックスは何ですか?
いくつかの仮定をしてみましょう。 次のような表があります。 a | b ---+--- a | -1 a | 17 ... a | 21 c | 17 c | -3 ... c | 22 私のセットに関する事実: テーブル全体のサイズは〜10 10行です。 私は値で〜100kの行を持ってa列内のa他の値(例えばについても同様、c)。 これは、列 'a'に〜100k個の異なる値があることを意味します。 私のクエリのほとんどは、aの特定の値のすべてまたはほとんどの値を読み取りますselect sum(b) from t where a = 'c'。 テーブルは、連続した値が物理的に近くなるように記述されます(順番に記述されているかCLUSTER、そのテーブルと列で使用されていると仮定しますa)。 テーブルが更新されることはめったにありません。読み取り速度のみが重要です。 テーブルは比較的狭い(タプルごとに〜25バイト、+ 23バイトのオーバーヘッドなど)。 問題は、どのようなインデックスを使用する必要があるかということです。私の理解は: BTreeここでの私の問題は、BTreeインデックスが重複する値を格納することを知っている限り、巨大になることです(テーブルが物理的にソートされていると想定できないため、必要です)。BTreeが巨大な場合、インデックスとインデックスが指すテーブルの部分の両方を読み取る必要があります。(fillfactor = 100インデックスのサイズを少し小さくするために使用できます。) BRIN私の理解では、役に立たないページを読むことを犠牲にして、ここに小さなインデックスを作成できるということです。小さな値を使用pages_per_rangeすると、インデックスが大きくなり(インデックス全体を読み取る必要があるためBRINで問題になります)、大きな値を使用pages_per_rangeすると、多くの無駄なページを読み取ることになります。pages_per_rangeそれらのトレードオフを考慮に入れた優れた価値を見つけるための魔法の公式はありますか? GIN …

1
削除ステートメントで使用されないクラスター化インデックス
次のように定義されたSQL Serverテーブルがあります CREATE TABLE [dbo].[Production_Detail] ( [Id] [bigint] NOT NULL DEFAULT (NEXT VALUE FOR [dbo].[Production_Detail_Seq]), [Meta_Data_ID] INT NOT NULL , [Production_Detail_Time] DATETIME NOT NULL, [Production_Detail_Time_Local] DATETIME NOT NULL, [Production_Detail_Value] FLOAT NULL, [IntegratedDM] BIT NOT NULL DEFAULT 0, [DailyIntegratedDM] BIT NOT NULL DEFAULT 0, [InsertedDate] DateTime NOT NULL, [ModifiedDate] DateTime NOT …

2
VACUUM FULLとCLUSTERのPostgreSQLの違い
200 GBのサイズがデータで占められ、180 GBのサイズが6つのインデックスで占められているテーブルがあります。それは30%肥大化していますので、それによって占有されている不要なスペースを回収したいと思います。job_id_idxインデックスでクラスター化されます。 スペースを再利用するには、clusterコマンドまたはvacuum fullコマンドを使用する必要がありますか? この2つのコマンドの違いは何ですか? vacuum fullある列の順序はclusterコマンドと同じですか? 両方のコマンドでインデックスが再作成されますか? 私の場合、どちらが速くなりますか? PostgreSQLデータベースのバージョンは9.1です

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.