Максимальный размер для Запроса SQL Server? В пункте? Есть ли Лучший Подход [дубликат]
Используйте переключатель.
В худшем случае компилятор генерирует тот же код как, если еще цепочка, таким образом, Вы ничего не теряете. Если в сомнении помещает наиболее распространенные случаи сначала в оператор переключения.
В лучшем случае оптимизатор может найти лучший способ генерировать код. Общие вещи, которые делает компилятор, состоят в том, чтобы создать дерево выбора из двух альтернатив (сохраняет, выдерживает сравнение и переходит в среднем случае), или просто создайте таблицу переходов (работы без выдерживает сравнение вообще).
4 ответа
Каждый пакет SQL должен соответствовать пределу размера пакета : 65 536 * Размер сетевого пакета.
Кроме этого, ваш запрос ограничен условиями выполнения. Обычно размер стека заканчивается, потому что x IN (a, b, c) - не что иное, как x = a OR x = b OR x = c, которое создает дерево выражений, подобное x = a OR (x = b OR (x = c)), поэтому он становится очень глубоким с большим количеством OR. SQL 7 попадал бы в SO при значениях примерно 10k в IN , но в настоящее время стеки намного глубже (из-за x64), поэтому он может быть довольно глубоким.
Обновление
Вы уже встречали статью Эрланда по теме передачи списков / массивов в SQL Server. В SQL 2008 у вас также есть Table Valued Parameters , которые позволяют вам передать весь DataTable как один параметр типа таблицы и присоединиться к нему.
XML и XPath - еще одно жизнеспособное решение:
SELECT ...
FROM Table
JOIN (
SELECT x.value(N'.',N'uniqueidentifier') as guid
FROM @values.nodes(N'/guids/guid') t(x)) as guids
ON Table.guid = guids.guid;
Можете ли вы загрузить идентификаторы GUID в рабочую таблицу, а затем выполнить
... WHERE var IN SELECT guid FROM #scratchtable
Максимумы SQL Server раскрыты http://msdn.microsoft.com/en-us/library/ms143432.aspx (это версия 2008 года)
SQL-запрос может быть varchar (max), но показан как ограниченный 65 536 * размер сетевого пакета, но даже в этом случае вас могут сбить с толку 2100 параметров каждого запроса. Если SQL выберет параметризацию литеральных значений в предложении in, я думаю, вы сначала достигнете этого предела, но я его не тестировал.
Изменить: протестировать, даже при принудительной параметризации он выжил - я выбил быстрый тест, и он выполнялся с 30k элементами в предложении In. (SQL Server 2005)
При 100 тыс. Элементов потребовалось некоторое время, затем оно было сброшено с:
Сообщение 8623, уровень 16, состояние 1, строка 1 Обработчику запросов не хватило внутренних ресурсов, и он не смог создать план запроса. Это редкое событие, которое ожидается только для чрезвычайно сложных запросов или запросов, которые ссылаются на очень большое количество таблиц или разделов. Пожалуйста, упростите запрос. Если вы считаете, что получили это сообщение по ошибке, обратитесь в службу поддержки клиентов для получения дополнительной информации.
Итак, 30k возможно, но только потому, что вы можете это сделать - не означает, что вам следует:)
Изменить: Продолжено из-за дополнительный вопрос.
50k сработало, но 60k выпало, так что где-то там, на моем тестовом стенде, кстати.
Что касается того, как сделать это соединение значений без использования большого in clause, лично я бы создал temp table, вставьте значения в эту временную таблицу, проиндексируйте ее и затем используйте в объединении, предоставив ему наилучшие возможности для оптимизации объединений.
На пакет, 65536 * Размер сетевого пакета , который составляет 4 КБ, поэтому 256 МБ
Однако IN остановится. до этого, но это неточно.
Вы получаете ошибки памяти, но я не могу вспомнить точную ошибку. В любом случае огромный IN будет неэффективным.
Edit: Ремус напомнил мне: ошибка связана с "размером стека"