SQL Server 2008查詢緩慢由NewRelic在其中一個具有適當索引的表之一上報告

Question

我們使用ASP.NET MVC與nHibernate從SQL Server 2008中獲取數據。最近，我們開始使用New Relic並注意到一個表（with大約有600萬行和1000萬行）正在花費更多的時間用簡單的查詢返回數據（沒有任何連接）

我們已經驗證索引存在於必填字段中，並且數據庫維護作業正在運行正常。

這裏是表結構

CREATE TABLE [dbo].[OfferTable](
[OfferID] [int] IDENTITY(1,1) NOT NULL, 
[Offer] [nvarchar](50) NOT NULL, 
[IssueDate] [datetime] NOT NULL, 
[ExpiryDate] [datetime] NOT NULL, 
[UserId] [nvarchar](255) NULL 
PRIMARY KEY CLUSTERED 
(
[OfferID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY] 
) ON [PRIMARY] 

IF NOT EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(N'[dbo]. [OfferTable]') AND name = N'IX_OfferTable_Offer') 
CREATE UNIQUE NONCLUSTERED INDEX [IX_OfferTable_Offer] ON [dbo].[OfferTable] 
(
    [Offer] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 

NHibernate的是生成下面的查詢來從數據庫行（從SQL事件探查了），顯示指數尋求發售現場，然後重點

exec sp_executesql N'select offertable0_.OfferId as OfferId22_, offertable0_.Offer as Offer_22, offertable0_.IssueDate as IssueDate22_, offertable0_.ExpiryDate as ExpiryDate22_,offertable0_.UserId as UserId22_ from OfferTable offertable0_ where (offertable0_.Offer is null) and (@p0 is null) or offertable0_.Offer=@p0',N'@p0 nvarchar(4000)',@p0=N'Someoffer' 

查詢執行計劃在OfferID（聚簇索引）後面跟隨嵌套循環查找

SET SET STATISTICS IO ON的命令給出以下輸出

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'OfferTable'. Scan count 0, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

根據上面的NewRelic查詢是非常不穩定的，取其中600毫秒到29300毫秒之間的任何地方，這是不可接受的。直接從SQL Management Studio執行相同的查詢時根本沒有時間。

即使NewRelic報告此查詢的緩慢26,800毫秒。

SELECT offertable_.OfferId AS col_0_0_ FROM OfferTable offertable_ WHERE offertable_.OfferId=@p0 

我們能夠得到DBCC SHOW_STATISTICS分期環境，因爲我們不必直接訪問數據庫。

Name        Updated    Rows  Rows Sampled Steps Density Average key length String Index Filter Expression Unfiltered Rows 
--------------------------------- -------------------- --------- ------------- ------ -------- ------------------ ------------ -------------------- -------------------- 
PK__OfferTab__8EBCF0B1762C88DA Feb 17 2014 11:47PM 6471738 87058   196 1  4     NO   NULL     6471738 


All density Average Length Columns 
------------- -------------- --------------- 
2.51234E-07 4    OfferId 

RANGE_HI_KEY RANGE_ROWS EQ_ROWS  DISTINCT_RANGE_ROWS AVG_RANGE_ROWS 
------------ ------------- ------------- -------------------- -------------- 
2077   0    1    0     1 
254978  33824.68  1    33823    1.000041 
255503  38071.39  1    524     72.65533 
425848  18998.45  1    18998    1 
572688  38071.39  1    38061    1.000283 
573083  28534.92  1    394     72.42365 
808660  38071.39  1    38061    1.000283 
865309  38071.39  1    38061    1.000283 
1466077  38071.39  1    38061    1.000283 
1466464  28534.92  1    386     73.92466 
1491230  38071.39  1    24765    1.537306 
1703369  18998.45  1    18998    1 

    ...... 


72632182  38071.39  1    38061    1.000283 
72632801  38071.39  1    618     61.6042 
72633595  38071.39  1    793     48.00932 
72635990  38071.39  1    2394     15.90284 
72647229  38071.39  1    11238    3.387738 
72647764  33973.69  1    534     63.62114 
72647766  0.9999998  1    1     1 


Name     Updated    Rows  Rows Sampled Steps Density  Average key length String Index Filter Expression Unfiltered Rows 
-------------------- -------------------- -------- ------------- ------ ------------- ------------------ ------------ ------------------ -------------------- 
IX_OfferTable_Offer Feb 17 2014 12:12AM 6694454 94967   195 1    60     YES   NULL    6694454 

All density Average Length Columns 
------------- -------------- ---------------- 
1.493774E-07 56    Offer 
1.493774E-07 60    Offer, OfferId 

RANGE_HI_KEY          RANGE_ROWS EQ_ROWS  DISTINCT_RANGE_ROWS AVG_RANGE_ROWS 
-------------------------------------------------- ------------- ------------- -------------------- -------------- 
//+7ubDjuOYu54oCOmn9yqoSaGY=      0    1    0     1 
/EiSLpejJg0iL3CIWpUwpHrKuN0=      32068.48  1    32068    1 
/Vdj7sd2XQYqH1fULVIjcvEKpNk=      54177.36  1    54138    1.000732 
+ATAAsm2GiZT8p6nq5PcoKP6WwM=      36094.7  1    36091    1.000089 
+ijb5mACGIixMdHwZ7bbN8d3wPE=      27053.36  1    27053    1 
+tIz35UIZ+5lMJAVJIloZ/UNBks=      36094.7  1    36091    1.000089 
06PLbtzHQ5d0011ruV3JKngyHX4=      36094.7  1    36091    1.000089 
0j9ZQAfUIfmuGmWnhvY2dDzyjgo=      36094.7  1    36091    1.000089 
0rDVT9rzqhHioz7DEFWs1surUr0=      27053.36  1    27053    1 
11ybw3Kws7ral/jxwmGvhcPqLSA=      36094.7  1    36091    1.000089 
1KEbJtyPiSI4+uyqipqU8TzFvLM=      45136.03  1    45115    1.000474 
1VnZxvlS1zb7TvQYHaF1NLz+X/Y=      36094.7  1    36091    1.000089 
26qVdhVKpWdPnkc0F1cpPhCxZE8=      27053.36  1    27053    1 
2joJSKCwIdoOHuiXu3nh+TeugGU=      36094.7  1    36091    1.000089 

..... 

YCRN93l3z9kZq9O8XmhTkfAc4t0=      45136.03  1    45115    1.000474 
YJpsDBYjGsM8E00Qso5jA2pEDvQ=      45136.03  1    45115    1.000474 
YqYLAWj3RAy1Eds1U5AJ3v6LyDI=      45136.03  1    45115    1.000474 
yxwmZJ4u++qKMFUZ3BLuRUVEECo=      45136.03  1    45115    1.000474 
Z6qEakF5+YM1ufMQud2tnSWbPXs=      45136.03  1    45115    1.000474 
ZF9irQvOCQRkt2s4Af7AftxHF2w=      45136.03  1    45115    1.000474 
ZLWmCLRC4tfKQ721jJRXB2WrE2s=      45136.03  1    45115    1.000474 
zsl5/65fRzNsVrHwRmB3Ta29e94=      45136.03  1    45115    1.000474 
ZZZHu1NznjtILSTYu/6jp5CK0mY=      48455.89  1    48428    1.00058 

我們還使用數據庫引擎優化顧問，其中建議與包括（包括指數）

請誰能幫助我理解爲什麼是NewRelic的報告查詢緩慢的新指標？與nHibernate有關嗎？應該使用覆蓋指標，爲什麼？

感謝提前:)

Answer 1

應的標準是(@p0 is null or offertable0_.Offer=@p0')而不是(@p0 is null) or offertable0_.Offer=@p0'？解決這個問題應該可以顯着提高參數爲空時的性能。查詢速度慢的一個常見原因是該列是varchar，但NHibernate提供了一個nvarchar參數，但在這裏似乎不是這種情況。

如果您經常選擇使用優惠條件，那麼索引可能是一個很大的幫助。但由於主鍵SELECT offertable_.OfferId AS col_0_0_ FROM OfferTable offertable_ WHERE offertable_.OfferId=@p0的查詢展示相同的問題，我懷疑你有一個不同的根本原因。