2

短い背景

こんにちは。現在、SQL Server スタンダード エディションの非常に大きなテーブルでパフォーマンスを向上させる必要がある状況に直面しています。テーブルはトランザクションが重いため、かなり多くのトランザクションが発生することが予想されます。

ソリューション パート 1

Barry King がここで提案したものと同様の戦略を使用して、テーブルをいくつかのパーティションに分割することにしました。そのため、以下のようなテーブルがたくさんあります。

CREATE TABLE [NewTable001](
    [DayId] [int] NOT NULL,
    [OriginalTableId] [bigint] NOT NULL,
    [CustomerId] [int] NULL
 CONSTRAINT [PK_OriginalTableID001] PRIMARY KEY CLUSTERED 
(
    [OriginalTableID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,             ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [NewTable001]  WITH CHECK ADD  CONSTRAINT [CK_Day_001] CHECK  ([DayId]=(1))
GO

ALTER TABLE [NewTable001] CHECK CONSTRAINT [CK_Day_001]
GO

基になるすべてのテーブルを処理するための対応するビューもあります。ここでの問題は、Barry King がブログ投稿で述べているように、ビュー内の一意の ID の処理です。ビューは ID を処理できないため、テーブルに格納する必要があり、ID 機能を利用できません。

ソリューション パート 2

次のように別のテーブルを作成することにより:

create table PartitionIDHelper
(
ID bigint identity(10000001,1), --Hihger (with margin) than the higest value in current    table
Value int --Something that is quick to write
);

そして、このコードを使用して私の手順で：

declare @ID bigint;
insert into PartitionIDHelper
select 1; --Just a value so that I can get the unique ID from the table
select @ID = @@IDENTITY; --My shiny new id value to use when writing to the view</pre>

潜在的な問題

このソリューションの潜在的な問題は、間違った順序で [OriginalTableID] に値を書き込む可能性があることです。

プロセス A がプロセス B の前に開始すると仮定します。プロセス A は、プロセス B よりも前に PartitionIDHelper テーブルから ID を取得します。ただし、プロセス B はより高速であり、プロセス B の前に書き込みを行うため、プロセス A よりも先にクラスター化インデックスに書き込みが行われます。

プロセス A は、順序が正しくないため、インデックス内の「最適な」位置に書き込みません。

考えられる解決策

では、どうすればこれを最もよく解決できますか？2つの戦略が考えられます。

  1. 私のクラスタ化されたインデックスが少し順不同であることを受け入れます
  2. クラスター化インデックスのために、各テーブルでローカル ID 列を使用します。

考えられる解決策 2 は、順序を格納する以外の目的でその列を使用することは決してないため、悪いパスのように思えます。

Michelle Ufford によるこのブログ投稿 (のほとんど) を読んだ後、私は少し断片化されたクラスター化インデックスに固執する方向に傾いています。データは主にシングルトン クエリによってアクセスされますが、これは挿入速度が重要な OLTP システムであるため、以下の引用は私にとって難しい質問です。

ID 整数列にのみクラスター化インデックスを作成することをお勧めしているわけではありません。断片化は一般的には望ましくありませんが、主に範囲スキャン クエリに影響します。シングルトン クエリでは、大きな影響はありません。範囲スキャン クエリでも、定期的な最適化作業の恩恵を受けることができます。ただし、クラスター化されたキーの増加し続ける属性は考慮すべき事項であり、INSERT 速度が重要な OLTP システムでは特に重要です。

すべてのコメントと提案は非常に高く評価されます!

/ターハー

4

0 に答える 0