Sql Server Query Optimization - PullRequest
       0

Sql Server Query Optimization

0 голосов
/ 24 июня 2010

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

Скажите, что мои параметры обнуляются (@ filter1, @ filter2, @ filter3 ...).Один из способов решить эту проблему:

SELECT col1, col2, col3
FROM table
WHERE col1 = ISNULL(@filter1, col1)
AND col2 = ISNULL(@filter2, col2)
AND col3 = ISNULL(@filter3, col3)

Результат этого будет фильтроваться соответствующими фильтрами, если не нулевым.Вопрос в следующем: 1) Это хорошая практика?2) Оптимизатор оптимизирует выход col1 = col1 или это повлияет на производительность запроса?

Ответы [ 6 ]

3 голосов
/ 24 июня 2010

Эрланд Соммарског собрал отличную статью по этому типу проблемы.Я настоятельно рекомендую прочитать это.

1 голос
/ 24 июня 2010

Об оптимизации условий: вы должны понять, что скомпилированный план должен удовлетворять любому значению переменной. Поэтому при создании плана SQL Server должен создать план доступа, который работает, когда @ filter1 равен NULL, а также, когда @ filter1 не равен NULL. Результатом почти всегда является сканирование.

Статьи, на которые ссылается Том Х., подробно разбираются в этом.

0 голосов
/ 24 июня 2010

По моему опыту (при запуске некоторых тестов для больших таблиц) следующее:

(col1 = @filter or @filter IS NULL)

намного быстрее, чем:

col1 = ISNULL(@filter1, col1)
0 голосов
/ 24 июня 2010

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

Было бы намного лучше, если бы вы просто генерировали запрос на стороне клиента с правильными фильтрами в предложении where вместо того, чтобы пытаться написать один универсальный запрос.

0 голосов
/ 24 июня 2010

1) Это хорошая практика? 2) Оптимизатор оптимизирует выход col1 = col1 или это повлияет на производительность запроса?

Да, это хорошая практика.

Некоторые РСУБД оптимизируют его, а некоторые нет. Нет, если вы называете это подготовленным заявлением.

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

Сконцентрируйтесь на написании кода, который четко выражает то, что вы делаете. На мой взгляд, эта идиома ясна и лаконична.

0 голосов
/ 24 июня 2010

ISNULL может повредить использование индекса, поэтому я бы не сказал, что он идеален, но если вам нужна описанная выше функциональность, я не уверен, что есть способ обойти это.

Можете ли вы взглянуть на свой план выполнения, чтобы увидеть, используется ли индекс, который вы ожидаете использовать?

...