1

数年で数百万行に成長するテーブルがあります。Webアプリケーションの一部として、ユーザーが特定のページにアクセスするたびに、このテーブルのサブセットのカウントをクエリする必要があります。建築の帽子をかぶった人は、パフォーマンスに懸念があると言っています。それらが正しいと仮定すると、インデックス付きビューを追加することでこの問題に対処できますか？

私が速くなりたいSQL：

SELECT COUNT(*) FROM [dbo].[Txxx] WHERE SomeName = 'ZZZZ'

また

SELECT COUNT_BIG(*) FROM [dbo].[Txxx] WHERE SomeName = 'ZZZZ'

テーブル：

CREATE TABLE [dbo].[Txxx](
    [Id] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
    [SomeName] [nvarchar](50) NOT NULL,
    [SomeGuid] [uniqueidentifier] NOT NULL
 CONSTRAINT [PK_Txxx] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)

意見：

CREATE view dbo.Vxxx
WITH SCHEMABINDING
AS
SELECT     SomeName, COUNT_BIG(*) AS UsedCount
FROM         dbo.Txxx
GROUP BY SomeName

索引：

CREATE UNIQUE CLUSTERED INDEX [IV_COUNT] ON [dbo].[Vxxx] 
(
    [SomeName] ASC
)
4

2 に答える 2

4

はい。ただし、クエリのコンパイル時にインデックス付きビューが考慮されるのはEnterpriseEditionのみです。非EEのインデックスを活用するには、ビューから直接選択し、NOEXPANDヒントを使用する必要があります。

NOEXPANDは、インデックス付きビューにのみ適用されます。インデックス付きビューは、一意のクラスター化インデックスが作成されたビューです。クエリにインデックス付きビューとベーステーブルの両方に存在する列への参照が含まれていて、クエリオプティマイザが、インデックス付きビューを使用するとクエリを実行するための最良の方法が提供されると判断した場合、クエリオプティマイザはビューのインデックスを使用します。この関数は、インデックス付きビューマッチングと呼ばれます。クエリオプティマイザによるインデックス付きビューの自動使用は、SQLServerの特定のエディションでのみサポートされています。

このようなインデックス付きビューでは、更新がロックされ、スコープ全体がロックされるため、書き込みの競合が発生することに注意してくださいSomeName。一度に1つのトランザクションのみが、。を使用して行を挿入、削除、または更新できSomeName = 'ZZZZ'ます。

于 2012-09-26T22:12:57.097 に答える
1

はい、そのインデックス付きビューは、その特定のクエリのパフォーマンスを確実に向上させます（Enterprise Editionを想定-Remusは、Enterpriseを使用していない場合にそれを利用する方法を説明しています）。

ただし、これは「無料」ではありません。インデックスは、すべてのDML操作で維持する必要があり、dbo.Txxxスペースを占有し（ただし、ベーステーブルよりもかなり少なくなります）、通常のテーブルにも影響する問題が発生します。 -断片化や（この場合はそれほどではないかもしれませんが）ページ分割など。

于 2012-09-26T22:10:52.227 に答える