Добре, имам паралелен избор, но не върху променливата на таблицата
Направих го анонимно и:
- BigParallelTable е 900 000 реда и ширина
- Поради наследени причини 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 съхранение е грешна