2017-10-20 292 views
0

我有一個SQL查詢是花了很長時間根據參數檢查....SQL查詢需要很長的時間和參數檢查

查詢它本身是存儲過程的一部分用於搜索屏幕。基本上你用一大堆文本/組合框來填寫表單來搜索。我有多選組合框,將通過分隔字段的方式傳遞相同字段的多個值。

以下是查詢的削減版本,來說明我的問題......

select 
    o.id, 
    o.createdBy 
into 
    #results 
from 
    jmsTransOther o 
where 
    o.(WorkOrderId IN (SELECT intValue FROM dbo.fn_SplitInts(@WorkOrderIds, ',')) <strong>OR @WorkOrderIds = ''</strong>) 

我經常使用此參數檢查OR @WorkOrderIds = ''這基本上意味着,如果這是不是真的那麼執行的另一邊該聲明。

這在大多數情況下工作得很好,但由於某種原因,這個fn_SplitInts函數基本上將分隔列表轉換爲表格,然後執行「IN」語句需要很長時間。

該表格中有大約200,000條記錄 - 目前這大約需要40秒才能搜索。但是,如果我刪除了參數檢查,即OR @WorkOrderIds = '',那麼它不到一秒鐘。

我可以解決它,但只是想知道這裏發生了什麼....?

+0

這幾乎肯定是一個參數嗅探問題。簡短的解決方案是簡單地在存儲過程中添加「WITH RECOMPILE」。我建議你在一般的參數嗅探方面做一些研究,但是,只要你知道最近發生了什麼 –

+0

@ Nick.McDermaid沒有想到這一點。我之前有過這個問題。但是,當我在查詢窗口中單獨測試查詢時,我遇到了同樣的問題?現在這是否排除了參數嗅探問題? –

+0

編號任何客戶端應用程序(SSMS或Web應用程序)都可能引起參數嗅探 –

回答

0

我可能會建議這個提法:

select o.id, o.createdBy 
into #results 
from jmsTransOther o 
where o.WorkOrderId IN (SELECT intValue FROM dbo.fn_SplitInts(@WorkOrderIds, ',')) 
union all 
select o.id, o.createdBy 
from jmsTransOther o 
where @WorkOrderIds = ''; 

or可能是搞亂了的統計信息。 (我也會使用NULL而不是空字符串來表示「所有這些」。)

+0

不幸的是,我有大約6這些相同的參數檢查在哪裏條件,這將意味着這種解決方案將變得相當混亂的不同標準... –

+0

@GlenHong。 。 。只能回答你提出的問題。如果您有其他問題,請將其作爲*新問題。編輯這個問題只會導致服務器無效,這個問題可能會導致低估。 –

+0

那麼在最後一行有一個問題......我真的沒有看到這麼多的解決方案,因爲我可以解決它。我更加關注是什麼導致了這個問題......正如尼克美人魚指出他認爲是問題所在 –