在Axapta數據庫上查詢時的性能問題

我在我們的Axapta數據庫上編寫了一個查詢並重寫了它一百次，但問題仍然存在。它表現非常糟糕。 15分鐘後，仍然沒有結果，幾乎將服務器關閉。在Axapta數據庫上查詢時的性能問題

任何想法如何改善這種說法是非常受歡迎的。

SELECT 
    J.INVOICEID, 
    T.AMOUNTCUR, 
    T.RECID, 
    T.ACCOUNTNUM, 
    CASE WHEN O.DATAAREAID IS NULL THEN 0 ELSE 1 END hasOpenTrans, 
    CASE WHEN P.DATAAREAID IS NULL THEN 0 ELSE 1 END hasPayment 
FROM 
    CUSTINVOICEJOUR J 
    LEFT JOIN CUSTTRANS T ON 
    T.DATAAREAID = J.DATAAREAID AND 
    T.INVOICE = J.INVOICEID AND 
    T.ACCOUNTNUM = J.INVOICEACCOUNT AND 
    T.TRANSDATE = J.INVOICEDATE 
    LEFT JOIN (
    SELECT 
     DATAAREAID, 
     REFRECID, 
     ACCOUNTNUM 
    FROM 
     CUSTTRANSOPEN 
    GROUP BY 
     DATAAREAID, 
     REFRECID, 
     ACCOUNTNUM 
    HAVING 
     COUNT(*) > 0) O ON 
     O.DATAAREAID = T.DATAAREAID AND 
     O.REFRECID = T.RECID AND 
     O.ACCOUNTNUM = T.ACCOUNTNUM 
    LEFT JOIN (
    SELECT 
     S.DATAAREAID, 
     S.TRANSCOMPANY, 
     S.TRANSRECID, 
     S.ACCOUNTNUM 
    FROM CUSTSETTLEMENT S 
     INNER JOIN CUSTTRANS C ON 
     C.DATAAREAID = S.DATAAREAID AND 
     C.RECID = S.OFFSETRECID AND 
     C.TRANSTYPE IN (0, 8, 15) AND 
     S.CANBEREVERSED = 1 
    GROUP BY 
     S.DATAAREAID, 
     S.TRANSRECID, 
     S.TRANSCOMPANY, 
     S.ACCOUNTNUM 
    HAVING 
     SUM(S.SETTLEAMOUNTCUR) > 0) P ON 
     P.DATAAREAID = T.DATAAREAID AND 
     P.TRANSRECID = T.RECID AND 
     P.ACCOUNTNUM = T.ACCOUNTNUM AND 
     P.TRANSCOMPANY = T.DATAAREAID 
WHERE 
    J.DATAAREAID = '011' AND 
    J.INVOICEDATE >= '2014-06-01'

，因爲它可能關係：這裏所涉及的表中的現有索引：

CUSTINVOICEJOUR 
Index Name    Columns              Clustered Primary Key Unique 
I_062INVOICEACCOUNTIDX DATAAREAID, INVOICEACCOUNT, INVOICEDATE      False  False   False 
I_062INVOICENUMIDX  DATAAREAID, INVOICEID, INVOICEDATE, NUMBERSEQUENCEGROUP, RECID True  False   True 
I_062ORDERACCOUNTIDX  DATAAREAID, ORDERACCOUNT, INVOICEDATE       False  False   False 
I_062PARMIDX    DATAAREAID, PARMID            False  False   False 
I_062RECID    DATAAREAID, RECID            False  True   True 
I_062SALESIDDATEIDX  DATAAREAID, SALESID, REFNUM, INVOICEDATE      False  False   False 
I_062VATNUMIDX   DATAAREAID, VATNUM            False  False   False 

CUSTTRANS 
Index Name    Columns         Clustered Primary Key Unique 
I_078ACCOUNTDATEIDX  DATAAREAID, ACCOUNTNUM, TRANSDATE   True  False   False 
I_078BILLOFEXCHANGEIDX DATAAREAID, BILLOFEXCHANGEID    False  False   False 
I_078INVACCOUNTDATEIDX DATAAREAID, INVOICE, ACCOUNTNUM, TRANSDATE False  False   False 
I_078INVOICEACCOUNTIDX DATAAREAID, INVOICE, ACCOUNTNUM   False  False   False 
I_078PAYMIDDATEIDX  DATAAREAID, PAYMID, TRANSDATE    False  False   False 
I_078RECID    DATAAREAID, RECID       False  True   True 
I_078VOUCHERDATEIDX  DATAAREAID, VOUCHER, TRANSDATE    False  False   False 

