ASP.NET的SP性能不佳

Question

我有一個處理排序，過濾和分頁（使用Row_Number）和一些時髦技巧的存儲過程:) SP運行在一個具有〜140k行的表上。

整件事情效果很好，至少前幾頁是超快的。 但是，如果我嘗試導航到更高的頁面（例如，前往10k的最後一頁），整個事情就會停頓並導致SQL超時錯誤。

如果我運行相同的查詢，使用工作室經理查詢窗口內同一PARMS，響應頁碼我傳遞的瞬間不論。

目前，它的測試代碼，簡直是綁定到一個ASP：Datagrid中使用.NET 3.5

的SP看起來是這樣的：

BEGIN 
WITH Keys 
AS (
SELECT 
    TOP (@PageNumber * @PageSize) ROW_NUMBER() OVER (ORDER BY JobNumber DESC) as rn 
    ,P1.jobNumber 
    ,P1.CustID 
    ,P1.DateIn 
    ,P1.DateDue 
    ,P1.DateOut 
FROM vw_Jobs_List P1 
WHERE 
    (@CustomerID = 0 OR CustID = @CustomerID) AND 
    (JobNumber LIKE '%'+@FilterExpression+'%' 
    OR OrderNumber LIKE '%'+@FilterExpression+'%' 
    OR [Description] LIKE '%'+@FilterExpression+'%' 
    OR Client LIKE '%'+@FilterExpression+'%')  
ORDER BY P1.JobNumber DESC),SelectedKeys 
AS (
SELECT 
    TOP (@PageSize)SK.rn 
    ,SK.JobNumber 
    ,SK.CustID 
    ,SK.DateIn 
    ,SK.DateDue 
    ,SK.DateOut 
FROM Keys SK 
WHERE SK.rn > ((@PageNumber-1) * @PageSize) 
ORDER BY SK.JobNumber DESC) 

SELECT 
    SK.rn 
    ,J.JobNumber 
    ,J.Description 
    ,J.Client 
    ,SK.CustID 
    ,OrderNumber 
    ,CAST(DateAdd(d, -2, CAST(isnull(SK.DateIn,0) AS DateTime)) AS nvarchar) AS DateIn 
    ,CAST(DateAdd(d, -2, CAST(isnull(SK.DateDue,0) AS DateTime)) AS nvarchar) AS DateDue 
    ,CAST(DateAdd(d, -2, CAST(isnull(SK.DateOut,0) AS DateTime)) AS nvarchar) AS DateOut 
    ,Del_Method 
    ,Ticket# 
    ,InvoiceEmailed 
    ,InvoicePrinted 
    ,InvoiceExported 
    ,InvoiceComplete 
    ,JobStatus 
FROM SelectedKeys SK 
JOIN vw_Jobs_List J ON j.JobNumber=SK.JobNumber 
ORDER BY SK.JobNumber DESC 
END 

而且它通過

sp_jobs (PageNumber,PageSize,FilterExpression,OrderBy,CustomerID) 

稱爲

例如

sp_Jobs '13702','10','','JobNumberDESC','0' 

任何人都可以闡明什麼可能是在SQL查詢窗口並執行一個數據集的一個asp.net頁面之間的性能差異巨大的原因任何光線？

Answer 1

時退房「WITH RECOMPILE」選項

http://www.techrepublic.com/article/understanding-sql-servers-with-recompile-option/5662581

Answer 2

我遇到了類似的問題，其中存儲過程的執行計劃將很好地工作一段時間，但隨後得到一個新的計劃，因爲選項更改。因此，它將針對一種情況進行「優化」，然後針對另一種選擇執行「表格掃描」。這是我過去試過的：

1. 重新執行存儲過程來計算一個新的執行計劃，然後留意它。
2. 將存儲過程分解爲每個選項的單獨存儲過程，以便對其進行優化，然後整個存儲過程只需調用每個「優化」的存儲過程。
3. 將記錄帶入一個對象，然後在代碼中執行所有「怪異的技巧」，然後它給你「緩存」結果的選項。

很明顯，選項＃2和＃3比選項＃1好。老實說，在大多數情況下，選項＃3正成爲最佳選擇。

我剛剛有另一個選項4.你可以不用在一個查詢中執行你的「內部選擇」，你可以把你的內部選擇的結果放到臨時表中，然後加入這些結果。如果可能的話，我仍會推薦＃3選項，但我知道有時您只需要繼續使用存儲過程，直到它「有效」。

祝你好運。