3

以下に示すように、列とインデックスで構成される単純なテーブルがあります。

コラム

インデックス

これは、SQL データベース エンジン チューニング アドバイザーの推奨に従って作成したインデックスです。すべての列が含まれています。

CREATE NONCLUSTERED INDEX [_dta_index_PROPOSAL_PROCESS_12_13243102__K2_K7_K1_3_4_5_6_8_9_10] ON [dbo].[PROPOSAL_PROCESS]
(
    [PROPOSAL_ID] ASC,
    [IS_DELETED] ASC,
    [ID] ASC
)
INCLUDE (   [CREATOR_USER_ID],
    [CREATION_TIME],
    [LAST_UPDATER_USER_ID],
    [LAST_UPDATE_TIME],
    [CURRENT_PROPOSAL_OBJECT],
    [INTERFACTORING_XML],
    [OMDM_OUTPUT_XML]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

picture-1 でチェックされた列を追加すると、実行時間が大幅に増加します。私のテスト結果は次のとおりです。

前述の列のいずれも含めない場合。

SET STATISTICS IO ON
SET STATISTICS TIME ON
CHECKPOINT; 
GO 
DBCC DROPCLEANBUFFERS; 
GO  
DECLARE @DynamicFilterParam_000001 bit = 0,
        @DynamicFilterParam_000002 bit = null,
        @EntityKeyValue1 int = 4419;    
SELECT 
    [Extent1].[ID] AS [ID], 
    --[Extent1].[CURRENT_PROPOSAL_OBJECT] AS [CURRENT_PROPOSAL_OBJECT], 
    --[Extent1].[INTERFACTORING_XML] AS [INTERFACTORING_XML], 
    --[Extent1].[OMDM_OUTPUT_XML] AS [OMDM_OUTPUT_XML], 
    [Extent1].[PROPOSAL_ID] AS [PROPOSAL_ID], 
    [Extent1].[CREATOR_USER_ID] AS [CREATOR_USER_ID], 
    [Extent1].[CREATION_TIME] AS [CREATION_TIME], 
    [Extent1].[LAST_UPDATER_USER_ID] AS [LAST_UPDATER_USER_ID], 
    [Extent1].[LAST_UPDATE_TIME] AS [LAST_UPDATE_TIME], 
    [Extent1].[IS_DELETED] AS [IS_DELETED]
    FROM [dbo].[PROPOSAL_PROCESS] AS [Extent1]
    WHERE (([Extent1].[IS_DELETED] = @DynamicFilterParam_000001) ) AND ([Extent1].[PROPOSAL_ID] = @EntityKeyValue1);

(影響を受ける 54 行) テーブル 'PROPOSAL_PROCESS'。スキャン カウント 1、論理読み取り 58、物理読み取り 2、先読み読み取り 55、LOB 論理読み取り 0、LOB 物理読み取り 0、LOB 先読み読み取り 0。

(1 行が影響を受けます)

SQL Server 実行時間: CPU 時間 = 31 ミリ秒、経過時間 = 16 ミリ秒。 SQL Server の解析時間とコンパイル時間: CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。

SQL Server 実行時間: CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。

前のクエリの select 句に CURRENT_PROPOSAL_OBJECT を追加すると

(影響を受ける 54 行) テーブル 'PROPOSAL_PROCESS'。スキャン カウント 1、論理読み取り 58、物理読み取り 2、先読み読み取り 55、LOB 論理読み取り 0、LOB 物理読み取り 0、LOB 先読み読み取り 0。

(1 行が影響を受けます)

SQL Server 実行時間: CPU 時間 = 0 ミリ秒、経過時間 = 545 ミリ秒。 SQL Server の解析時間とコンパイル時間: CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。

前のクエリの select 句に INTERFACTORING_XML を追加すると

(影響を受ける 54 行) テーブル 'PROPOSAL_PROCESS'。スキャン カウント 1、論理読み取り 58、物理読み取り 2、先読み読み取り 55、LOB 論理読み取り 1822、LOB 物理読み取り 376、LOB 先読み読み取り 0。

(1 行が影響を受けます)

SQL Server 実行時間: CPU 時間 = 47 ミリ秒、経過時間 = 2415 ミリ秒。 SQL Server の解析時間とコンパイル時間: CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。

前のクエリの select 句に CURRENT_PROPOSAL_OBJECT を追加すると

(影響を受ける 54 行) テーブル 'PROPOSAL_PROCESS'。スキャン カウント 1、論理読み取り 58、物理読み取り 2、先読み読み取り 55、LOB 論理読み取り 5048、LOB 物理読み取り 944、LOB 先読み読み取り 0。

(1 行が影響を受けます)

SQL Server 実行時間: CPU 時間 = 47 ミリ秒、経過時間 = 6912 ミリ秒。 SQL Server の解析時間とコンパイル時間: CPU 時間 = 0 ミリ秒、経過時間 = 0 ミリ秒。

結局のところ、私は 6912 ミリ秒に直面しています。このひどいパフォーマンスの理由は何ですか?

いくつかのインデックスを作成できませんか? これは、大きなサイズの nvarchar を同じテーブルに配置することから発生した悪い設計の結果ですか?

前もって感謝します

編集:問題を再生成するためのスクリプトは次のとおりです。sql-fiddleで同じ問題を作成しようとしましたが、1行も挿入されませんでした。

編集 2: select 句にすべての列を含め、クエリが 2 行を返すようにする別の提案 Id を指定した場合、実行時間は通常約 100 ミリ秒のままです。クエリの実行時間は、返される行の増加に応じてますます悪化します。インデックスとの接続。

4

3 に答える 3