CUSTTRANSOPEN 
Index Name   Columns       Clustered Primary Key Unique 
I_865ACCOUNTDATEIDX DATAAREAID, ACCOUNTNUM, TRANSDATE True  False   False 
I_865RECID   DATAAREAID, RECID     False  True   True 
I_865REFRECIDX  DATAAREAID, REFRECID    False  False   False 

CUSTSETTLEMENT 
Index Name      Columns                Clustered Primary Key Unique 
I_075OFFSETCOMPANYRECTRANSREC7 DATAAREAID, OFFSETCOMPANY, OFFSETRECID, TRANSRECID, SETTLEMENTGROUP False  False   False 
I_075OFFSETVOUCHERIDX   DATAAREAID, OFFSETTRANSVOUCHER          False  False   False 
I_075RECID      DATAAREAID, RECID              False  True   True 
I_075SETTLEMENTGROUPIDX   DATAAREAID, SETTLEMENTGROUP           False  False   False 
I_075TRANSINDEX     DATAAREAID, TRANSRECID, TRANSDATE          True  False   False

而且表的大小可能無關緊要，或者至少給人的記錄數的想法，我「M處理：

CUSTINVOICEJOUR 
DATAAREAID  Nbr 
011   1513668 
012    2 
ash   355735 
bar   268795 
euk   692242 
hlm   866154 
lil   136163 
prv    3180 

CUSTTRANS 
DATAAREAID  Nbr 
011   2383870 
012    4 
ash   428161 
bar   367620 
bol    45 
euk   630029 
hlm   1377005 
lil   167405 
prv    4148 

CUSTTRANSOPEN 
DATAAREAID Nbr 
011   6119 
012    4 
ash   5845 
bar   1876 
bol   29 
euk   8077 
hlm   2426 
lil   2173 
prv   190 

CUSTSETTLEMENT 
DATAAREAID  Nbr 
011   2469546 
ash   462982 
bar   415329 
bol    18 
euk   684421 
hlm   1419857 
lil   178551 
prv    4325

來源

2014-07-09 Roebie

能告訴你的執行路徑：從這個地方

執行計劃？只是通過查看腳本來嘗試猜測正在使用的索引是相當困難的。我們可以猜測，但看到一個執行計劃會希望更容易看到會發生什麼。 – SchmitzIT

Axapta似乎是一個很SHOUTY的數據庫。 – podiluska

您應該在AX內部執行此查詢...更容易，並且不會跳過業務更改。 –

不知道更多關於執行計劃，或各列的數據selectivity，並考慮到該查詢，您發佈的指標，有米ight值得嘗試在表格上創建覆蓋索引。

在查詢看一眼就使我參與（主要利用一切參與WHERE條款列或JOIN表如下指標：

CUSTINVOICEJOUR - DATAAREAID, INVOICEID, NVOICEACCOUNT, INVOICEDATE, RECID, ACCOUNTNUM 
CUSTTRANS - DATAAREAID, INVOICE, ACCOUNTNUM, TRANSDATE, RECID 
CUSTTRANSOPEN - DATAAREAID, REFRECID, ACCOUNTNUM 
CUSTSETTLEMENT - DATAAREAID, RECID, TRANSTYPE, CANBEREVERSED, TRANSRECID, ACCOUNTNUM, TRANSCOMPANY

牢記列的上述順序是基於我在查詢中發現它們的順序，要找出理想的順序，確定每列的選擇性，並按照從高選擇性到低的順序對它們進行排序。在添加新索引之前的選擇性路徑，然後添加索引並檢查執行路徑再次查看是否正在使用新索引（它們應該是。如果不是，則可能表示缺少一列）。然後，當轉移到下一個索引時，還要留意剛剛添加的索引，以查看剛纔添加的索引是否可能會影響執行路徑（如果您捕獲了所有索引使用的列，但這種類型的行爲永遠不能排除100％）。

需要注意的另一件好事是服務器返回的統計信息。添加新索引時，目標應該是降低物理讀取量（基於磁盤的搜索），並將其轉換爲邏輯讀取（從內存中購買，這樣更便宜）。

你的里程可能會有所不同，但上述讓你在一個好的開始。

來源

2014-07-09 10:31:09 SchmitzIT

也許somthing配置錯誤或某個其他進程正在鎖定表？我在本地數據庫上執行了你的查詢，並在大約1秒內執行。

查看SQL服務器上正在運行的進程並搜索鎖。你可以使用SSMS中的查詢分析器。 enter image description here

來源

2014-07-22 14:32:24 Nico

在Axapta數據庫上查詢時的性能問題

回答

相關問題