Почему это небольшое изменение sql в предложении where внутреннего соединения вызывает значительное улучшение производительности?

Question

Справочная информация:

Мы сузили некоторые проблемы производительности в нашей ERP до одного оператора SQL. Наша служба поддержки внесла одно небольшое изменение в статистику SQL и улучшила производительность. Серверная часть - это Microsoft Access. (да, я знаю, да, это неловко, нет, у меня нет выбора в этом вопросе)

Мы перешли с 75% времени выполнения инструкции на выполнение 90 секунд и на 25% 2-3 секунды на 100% времени на 2-3 секунды.

Таблица POHDR имеет большие 20 000 строк и плюс, SUPPNAME меньше 1000. Обе таблицы имеют индексированное поле vnum.

Операторы SQL ниже, но все, что изменилось, это предложение Where, использующее SUPPNAME.vnum вместо POHDR.vnum.

ДО:

SELECT DISTINCTROW POHDR.*, 
                   SUPPNAME.SNAME1,
                   suppname.sname1 & chr(13) & chr(10) & POHDR.vnum as SUPPFLD 
    FROM POHDR 
        INNER JOIN SUPPNAME 
            ON POHDR.VNUM = SUPPNAME.VNUM 
    WHERE ((POHDR.VNUM= '20023' AND POHDR.RECDATE Is Null))  
        AND [POHDR].[CANCEL] Is Null and ((POHDR.CLOSED=No)) 
    order by IIf(InStr(PO,'-'),Left(PO,InStr(PO,'-')) & '_' & Mid(PO,InStr(PO,'-')),PO)

ПОСЛЕ:

SELECT DISTINCTROW POHDR.*, 
                   SUPPNAME.SNAME1,
                   suppname.sname1 & chr(13) & chr(10) & POHDR.vnum as SUPPFLD 
    FROM POHDR 
        INNER JOIN SUPPNAME 
            ON POHDR.VNUM = SUPPNAME.VNUM 
    WHERE ((SUPPNAME.VNUM= '26037' AND POHDR.RECDATE Is Null))  
        AND [POHDR].[CANCEL] Is Null 
        and ((POHDR.CLOSED=No)) 
    order by IIf(InStr(PO,'-'),Left(PO,InStr(PO,'-')) & '_' & Mid(PO,InStr(PO,'-')),PO)

Влияет ли изменение места, где vnum, на меньшую таблицу с меньшим дублированием vnum или вообще без него, на самом деле такое большое различие, или происходит что-то еще?

спасибо, Брайан Любопытный.

p.s. Кроме того, я не писал и не контролировал этот SQL-статус. И точно не знаю, что происходит с оператором if in order by.

Answer 1

Ключом в этом виде оптимизации запросов является индексация, поэтому прежде всего необходимо проверить, все ли поля проиндексированы, в частности SUPPNAME.VNUM и POHDR.VNUM.

Тогда второе, конечно, это количество записей в каждой таблице, которые удовлетворяют каждому из этих условий. Если существует только одно SUPPNAME.VNUM = '26037', это может устранить большое количество POHDR.VNUM = '20023', которое не сработало бы по другим критериям, которое затем не нужно выполнять.

Но не видя структуры вашей БД и данных в ней, я бы не сделал никаких определенных выводов.

Answer 2

Я не знаю, есть ли очень хороший ответ "WHY" на ваш вопрос, кроме того факта, что изменение этого предложения WHERE привело к тому, что оптимизатор выбрал другой план запроса.

Оптимизатор может выбирать план запроса на основе многих факторов (индексы, статистика, черная магия и т. Д.). Пока у вас есть хорошие индексы, лучшее, что вы обычно можете сделать, это тщательно протестировать разные похожие версии запроса и сравнить сгенерированные ими планы запросов.