調慢SQL查詢

我得到了一個在我的SQL Server上運行的應用程序，該應用程序開始減慢特定的任務。我運行了SQL Profiler並注意到以下查詢需要花費大量的時間（1-2分鐘）。 我無權訪問代碼來更改查詢。
有什麼我可以調整/更改數據庫中？以下聲明中的PC10000表格大約爲。 119000條記錄。我也有執行計劃。調慢SQL查詢

SELECT TOP 25 
    zProjectID, zTaskID, zTransactionNumber, zTransactionDate, zUserID, 
    zCostCategoryDDL, zCostCategoryString, zSubCostCategory, zSubCostCategoryString, 
    zDepartmentID, zJournalEntry, zPostingDate, zSalesPostingDate, zPeriodNumber, 
    zTransactionDescription, zBillingDescriptionLine1, zBillingDescriptionLine2, 
    zBillingDescriptionLine3, zBillingDescriptionLine4, zSalesAccountIndex, 
    zSalesAccountString, zDistDocumentTypeDDL, zDistDocumentNumber, zDistSequenceNumber, 
    zSalesDocumentTypeDDL, zSalesDocumentNumber, zSalesLineNumber, zDistHistoryYear, 
    zSeriesDDL, zSourceDoc, zWebSource, zOrigDocumentNumber, zOrigDocumentDate, 
    zOrigID, zOrigName, zExpenseStatusDDL, zApprovalUserIDCost, zAccountIndex, 
    zAccountNumberString, zBillingStatusDDL, zApprovalUserIDBilling, zBillingWorkQty, 
    zBillingWorkAmt, zQty, zQtyBilled, zUnitCost, 
    zUnitPrice, zRevenueAmt, zOriginatingRevenueAmt, zCostAmtEntered, zCostAmt, 
    zOriginatingCostAmt, zPayGroupID, zPayrollStatusDDL, zTotalTimeStatusDDL, 
    zEmployeeID, zHoursEntered, zHoursPaid, zPayRecord, zItemID, zItemDescription, 
    zUofM, zItemQty, zBurdenStatusDDL, zUserDefinedDate, zUserDefinedDate2, 
    zUserDefinedString, zUserDefinedString2, zUserDefinedCurrency, 
    zUserDefinedCurrency2, zNoteIndex, zImportType, DEX_ROW_ID 
FROM 
    DBServer.dbo.pc10000 
WHERE 
    (zDistDocumentNumber in 
     (select cast(JRNENTRY as varchar(20)) 
      from DBServer..GL10001 
      where BACHNUMB = 'PMCHK00004283') 
    or zSalesDocumentNumber in 
     (select cast(JRNENTRY as varchar(20)) 
      from DBServer..GL10001 
      where BACHNUMB = 'PMCHK00004283')) 
ORDER BY 
    zProjectID ASC ,zTaskID ASC ,zTransactionNumber ASC

alt text

來源

2009-07-09 JapNolt

你可以讓你沒有訪問代碼更明確的問題，即粗體。 – pjp 2009-07-09 14:50:00

修改爲強調他無法更改查詢的事實。 – 2009-07-09 14:51:24

爲什麼不能編輯代碼。查詢是否通過存儲過程運行？ – pjp 2009-07-09 14:57:20

您看到的最大問題是由於缺乏合適的索引。您可以看到，因爲執行計劃中存在表掃描。

表掃描打擊性能，因爲它們表示正在掃描整個表以匹配查詢中給定子句的數據。

我建議你上BACHNUMB在GL10001

您也可以嘗試在PC10000上zDistDocumentNumber和zSalesDocumentNumber索引添加索引，但我覺得GL10001指標是最主要的一個。

與其他技術相比，「IN」子句通常相當昂貴，但由於您無法更改查詢本身，因此您無能爲力。

毫無疑問，你需要添加合適的索引

來源

2009-07-09 14:43:01 AdaTheDev

查詢是做對GL10001表2次表掃描。從快速查看查詢（這有點難以閱讀），我會看看您是否在BACHNUMB列上有索引。

來源

2009-07-09 14:41:44

你可以重寫這些子選擇的加盟，並添加索引到GP01..GL10001上BACHNUMB和JRNENTRY

來源

2009-07-09 14:42:14

既然你無法改變的查詢，你能做的最好的事情是確保您在用於連接（和子查詢）的列上有索引。如果你能想到一個更好的查詢計劃，你可以將它提供給SQL Server，而不是讓它自己計算（這是非常罕見的情況）。

來源

2009-07-09 14:42:30

的執行計劃顯示很清楚，實際上定位行是什麼把所有的時間（沒有繁瑣的書籤查找，或聚合/重新安排任務），所以它的相當肯定會成爲索引問題。將表掃描懸停在執行計劃中，並檢查工具提示中的「對象」，以查看正在使用哪些列。看到它們被索引。

您可能還想運行跟蹤以採樣一些實時數據，並將其提供給數據庫調整顧問。

來源

2009-07-09 14:45:00

更換或與UNION兩個所有查詢這應該讓這些線軸的拍攝

即像這樣的東西

SELECT .... 

(zDistDocumentNumber in 
    (select cast(JRNENTRY as varchar(20)) 
     from DBServer..GL10001 
     where BACHNUMB = 'PMCHK00004283') 

UNION ALL 

SELECT ... 

zSalesDocumentNumber in 
    (select cast(JRNENTRY as varchar(20)) 
     from DBServer..GL10001 
     where BACHNUMB = 'PMCHK00004283'))

來源

2009-07-09 14:48:16 pjp

除了添加索引，一旦運行該查詢，您也可以將IN語句轉換爲EXISTS ...沿着這些線：

SELECT TOP 25 .... 
FROM GP01.dbo.pc10000 parent 
WHERE EXISTS 
    (
    SELECT child.* 
    FROM GP01..GL10001 child 
    WHERE BACHNUMB = 'PMCHK00004283' 
     and parent.zDistDocumentNumber = child.JRNENTRY 
    ) 
    OR EXISTS 
    (
    SELECT child2.* 
    FROM GP01..GL10001 child2 
    WHERE BACHNUMB = 'PMCHK00004283' 
     and parent.zSalesDocumentnumber = child2.JRENTRY 
    ) 
ORDER BY zProjectID ASC ,zTaskID ASC ,zTransactionNumber ASC

來源

2009-07-09 15:06:41

回答

相關問題