Во-первых, из BOL:Могут ли запросы, которые считывают переменные таблицы, генерируют параллельные планы выкладки в SQL Server 2008?
Запросы, изменяющие таблицы переменные не создают параллельных планов выполнения запросов. Производительность может быть затронута, когда изменены очень большие таблицы переменные или переменные таблицы в сложных запросах. В этих ситуациях вместо этого используйте временные таблицы. Для получения дополнительной информации см. CREATE TABLE (Transact-SQL). Запросы, которые читают Таблица переменные без их модификации все еще могут быть распараллелены.
Это кажется достаточно ясным. Запросы, которые читают переменные таблицы, не изменяя их, все еще могут быть распараллелены.
Но затем по крайней SQL Server Storage Engine, в противном случае авторитетный источник, Сунил Агарвал сказал в статье на данном TempDb от 30 марта 2008 года:
запросы, связанные таблицы переменных не создают параллельные планы.
Был ли Сунил перефразирующим BOL re: INSERT, или наличие табличных переменных в предложении FROM предотвращает параллелизм? Если да, то почему?
Я имею в виду конкретный пример использования контрольной таблицы, в котором у вас есть небольшая контрольная таблица, соединенная с большой таблицей, для сопоставления значений, действия в качестве фильтра или того и другого.
Спасибо!
Удивительный. Вы сравнили это с планом, созданным с помощью #FilterList, а не с @FilterList? –
Я бы положил ваше заключение наверху. Спасибо, что проверили это. Я также нашел это: http://social.msdn.microsoft.com/Forums/en-SG/sqldatabaseengine/thread/d2abcea7-dfd8-414a-8f94-13621a85c03b. Котировка Boris B: «Запросы только для чтения, которые используют переменные таблицы, все еще могут быть распараллелены. Запросы, которые включают измененные переменные таблицы, выполняются серийно. ** Мы исправим заявление в Books Online. **« –
Вы можете получить параллельный ' SELECT' в переменной таблицы. Счет 'row' поддерживается в' sys.partitions', но вам нужно использовать 'OPTION (RECOMPILE)', чтобы заставить его учесть это. –