4

私は、列ストア インデックスがテーブルに対してどのようなパフォーマンスの向上をもたらすかを確認しようとしていました。このテーブルには、約 370 万行、11 列があり、ヒープとして (主キーなしで) 格納されます。テーブルに列ストア インデックスを作成し、次のクエリを実行します。

SELECT 
    [Area], [Family],
    AVG([Global Sales Value]) AS [Average GlobalSalesValue],
    COUNT([Projected Sales])
FROM 
    dbo.copy_Global_Previous5FullYearSales
WHERE 
    [Year] > 2012  
GROUP BY 
    [Area], [Family]

create table ステートメントは次のとおりです。

CREATE TABLE [dbo].[copy_Global_Previous5FullYearSales]
(
    [SBU] [NVARCHAR](10) NULL,
    [Year] [INT] NULL,
    [Global Sales Value] [MONEY] NULL,
    [Area] [NVARCHAR](50) NULL,
    [Sub Area] [NVARCHAR](50) NULL,
    [Projected Sales] [MONEY] NULL,
    [Family] [NVARCHAR](50) NULL,
    [Sub Family 1] [NVARCHAR](50) NULL,
    [Sub Family 2] [NVARCHAR](50) NULL,
    [Manufacturer] [NVARCHAR](40) NULL,
    [rowguid] [UNIQUEIDENTIFIER] NOT NULL,
    [ID] [INT] IDENTITY(1,1) NOT NULL,

    PRIMARY KEY CLUSTERED ([ID] ASC)
        WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
              IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
              ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

この場合、列ストア インデックスから得られるパフォーマンスの向上はごくわずかです。列ストア インデックスを使用したクエリは、インデックスを使用しない元のクエリとほぼ同じ速度で実行されます。場合によっては、バッチ モードの処理が使用されている場合でも、さらに低速になります。

驚いたことに、増加し続ける主キー ID を既存のテーブルに作成し、列ストア インデックスを再構築すると、CPU 時間は 15 倍、経過時間は 3 倍改善されました。

主キーを追加すると、データを圧縮形式で格納する列ストア インデックスのクエリ パフォーマンスにどのように影響するかわかりません。また、主キーはページの順序のみを変更しますが、この場合は変更されません。

以下は実行計画です実行計画

4

1 に答える 1

4

aa キーの存在により、列ストアの構築方法が変わります。Builder は順番に入力を取得するため、結果のセグメントはセグメント除去のより適切な候補になります。詳細については、データが日付によって並べ替えられているか、ほぼ並べ替えられていることを確認して、日付範囲の削除を活用してください :

データ ウェアハウス クエリで最も一般的なフィルターの種類は、日付によるものです。列ストア セグメントの削除は、セグメント内の列の最小値と最大値を調べるだけで、適格な行がないとシステムが判断できる場合に、100 万行のセグメント全体をスキップするのに役立ちます。したがって、通常は、日付フィルターをできるだけ早く実行できるように、セグメントが日付で並べ替えられているか、ほぼ並べ替えられていることを確認する必要があります。

ご注文はお受けしてIDいますが、それが機能的な依存関係の副作用を引き起こすと確信しています。

于 2015-04-03T13:30:17.000 に答える