痛苦地慢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查询

回答

相关问题