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

次の相互参照テーブルをSQL ServerがホストするDBに追加します。 company_id bigint not null (FK) org_path nvarchar (2048) not null company_idフィールドはid、別のテーブルのフィールドを参照します（そのフィールドが主キーです）。 同じを持つ複数のレコードも存在する可能性があることを考えるとcompany_id、主キーは両方のフィールドを使用する必要があります。ただし、org_pathSQL Serverには長すぎるため、両方のフィールドを使用してキーを作成できません。 に関してはorg_path、これが存在する唯一のテーブルです。このテーブルへのクエリがすべてのエントリまたはすべてのorg_pathエントリのいずれかを要求する可能性はほとんどありませんcompany_id。別の言い方をすると、このテーブルがによってクエリされることは疑わしいようorg_pathです。さらに、org_path更新される可能性は低く、おそらく挿入され、おそらく削除されることはほとんどありません。 行の総数は数千になると思います。 また、その理由nvarchar (2048)は、値がサードパーティのDBの値を模倣する必要があるためです。典型的な例は次のようになります \Translation Providers\[customer name]\[order name]\ 分音符号を含めることができます。 だから私の質問はこれです：自動インクリメントidフィールドを追加しcompany_idてそれを主キーとして使用する方が効率的ですか、それとも不必要なオーバーヘッドが追加されますか-そしてcompany_id、別のテーブルの主キーであるという事実にはここで効果？

9 sql-server  t-sql  primary-key  clustered-index 

PostgreSQLがディスク上のレコードをどのように並べるかを知る必要があります。この場合、docsに記載されているインデックスの組み合わせを利用したいと思います。これは、ビットマップを使用して一致する行を取得し、物理的な場所に従ってそれらを返すことを理解しています。問題のテーブルは、主キーによってクラスター化されています。 私が理解しているように、PostgreSQLはクラスタリングが終了した後、自動的にクラスタリングを継続しません（ただし、特定のインデックスに従ってクラスタリングされたことを覚えています）。さて、これが主キーなので、物理的なストレージの順序はそれに従っているのでしょうか（これがtrueの場合は、特定のクエリに有利に使用したいと思います）。 要約すると、特にクラスタリングの後、PostgreSQLは新しいレコードをどのように順序付けますか？ どうもありがとう！

9 postgresql  database-design  index  clustered-index  physical-design 

約30億行のディスク容量約104 GBを占めるヒープテーブルがあります。このテーブルの[ WeekEndingDate]列にクラスター化インデックスを作成しようとしています。データファイルには約200 GBの空き容量があり、tempdbには約280 GBの空き容量があります。 私は2つの異なる方法を試しました。最初に、次のコマンドを使用してテーブルに直接インデックスを作成しました。 CREATE CLUSTERED INDEX CX_WT_FOLD_HISTORY ON WT_FOLD_HISTORY (WeekEndingDate ASC) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = ON, IGNORE_DUP_KEY = OFF , ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE) 私は両方のそれを試してみましたSORT_IN_TEMPDB = ONとOFF。使用するONとtempdbがOFFいっぱいになり、データドライブがいっぱいになります。 他の方法は、必要なインデックスで新しい空のテーブルを作成し、ヒープから新しいテーブルにレコードを挿入することでした。データドライブがいっぱいになった後も、これは失敗しました。 何をすべきかに関するその他の提案。私が読んだほとんどのことは、インデックスを作成するときにワークスペースとして使用するには、テーブルの約1.2倍のサイズが必要だと述べています。私はそれよりはるかに多く持っていますが、それでも失敗します。任意の提案をいただければ幸いです。 これが私の元のヒープテーブル構造です。 CREATE TABLE [dbo].[WT_FOLD_HISTORY]( [WeekEndingDate] …

8 sql-server  sql-server-2008  index  clustered-index 

たとえば、1対Nの関係があるとし(person_id, pet_id)ます。pet_idが主キーであるテーブルがあります。 InnoDBセカンダリインデックスは基本的にBツリーであり、値は行の対応するプライマリキー値であると理解しています。 さて、一人の人が何千ものペットを持つことができ、私はしばしば人のペットをの順にしたいとしpet_idます。次に、セカンダリインデックスのレコードが並べ替えられている(person_id, pet_id)か、並べ替えられていないためのだけperson_idであるかが重要になります。後で推測。pet_idperson_id では、person_idが一意でない場合、レコードは、(person_id, pet_id)またはJUST によって物理的にソートされていpet_idますか？ ありがとう

8 mysql  innodb  primary-key  clustered-index 

これは、主キーで指定されたソート順から派生した質問ですが、ソートはSELECTで実行されます。 @Catcallは、ストレージの順序（クラスター化インデックス）と出力の順序についてこれを述べています。 多くの人々は、クラスター化インデックスが出力のソート順を保証すると信じています。しかし、それはそうではありません。ディスク上のストレージの順序を保証します。 たとえば、このブログ投稿をご覧ください。 Hugo Kornelisによるブログ投稿を読みましたが、インデックスがSQLサーバーが特定の順序でレコードを読み取ることを保証するものではないことを理解しています。しかし、自分のシナリオではこれを想定できないことを受け入れるのに苦労していますか？ CREATE TABLE [dbo].[SensorValues]( [DeviceId] [int] NOT NULL, [SensorId] [int] NOT NULL, [SensorValue] [int] NOT NULL, [Date] [int] NOT NULL, CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED ( [DeviceId] ASC, [SensorId] ASC, [Date] DESC ) WITH ( FILLFACTOR=75, DATA_COMPRESSION = PAGE, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, …

8 sql-server  execution-plan  clustered-index  sorting