Могут ли запросы, которые читают переменные таблицы, генерировать параллельные планы исключения в SQL Server 2008?

Question

Первый, от BOL :

Запросы, изменяющие переменные table , не генерируют планы выполнения параллельных запросов. На производительность может повлиять изменение очень больших переменных таблицы или переменных таблицы в сложных запросах. В этих ситуациях рассмотрите возможность использования временных таблиц. Для получения дополнительной информации см. CREATE TABLE (Transact-SQL). Запросы, которые читают table переменные без их изменения, могут все еще распараллеливаться.

Это кажется достаточно ясным. Запросы, которые read табличные переменные, без их изменения, все еще могут быть распараллелены.

Но затем на SQL Server Storage Engine , другом источнике с хорошей репутацией, Сунил Агарвал сказал об этом в статье о tempdb от 30 марта 2008 года:

Запросы с использованием табличных переменных не генерируют параллельные планы.

Была ли Sunil перефразировала BOL re: INSERT или присутствие табличных переменных в предложении FROM препятствовало параллелизму? Если так, то почему?

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

Спасибо!

Answer 1

ОК, у меня есть параллельный выбор, но нет в табличной переменной

Я анонимизировал это и:

• BigParallelTable имеет ширину 900 тыс. Строк и ширину
• По устаревшим причинам BigParallelTable частично денормализован (я исправлю это позже, обещание)
• BigParallelTable часто генерирует параллельные планы, потому что это не идеально и "дорого"
• SQL Server 2005 x64, SP3, сборка 4035, 16 ядер

Запрос + план:

DECLARE @FilterList TABLE (bar varchar(100) NOT NULL)

INSERT @FilterList (bar)
SELECT 'val1' UNION ALL 'val2' UNION ALL 'val3'

--snipped

SELECT
     *
FROM
    dbo.BigParallelTable BPT
    JOIN
    @FilterList FL ON BPT.Thing = FL.Bar

StmtText
  |--Parallelism(Gather Streams)
       |--Hash Match(Inner Join, HASH:([FL].[bar])=([BPT].[Thing]), RESIDUAL:(@FilterList.[bar] as [FL].[bar]=[MyDB].[dbo].[BigParallelTable].[Thing] as [BPT].[Thing]))
            |--Parallelism(Distribute Streams, Broadcast Partitioning)
            |    |--Table Scan(OBJECT:(@FilterList AS [FL]))
            |--Clustered Index Scan(OBJECT:([MyDB].[dbo].[BigParallelTable].[PK_BigParallelTable] AS [BPT]))

Теперь, подумав об этом, переменная таблицы почти всегда является сканированием таблицы, не имеет статистики и предполагает одну строку "Предполагаемое количество строк = 1", "Фактическое .. = 3".

Можем ли мы объявить, что переменные таблицы не используются параллельно, но содержащийся план может использовать параллелизм в другом месте? Значит, BOL верен, а статья о хранилище SQL неверна

Answer 2

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

DECLARE @T TABLE
(
X INT
)
INSERT INTO @T
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY (SELECT 0))
FROM master..spt_values v1,master..spt_values v2;

WITH E8(N)
     AS (SELECT 1
         FROM   @T a,
                @T b),
     Nums(N)
     AS (SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY (SELECT 0))
         FROM   E8)
SELECT COUNT(N)
FROM   Nums
OPTION (RECOMPILE)  

Answer 3

[Отвечая на мой вопрос здесь, чтобы я мог соответствующим образом представить соответствующие цитаты ....]

Борис Б, из темы на форумах MSDN SQL Server:

Запросы только для чтения, в которых используются переменные таблицы, все еще могут быть распараллелены. Запросы, включающие переменные таблицы, которые изменяются, выполняются последовательно. Мы исправим это утверждение в Books Online. (emp. Добавлено)

и

Обратите внимание, что есть две разновидности поддержки параллелизма:

A. Оператор может / не может быть в параллельном потоке

B. Запрос не может / не может выполняться параллельно, потому что этот оператор существует в дереве.

B является надмножеством A.

Насколько я могу судить, переменные таблицы не B, а могут быть A.

Еще одна релевантная цитата: не встроенные TVF T-SQL:

Не встроенные TVF T-SQL ... рассматриваются для параллелизма, если входные данные TVF являются постоянными времени выполнения, например переменные и параметры. Если вход является столбцом (из перекрестного применения), то параллелизм отключается для всего оператора.

Answer 4

Насколько я понимаю, параллелизм блокируется для табличных переменных для операций UPDATE / DELETE / INSERT, но не для SELECT. Конечно, доказать это будет гораздо сложнее, чем просто выдвигать гипотезы. : -)