Question

此查询非常缓慢，我们的团队无法弄清楚原因。我们尝试过创建视图，但它仍然非常慢。有什么想法吗？

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 ;

Answer 1

首先，所有外键关系都被编入索引吗？（例如，CMSDPR23.JE215000，CP.JEBOA等

其次，LIKE强制进行全表搜索。你能索引NMELASTBUS和NAME_FIRST（等等......）并检查匹配吗？

第三，您的WHERE子句中的字段是否已编入索引？

Answer 2

如果您还没有这样做，请尝试将查询提交到DB2的EXPLAIN实用程序，以确定完整的访问路径是什么以及查询的哪些部分是最昂贵的。使用关系扫描（全表扫描）查找行的解释计划的任何部分最有可能被索引改进。

在添加一堆索引之前，请确保所涉及的表和索引具有要使用的优化程序的准确统计信息。如果自上次运行RUNSTATS后表格大幅增长，优化器可能会忽略完美的索引，因为它不了解表格的增长程度。如果数据的基数和分布与上次RUNSTATS期间捕获的数据的基数和分布发生了显着变化，请执行新的RUNSTATS。

发布已在表上定义的索引列表，以及每个表中的大致行数将有很大帮助。

LIKE搜索不一定强制进行表扫描，但如果指定的列被索引，它肯定会导致索引扫描。 EXPLAIN实用程序将向您显示这些情况下实际发生的情况。

外键并不总能从索引中受益，特别是对于整个表中基数非常低的外键。另一个问题是优化器通常必须选择要使用的最佳索引，因此存在大量次优索引将最终减慢更新并且可能不会加速读取。

让我们假设这些表上还没有好的索引。根据提供的有限信息，为CMSDPR23.JE215000表建立的索引（CWARCASNBR，CIPTYSQNBR，CT1FYA）可以减少CMSDPL23.JE026001的加入费用。同样，有希望为CMSDPR23.CT007000建立一个索引（ADDRESSID，ADDIDSEQNO），因为它有点像主键或至少是一个唯一的候选键。

如果返回了大量行，则ORDER BY将需要排序。如果您在外表中使用相同的列CP.JEBOA，CP.CT1FYA，则可能会有更便宜的排序，因为它只会被扫描一次。

Answer 3

基本原则如前所述，只使用索引键，索引键越多越快。

根据数据库记录的数量，order by将添加好1或2分钟。我通常会尽量避免它，因为我正在处理数百万条记录。

痛苦地缓慢DB2查询

3 个答案: