OK, jag har ett parallellval men inte på tabellvariabeln
Jag har anonymiserat det och:
- BigParallelTable är 900 000 rader och bred
- Av äldre skäl är BigParallelTable delvis denormaliserad (jag fixar det senare, lovar)
- BigParallelTable genererar ofta parallella planer eftersom det inte är idealiskt och är "dyrt"
- SQL Server 2005 x64, SP3, build 4035, 16 kärnor
Fråga + plan:
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]))
När man nu tänker på det är en tabellvariabel nästan alltid en tabellskanning, har ingen statistik och antas en rad "Uppskattat antal rader =1", "Faktiskt.. =3".
Kan vi deklarera att tabellvariabler inte används parallellt, men den innehållande planen kan använda parallellism någon annanstans? Så BOL är korrekt och SQL Storage-artikeln är fel