痛苦地慢DB2查詢

這個查詢非常慢，我們的團隊無法弄清楚原因。我們嘗試創建視圖，但仍然非常緩慢。有什麼想法嗎？痛苦地慢DB2查詢

SELECT 
    CI . CWARCASNBR AS CASENUMBER , 
    CI . CT1FYA AS COURTAGENCYCODE , 
    CI . CIPTYSQNBR AS PARTYSEQNBR , 
    CI . CIRCDTYPE AS CASETYPECODE , 
    CP . NMELASTBUS AS LASTNAME , 
    CP . NAME_FIRST AS FIRSTNAME , 
    CP . NAME_MID AS MIDDLENAME , 
    CP . NAME_SUFFX AS SUFFIX , 
    CP . CP_SEX AS GENDER , 
    CP . CT1PA AS RACECODE , 
    CP . CP_DOB AS DOB , 
    CP . CP_SSN AS SSN , 
    A . STREETNAME AS ADDRESS1 , 
    A . ADDRLINE2 AS ADDRESS2 , 
    A . CITYPARISH AS CITY , 
    A . ADDRSTATE AS STATE , 
    A . ZIPCODE AS ZIP 
FROM 
    CMSDPL23 . JE026001 AS CP 
    LEFT OUTER JOIN 
    CMSDPR23 . JE215000 CI ON 
    CP . JEBOA = CI . CWARCASNBR AND 
    CP . CT1FYA = CI . CT1FYA AND 
    CP . CP_SEQ_NBR = CI . CIPTYSQNBR 
    LEFT OUTER JOIN 
    CMSDPR23 . CT007000 A ON CP . ADDRESSID = A . ADDRESSID 
         AND CP . ADDRESSPRI = A . ADDIDSEQNO 
WHERE 
    CP . NMELASTBUS LIKE 'Durham' || '%' AND 
    CP . NAME_FIRST LIKE 'Roger%' || '%' AND 
    NOT CP . PRTY_TCDE IN ('OFF' , 'BEP') AND 
    CI . CI_FLAG_1 IN ('C' , 'B') AND 
    CI . CT1MKA = '23' 
ORDER BY 
    CI . CWARCASNBR , CI . CT1FYA ;

來源

2010-02-18 mint

向我們展示您的表格架構 – Pentium10 2010-02-18 14:02:01

對於初學者來說，所有的外鍵關係都是索引的嗎？（例如，CMSDPR23.JE215000，CP.JEBOA等

其次，LIKE迫使全表搜索，你能指標NMELASTBUS和NAME_FIRST（等）併爲您的比賽？

第三，在你WHERE領域子句索引？

來源

2010-02-18 14:01:41

我應該在所有JOIN字段以及WHERE字段上放置索引嗎？ – mint 2010-02-18 15:37:09

@monO - 根據我的經驗，任何時候一個字段參與一個可能涉及遍歷整個表的查找，它應該被索引。這包括WHERE子句和JOINS中的字段。通常，JOIN中的一個字段已經爲您編制索引，作爲「其他」表的主鍵。 – 2010-02-18 16:56:55

如果您還沒有這樣做，請嘗試將查詢提交給DB2的EXPLAIN實用程序，以確定完整的訪問路徑是什麼以及查詢的哪些部分是最昂貴的。使用關係掃描（全表掃描）來查找行是最有可能通過索引來改進的

在添加一堆索引之前，請確保涉及的表和索引具有準確的統計信息以供優化器使用。如果自RUNSTATS上次運行以來該表大幅增長，那麼優化程序可能會忽略完美的索引，因爲它不瞭解表的大小。如果數據的基數和分佈與上次RUNSTATS中捕獲的數據發生了顯着變化，則執行新的RUNSTATS。

發佈已經在表中定義的索引列表以及每個表中的近似行數會有很大幫助。

LIKE搜索不一定會強制執行表掃描，但如果指定的列是索引的，肯定會導致索引掃描。 EXPLAIN實用程序將向您顯示在這些情況下實際發生的情況。

外鍵並不總是從索引中受益，特別是對於整個表中基數非常低的外鍵而言。另一個問題是，優化器通常不得不選擇最佳索引來使用，因此存在大量次優索引會降低更新速度，並且可能不會加速讀取。

我們假設這些表格上還沒有好的索引。從提供的有限信息中，爲表CMSDPR23.JE215000建立的索引（CWARCASNBR，CIPTYSQNBR，CT1FYA）可以降低來自CMSDPL23.JE026001的聯接的開銷。同樣，希望CMSDPR23.CT007000有一個已經建立在（ADDRESSID，ADDIDSEQNO）上的索引，因爲它有一種主鍵或至少一個唯一的候選鍵。

如果返回大量行，那麼您的ORDER BY將要求進行排序。如果您追蹤外表中的同一列CP.JEBOA，CP.CT1FYA，則可能會有更便宜的排序，因爲它只會被掃描一次。

來源

2010-02-24 05:17:05

-1

基本原理如前所述只使用索引鍵，索引鍵越多速度越快。

訂單將根據數據庫記錄的數量添加一兩分鐘。我通常會盡量避免它，因爲我正在處理數百萬條記錄。

來源

2016-04-01 14:51:54

你不能真正從行數到持續時間，涉及的因素太多。哦，根據查詢的不同，訂購有時需要數小時。使用'ORDER BY'與結果集大小完全無關，完全取決於您是否需要有序輸出。 – 2016-04-02 13:54:24

痛苦地慢DB2查詢

回答

相關問題