web-dev-qa-db-ja.com

高IO、よりパフォーマンスの高いソリューションはありますか？

以前は実行に数分かかっていたクエリが6秒ほどかかるようになりましたが、1日に数千回実行されるため、より高速にしたいと考えています。

https://www.brentozar.com/pastetheplan/?id=SJMLjJOWm

このクエリ中のI/Oの99％以上が1つのクラスター化インデックススキャンで発生しているようです。

これは正常ですか？このクエリは、それだけのためにインデックスを追加することを正当化するのに十分に使用されているので、ここで明らかなものがないかどうか知りたいのですが。

Dbo.GROUP_CONCAT関数は、このgithubアセンブリプロジェクトから取得されます https://github.com/orlando-colamatteo/ms-sql-server-group-concat-sqlclr

SpecsProdテーブルの定義：

CREATE TABLE [dbo].[SpecsProd](
    [ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
    [specsID_1] [int] NULL,
    [specsID_2] [int] NULL,
    [specID] [int] NOT NULL,
    [productID] [int] NOT NULL,
    [SpecValue_1] [varchar](1000) NULL,
    [SpecValue_2] [varchar](1000) NULL,
    [Flock] [bit] NULL,
    [SpecValue_1a] [varchar](2000) NULL,
    [SpecValue_2a] [varchar](2000) NULL,
 CONSTRAINT [PK_SpecsProd] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[SpecsProd] ADD  CONSTRAINT [DF_SpecsProd_Flock]  DEFAULT ((0)) FOR [Flock]
GO

ALTER TABLE [dbo].[SpecsProd]  WITH NOCHECK ADD  CONSTRAINT [FK_SpecsProd_Products] FOREIGN KEY([productID])
REFERENCES [dbo].[Products] ([Id_product])
NOT FOR REPLICATION 
GO

ALTER TABLE [dbo].[SpecsProd] CHECK CONSTRAINT [FK_SpecsProd_Products]
GO

99％のI/Oを使用するクラスター化インデックスは[PK_SpecsProd]（最初のインデックス）です。他のインデックスもそこにあります。

    ALTER TABLE [dbo].[SpecsProd] ADD  CONSTRAINT [PK_SpecsProd] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [IX_ProdID_SpecID] ON [dbo].[SpecsProd]
(
    [productID] ASC,
    [specID] ASC
)
INCLUDE (   [ID],
    [SpecValue_1],
    [SpecValue_2]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [IX_SpecID_ProductID] ON [dbo].[SpecsProd]
(
    [specID] ASC,
    [productID] ASC
)
INCLUDE (   [SpecValue_1],
    [SpecValue_2]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [product] ON [dbo].[SpecsProd]
(
    [productID] ASC
)
INCLUDE (   [specID],
    [SpecValue_1],
    [SpecValue_2]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [specId_inc_prodID_specvalue1] ON [dbo].[SpecsProd]
(
    [specID] ASC
)
INCLUDE (   [productID],
    [SpecValue_1]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [specsID] ON [dbo].[SpecsProd]
(
    [specsID_1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
GO

カラム数が最も多いテーブル（スペックテーブル）のギネスレコード候補の1つ

CREATE TABLE [dbo].[Specs](
    [ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
    [Id_spec] [int] NOT NULL,
    [CatId] [int] NOT NULL,
    [sect] [varchar](50) NULL,
    [spec] [varchar](75) NOT NULL,
    [format] [varchar](50) NULL,
    [unit] [varchar](20) NULL,
    [definition] [ntext] NULL,
    [ordre] [int] NOT NULL,
    [Id_langue] [int] NOT NULL,
    [FormField] [varchar](50) NULL,
    [List] [varchar](max) NULL,
    [filterField] [bit] NOT NULL,
    [isFilter] [bit] NOT NULL,
    [isCollectionFilter] [bit] NOT NULL,
    [quickViewSubcats] [varchar](250) NULL,
    [width] [bit] NOT NULL,
    [height] [bit] NOT NULL,
    [depth] [bit] NOT NULL,
    [weight] [bit] NOT NULL,
    [DateCreation] [datetime] NOT NULL,
    [DateModification] [datetime] NOT NULL,
    [quickView] [bit] NOT NULL,
    [Visible] [bit] NULL,
    [compare] [bit] NOT NULL,
    [priceTag] [bit] NOT NULL,
    [ConvertionRate] [varchar](20) NULL,
    [ConvertionUnit] [varchar](20) NULL,
    [searchableLabel] [bit] NULL,
    [searchableValue] [bit] NULL,
 CONSTRAINT [PK_Specs] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_filter]  DEFAULT ((0)) FOR [filterField]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_isFilter]  DEFAULT ((0)) FOR [isFilter]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_isCollectionFilter]  DEFAULT ((0)) FOR [isCollectionFilter]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_width]  DEFAULT ((0)) FOR [width]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_height]  DEFAULT ((0)) FOR [height]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_depth]  DEFAULT ((0)) FOR [depth]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_weight]  DEFAULT ((0)) FOR [weight]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_DateCreation]  DEFAULT (getdate()) FOR [DateCreation]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_DateModification]  DEFAULT (getdate()) FOR [DateModification]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_quickView]  DEFAULT ((0)) FOR [quickView]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_compare]  DEFAULT ((0)) FOR [compare]
