Влияет ли использование WHERE IN на производительность запросов?

Question

Я слышал, что использование предложения IN может снизить производительность, поскольку он не использует индексы должным образом. Смотрите пример ниже:

SELECT ID, Name, Address 
FROM people
WHERE id IN (SELECT ParsedValue FROM UDF_ParseListToTable(@IDList))

Лучше ли использовать форму ниже, чтобы получить эти результаты?

SELECT ID,Name,Address
FROM People as p
INNER JOIN UDF_ParseListToTable(@IDList) as ids
ON p.ID = ids.ParsedValue

Зависит ли это от того, какую версию SQL Server вы используете? Если да, то какие из них затронуты?

Answer 1

Да, при условии относительно больших наборов данных.

Лучше использовать EXISTS для больших наборов данных. Я следую этому и заметил улучшения во времени выполнения моего кода.

Согласно статье, это связано с тем, как IN против EXISTS интернализуется Другая статья: http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx

Answer 2

Это очень просто выяснить - откройте Management studio, поместите обе версии запроса, а затем запустите с включенным планом Show Execution. Сравните два плана выполнения. Часто, но не всегда, оптимизатор запросов заставляет один и тот же точный план / буквально делать одно и то же для разных версий запроса, которые логически эквивалентны.

Фактически, это его цель - цель состоит в том, чтобы оптимизатор взял ЛЮБУЮ версию запроса, предполагая, что логика была бы одинаковой, и составил оптимальный план. Увы, процесс не идеален.

Вот одно научное сравнение:

http://sqlinthewild.co.za/index.php/2010/01/12/in-vs-inner-join/ http://sqlinthewild.co.za/index.php/2009/08/17/exists-vs-in/

Answer 3

Ваш первый пример отличается от вашего второго, потому что WHERE X IN (@variable) совпадает с WHERE X = @variable (т. Е. У вас не может быть списков переменных).

Что касается производительности, вам придется посмотреть на планы выполнения, чтобы увидеть, какие индексы выбраны.

Answer 4

IN может снизить производительность, поскольку SQL Server должен сгенерировать полный набор результатов, а затем создать потенциально огромный оператор IF в зависимости от количества строк в наборе результатов. Кстати, вызов UDF также может сильно повлиять на производительность. Их очень приятно использовать, но они могут реально повлиять на производительность, если вы не будете осторожны. Вы можете использовать Google UDF и Performance для исследования этого вопроса.

Answer 5

Больше, чем IN или Table Variable, я думаю, что правильное использование индекса увеличит производительность вашего запроса.

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

Во-вторых, IN будет оцениваться только один раз, так как нет подзапроса. В вашем случае переменная @IDList, вероятно, вызовет несоответствия, которые вам понадобятся @IDList1, @IDList2, @IdList3...., потому что IN требует список.

Как общее практическое правило, вы должны избегать IN с подзапросами и использовать EXISTS с объединением - вы будете чаще получать лучшую производительность, чем нет.