Почему точно такой же запрос выполняется быстро в prod env, но медленно в Dev env?

Question

У меня есть один запрос, который занимает 10-11 секунд в prod env, но тот же запрос занимает слишком много времени, чтобы вернуть данные в Dev env. Таблица и индексы одинаковы в обеих средах. (И Prod, и Dev находятся на одной и той же виртуальной машине). Оба запроса возвращают разные планы выполнения с разными индексами.

Prod Env при выборе индекса VMRCTTA1.VMRIACCNT_MC_EXTR_IDX, но Dev Env выбирает VMRCTTA1.VMRRACCNT_MC_EXTR_P (автоматически генерируется из первичного ключа)1003 *

Пожалуйста, помогите мне с этим.

Here is the query:

--INSERT INTO VMRCTTA1."VMRRMC_CD_SUMM"
SELECT
        ACCNT_CNTRY_CD,
        YTD,
        YEAR,
        MONTH,
        ACCNT_GSSN_CD,
        ACCNT_CD,
        ACCNT_MC_CD,
        COALESCE(REVNU,0)AS REVNU_P,
        COALESCE(QTY,0) AS QTY_PC,
        ACCNT_MC_DIV AS MC_DIV
    FROM
    (
        SELECT   ACCNT_CNTRY_CD,
            'Y' AS YTD,
            2019 AS YEAR,
            2 AS MONTH,
            ACCNT_GSSN_CD,
            ACCNT_CD,
            ACCNT_MC_CD,
            SUM(COALESCE(ACCNT_NET_REVNU,0)) AS REVNU,
            SUM (COALESCE(ACCNT_QTY,0)) AS QTY,
            CASE WHEN ACCNT_MC_DIV = 'P' THEN 'P' WHEN  ACCNT_MC_DIV = 'T' THEN 'V' END AS ACCNT_MC_DIV
        FROM    VMRCTTA1.VMRRACCNT_MC_EXTR ME--,                VMRCTTA1.VMRRMC_CD_SPS_MAPPNG CM
        WHERE
--        ME.ACCNT_MC_CD = CM.MC_CD
            ACCNT_CNTRY_CD = 531
        AND ( ACCNT_YEAR = 2019 AND ACCNT_PERIOD <= 2 )
        AND  ACCNT_MC_DIV IN ('P','T')
        GROUP BY
            ACCNT_CNTRY_CD,
            ACCNT_GSSN_CD,
            ACCNT_CD,
            ACCNT_MC_CD,
            ACCNT_MC_DIV
    )AS A

UNION

SELECT
    B.ACCNT_CNTRY_CD,
    B.YTD,
    B.YEAR,
    B.MONTH,
    B.ACCNT_GSSN_CD,
    B.ACCNT_CD,
    B.ACCNT_MC_CD,
    B.REVNU,
    B.QTY,
    B.DIV
FROM
(
    SELECT
        ACCNT_CNTRY_CD,
        YTD,
        YEAR,
        MONTH,
        ACCNT_GSSN_CD,
        ACCNT_CD,
        ACCNT_MC_CD,
        MAX(CASE WHEN ACCNT_MC_DIV ='P' THEN  COALESCE(REVNU,0) END) AS REVNU_P,
        MAX(CASE WHEN ACCNT_MC_DIV ='V' THEN  COALESCE(REVNU,0) END) AS REVNU_V,
        MAX(CASE WHEN  ACCNT_MC_DIV ='P' THEN  COALESCE(QTY,0) END) AS QTY_PC,
        MAX(CASE WHEN  ACCNT_MC_DIV ='V' THEN  COALESCE(QTY,0) END) AS QTY_VAN,
        'T' AS MC_DIV
    FROM
    (
        SELECT   ACCNT_CNTRY_CD,
            'Y' AS YTD,
            2019 AS YEAR,
            2 AS MONTH,
            ACCNT_GSSN_CD,
            ACCNT_CD,
            ACCNT_MC_CD,
            SUM(COALESCE(ACCNT_NET_REVNU,0)) AS REVNU,
            SUM (COALESCE(ACCNT_QTY,0)) AS QTY,CASE WHEN ACCNT_MC_DIV = 'P' THEN 'P' WHEN  ACCNT_MC_DIV = 'T' THEN 'V' END AS ACCNT_MC_DIV
        FROM    VMRCTTA1.VMRRACCNT_MC_EXTR ME--,                VMRCTTA1.VMRRMC_CD_SPS_MAPPNG CM
        WHERE
--        ME.ACCNT_MC_CD = CM.MC_CD
            ACCNT_CNTRY_CD = 531
        AND ( ACCNT_YEAR = 2019 AND ACCNT_PERIOD <= 2 )
        AND  ACCNT_MC_DIV IN ('P','T')
        GROUP BY
            ACCNT_CNTRY_CD,
            ACCNT_GSSN_CD,
            ACCNT_CD,
            ACCNT_MC_CD,
            ACCNT_MC_DIV
    )AS A
    GROUP BY
    ACCNT_CNTRY_CD,
    YTD,
    YEAR,
    MONTH,
    ACCNT_GSSN_CD,
    ACCNT_CD,
    ACCNT_MC_CD
) AS A,
TABLE
(
VALUES
   (A.ACCNT_CNTRY_CD,A.YTD,A.YEAR,A.MONTH,A.ACCNT_GSSN_CD,A.ACCNT_CD,A.ACCNT_MC_CD,COALESCE(A.REVNU_V,0)+COALESCE(A.REVNU_P,0),COALESCE(A.QTY_PC,0)+COALESCE(A.QTY_VAN,0),'T')
)
AS      B(ACCNT_CNTRY_CD,YTD,YEAR,MONTH,ACCNT_GSSN_CD,ACCNT_CD,ACCNT_MC_CD,REVNU,QTY,DIV)

Answer 1

Оптимизатор Db2 основан на стоимости. Помимо модели данных для расчета затрат учитываются количество строк, статистика (собранная runstats), конфигурация и ресурсы. Например, конфигурация Db2 содержит информацию о CPUSpeed, и это также имеет значение - поэтому эти значения могут отличаться в вашей среде разработки, тестирования и производства.

Эти различия могут привести к разным оценкам затрат, могут привести к разным планам доступа.

Answer 2

Начиная с версии 11.1, вы можете использовать встроенные рекомендации по оптимизации , чтобы легко проверить, единственная ли проблема здесь - разница в индексе.

В вашем конкретном случае вы можете добавить к вашему запросу следующую рекомендацию, чтобы заставить Db2 выбрать VMRIACCNT_MC_EXTR_IDX index:

/* <OPTGUIDELINES><IXSCAN TABLE='VMRCTTA1.VMRRACCNT_MC_EXTR' INDEX='VMRIACCNT_MC_EXTR_IDX'/></OPTGUIDELINES> */

Пожалуйста, попробуйте это и:

• проверить, действительно ли запрос выполняется быстрее
• проверить, есть ли ожидаемый индекс, выбранный в объяснении

Если ответ на оба вопроса - да, то это означает, что должно быть что-то не совсемпрямо со статистикой или работоспособностью индексов, например, по индексу производства более фрагментирован, что влияет на калькуляцию во время компиляции. Предполагая, что проблема будет сохраняться после REORG и RUNSTATS (я предлагаю WITH DISTRIBUTION AND DETAILED INDEXES ALL), не стесняйтесь загружать полные объяснения (db2exfmt) из PROD для запроса с указанием и без него.