基於一個不可能的參數，具有完全不同的性能的相同的查詢計劃？

我應該是相當敏捷的（我有一個DBA背景，我在優化不錯），並在幾乎所有情況下，它是一個即席查詢。然而，當我提供一個特定參數的查詢（用小於平均預期的結果集漂亮的選擇性值）tempdb的開始成長，當它運行的磁盤的死亡。基於一個不可能的參數，具有完全不同的性能的相同的查詢計劃？

這是對勞森AP系統的SQL Server 2005系統上一次性的報告，如果有人問津。

我已經研究針對高性能運行和非運行的高性能，而不僅僅是估計的查詢計劃，但實際的查詢計劃的查詢計劃，他們是完全相同的。我更新了統計信息，查詢計劃保持不變。唯一不同的是實際數據。

爲nonperformant組數據看起來奇怪... ID列是CHAR（9）和CHAR（22），左填充空格，然後填充零添加的良好措施。一個典型的ID值就像

' 00112'

......這很奇怪，但它是一個有效的字符（9），因此是合法的。這些列的索引很好，除了一個以外，所有情況都很好。

我想這個問題有對數據的工作指標做，雖然我看不出來。非查詢結果記錄的數量少於以秒爲單位返回結果的最大結果記錄的數量的一半。

我使用的查詢如下（這是針對勞森V9數據庫模式）：

insert into dbo.rptPayments with (tablock) 
    (
    VendorGroup, 
    VendorID, 
    VendorName, 
    ChargedToCompany, 
    ChargedToAccount, 
    ChargedToSubAccount, 
    InvoiceID, 
    PaymentAmount 
    ) 
select top 100 percent 
    vm.VENDOR_GROUP as VendorGroup, 
    rtrim(ltrim(vm.VENDOR)) as VendorID, 
    vm.VENDOR_VNAME as VendorName, 
    gm.NAME as ChargedToCompany, 
    dist.DIS_ACCOUNT as ChargedToAccount, 
    dist.DIS_SUB_ACCT as ChargedToSubAccount, 
    inv.INVOICE as InvoiceID, 
    dist.ORIG_TRAN_AMT as PaymentAmount 
from 
    dbo.APVENMAST vm with (nolock) 
inner join 
    dbo.APINVOICE inv with (nolock) 
    on inv.VENDOR = vm.VENDOR 
    and inv.VENDOR_GROUP = vm.VENDOR_GROUP 
inner join 
    dbo.APDISTRIB dist with (nolock) 
    on dist.COMPANY = inv.COMPANY 
    and dist.VENDOR = inv.VENDOR 
    and dist.INVOICE = inv.INVOICE 
inner join 
    dbo.APPAYMENT pay with (nolock) 
    on pay.COMPANY = inv.COMPANY 
    and pay.VENDOR = vm.VENDOR 
    and pay.INVOICE = inv.INVOICE 
    and pay.VENDOR_GROUP = inv.VENDOR_GROUP 
inner loop join 
    dbo.GLSYSTEM gm with (nolock, index(GLSSET1)) 
    on gm.COMPANY = dist.DIST_COMPANY 
where 
    vm.VENDOR_GROUP = @VendorGroup 
    and vm.VENDOR_STATUS = 'A' 
    and inv.INVOICE_DTE between '2009-09-01' and '2011-08-31' 
    and pay.VOID_SEQ = 0 
    and pay.CANCEL_SEQ = 0

...你可以看到，我使用了一些提示，強制查詢下來正確的道路......優化者正在做出一些非常糟糕的選擇。我期待20000 - 30000記錄的結果集。在引用表

架構可能會發現here.

定義，我已經建立了這個自定義指標如下：

CREATE NONCLUSTERED INDEX [tmpAPDISTRIB] ON [dbo].[APDISTRIB] 
(
    [COMPANY] ASC, 
    [VENDOR] ASC, 
    [INVOICE] ASC 
) 
INCLUDE ([DIST_COMPANY], 
[ORIG_TRAN_AMT], 
[DIS_ACCOUNT], 
[DIS_SUB_ACCT]) 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] 

CREATE NONCLUSTERED INDEX [tmpAPPAYMENT] ON [dbo].[APPAYMENT] 
(
    [COMPANY] ASC, 
    [VENDOR] ASC, 
    [INVOICE] ASC, 
    [VENDOR_GROUP] ASC 
) 
INCLUDE ([VOID_SEQ], 
[CANCEL_SEQ]) 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] 

CREATE NONCLUSTERED INDEX [tmpAPINVOICE] ON [dbo].[APINVOICE] 
(
    [VENDOR] ASC, 
    [VENDOR_GROUP] ASC, 
    [INVOICE_DTE] 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]

任何幫助或建議將是非常有用的。

UPDATE經順藤摸瓜，我發現從問題@VendorGroup記錄被存儲方式不同......顯然有可用的功能的AP分佈（由dbo.APDISTRIB表來表示），以支持「重複」與發票相同的發票號碼，導致我的加入笛卡爾產品，因爲我沒有加入這個專欄。沒有其他供應商組織正在使用此功能。

來源

2011-09-23 Jeremy Holovacs

爲什麼查詢有「TOP 100 PERCENT」？ @VendorGroup的實際問題價值是什麼？除了產出之外，它與其他產品有什麼不同？你是手動更新統計數據，自動更新還是根本不？ –

你可以發佈執行計劃嗎？ –

@AaronBertrand，百分之百的排名只是另一個試圖欺騙系統從頭開始的系統。我沒有想到它會起作用，但有時候改變一些無害的東西會刺激優化器的輪胎。 '@ VendorGroup'的有效值是CON，ROCK，SJR和其他一些值。 ROCK是一個給出問題的人。 –