OK, ich habe eine parallele Auswahl, aber nicht auf die Tabellenvariable
Ich habe es anonymisiert und:
- BigParallelTable ist 900.000 Zeilen und breit
- Aus Legacy-Gründen ist BigParallelTable teilweise denormalisiert (ich werde es später beheben, versprochen)
- BigParallelTable generiert oft parallele Pläne, weil es nicht ideal und "teuer" ist
- SQL Server 2005 x64, SP3, Build 4035, 16 Kerne
Abfrage + 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]))
Nun, wenn Sie darüber nachdenken, ist eine Tabellenvariable fast immer ein Tabellenscan, hat keine Statistiken und es wird angenommen, dass eine Zeile "Geschätzte Anzahl von Zeilen =1", "Tatsächlich ... =3" ist.
Können wir deklarieren, dass Tabellenvariablen nicht parallel verwendet werden, aber der enthaltende Plan Parallelität an anderer Stelle verwenden kann? Also ist BOL richtig und der Artikel zu SQL Storage ist falsch
