SQL хранит производительность процесса - огромное предложение WHERE - PullRequest
Новая
       4

SQL хранит производительность процесса - огромное предложение WHERE

1 голос
/ 17 января 2011

У меня есть сохраненный процесс, который выполняет запрос с предложением HUGE where.Само по себе предложение WHERE очень просто.Похоже, что 

SELECT a, b, c FROM table
WHERE (cond1) OR (cond2) OR (cond3) OR (cond4)

, где cond1, cond2, cond3 и cond4 представляют некоторые требования от наших пользователей.

Мой вопрос касается производительности запросов: имеет ли смысл выполнять 4 separeate?запросы (каждый с одним из условий cond {1..4}), вставить результаты во временную таблицу, а затем, наконец, выбрать все из этой временной таблицы?

Что мне интересно, является ли dbms'оптимизировать для таких ситуаций.

FWIW, я использую Syabse ASE - TDS 5.5.

Спасибо Harshath

PS: Пожалуйста, не просите меня "сделать мойсобственный бенчмаркинг ".Я буду, конечно, делать это в конце концов.Что я действительно ищу ссылки, указывающие на внутреннюю часть такой оптимизации, если таковые имеются.TY:)

Ответы [ 3 ]

2 голосов
/ 17 января 2011

Наличие большего значения WHERE почти всегда будет быстрее, чем разделение его на несколько запросов и последующее добавление результатов.

Учтите, что в нескольких запросах вы сканируете таблицу для каждого запроса - что добавляет значительные накладные расходы, не говоря уже о любом виде дискового ввода-вывода, который может произойти.Лучше сравнить все, что вам нужно сравнить, пока у вас есть данные в памяти, чем рискнуть потерять их из памяти только для того, чтобы вернуть их в память для следующего запроса.

2 голосов
/ 17 января 2011

Причина разделения запросов может быть быстрее в том, что отдельные меньшие запросы могут быть разрешены с помощью индексов, где большой запрос приводит к сканированию таблицы.

Первый вопрос: есть ли в таблице индексы?Если нет, то сканирование таблицы всегда будет требоваться, а разбиение запроса на N частей вызовет просто сканирование таблицы N.

Если есть индексы, вам нужно проверить, решит ли ваш оптимизатор их использовать.,Если оптимизатор запросов уже использует их, нет смысла разбивать запрос.

Если есть индексы, и оптимизатор запросов не использует их, и ваше тестирование показывает, что их будет быстрее использовать,Вы можете извлечь выгоду из разделения запроса.

2 голосов
/ 17 января 2011

Если вы включите все в одно предложение WHERE, по крайней мере, СУБД будет иметь возможность оптимизировать его.Если вы используете отдельные запросы, то СУБД не сможет оптимизировать.

Кроме того, мне кажется, вы добавляете кучу накладных расходов во временную таблицу, несколько запросов и объединяете все вместе.Я не могу представить, как ваш второй вариант мог бы быть быстрее или даже быстрее.

...