GO

ALTER TABLE [dbo].[Specs] ADD  CONSTRAINT [DF_Specs_priceTag]  DEFAULT ((0)) FOR [priceTag]
GO
sql-servert-sqlsql-server-2016execution-plan
6
A_V
  1. 待機統計ではASYNC_NETWORK_IOがボトルネックです。

実際の計画では、経過時間の約87％が結果をクライアントに送信するために費やされます。アプリケーションコードを変更するか、送り返すデータの量を減らす必要がある場合があります。

<WaitStats>
  <Wait WaitType="CMEMTHREAD" WaitTimeMs="33" WaitCount="86" />
  <Wait WaitType="SESSION_WAIT_STATS_CHILDREN" WaitTimeMs="1029" WaitCount="55" />
  <Wait WaitType="LATCH_EX" WaitTimeMs="2796" WaitCount="308" />
  <Wait WaitType="ASYNC_NETWORK_IO" WaitTimeMs="3083" WaitCount="144" />
</WaitStats>
<QueryTimeStats ElapsedTime="3542" CpuTime="7247" />
  1. MAXDOP 22はSELECTクエリに対してかなり高いです。

このクエリを異なるMAXDOP値でテストして、22が本当に最良の選択であることを確認しましたか？推測しなければならないのであれば、ソケットあたり12コアの2ソケットサーバーがあると思います。おそらく、MAXDOPが何らかの理由でインスタンスレベルで22に設定されています。私はそれを計画のスレッド情報に基づいています：

<ThreadStat Branches="4" UsedThreads="88">
  <ThreadReservation NodeId="0" ReservedThreads="24" />
  <ThreadReservation NodeId="1" ReservedThreads="24" />
  <ThreadReservation NodeId="2" ReservedThreads="16" />
  <ThreadReservation NodeId="3" ReservedThreads="24" />
</ThreadStat>

NUMAノード2のスケジューラーは他のスケジューラーより少ないか、サーバーにはそれぞれ12個のスケジューラーの2つのソケットがあるか、サーバーにはそれぞれ6個のスケジューラーの4つのソケットがあるか、手動のソフトNUMAがセットアップされました。 MAXDOPの一般的な提案は、ハードNUMAノードあたりのコアの物理数よりも少ないものを使用することです。

以上のことから、テストを行うために技術的な詳細をすべて理解する必要はありません。異なるMAXDOPでテストしてみて（必ず2回以上テストを実行してください）、それが役立つかどうかを確認してください。

  1. 必要に応じて、プラン内の3つのテーブルすべてについてIOを減らすことができます。

クエリプランを確認しただけで、既にあるインデックス定義は確認していません。 SpecsProdが最大のテーブルのようです。必要な列だけにカバーインデックスを定義できます。探索することはできませんが、クエリで使用される3つの列のみを含む非クラスター化インデックスはクラスター化インデックスよりも小さいため、IOは少なくなります。

Productsテーブルは、2番目に高いIOコストです。すでにクラスター化インデックスで注文していますが、クラスター化インデックスのサイズはすべてのサイズです。テーブル内のデータ。クラスター化されたキー列だけに非クラスター化インデックスを作成してIOを減らすことができます。DESCの順序で作成して、スキャンを並列処理に適格にすることもできますが、 TOP式により、実際には違いが出ます。

Specsにはすでにカバリングインデックスがありますが、フィルターはシーク述語ではなく述語で評価されます。インデックスを変更するか、キー列を正しい順序で新しく作成すると、スキャンの代わりにシークを実行できるはずです。

4
Joe Obbish

コードを見るだけで、次の2つのことをお勧めします

1番目：次のサブクエリを保持する一時テーブルを作成する

WHERE sp.productID IN (
            SELECT TOP 25000 id_product
            FROM products
            ORDER BY 1 DESC
            )

つまり、私はやります

create table #t (id_product int primary key);
insert into #t (id_product)
SELECT TOP 25000 id_product
FROM products
ORDER BY 1 DESC;

次に、元のWHERE句を

WHERE sp.productID IN (
                SELECT id_product
                FROM #t )

2番目：where句のlower（）関数を削除します。データベースの照合で大文字と小文字が区別されない場合（CS）、lower（）関数は必要ありません。データベースがCSの場合は、条件を書き直すことができます。

例えば、

lower(sp.SpecValue_1) = ('y')

次のように書き直すことができます

sp.SpecValue_1 in ('y', 'Y')

このアプローチから始めて、これによりパフォーマンスが向上するかどうかを確認できます。フルスキャンでも統計を更新することを忘れないでください。

それでも要件を満たさない場合は、@ Joe Obbishが述べたような他のアプローチを検討してください。

3
jyao