OK, j'ai une sélection parallèle mais pas sur la variable de table
Je l'ai rendu anonyme et :
- BigParallelTable est large de 900 000 lignes
- Pour des raisons d'héritage, BigParallelTable est partiellement dénormalisé (je le corrigerai plus tard, promis)
- BigParallelTable génère souvent des plans parallèles car ce n'est pas idéal et c'est "coûteux"
- SQL Server 2005 x64, SP3, build 4035, 16 cœurs
Requête + forfait :
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]))
Maintenant, en y réfléchissant, une variable de table est presque toujours une analyse de table, n'a pas de statistiques et est supposée une ligne "Nombre estimé de lignes =1", "Réel.. =3".
Pouvons-nous déclarer que les variables de table ne sont pas utilisées en parallèle, mais que le plan contenant peut utiliser le parallélisme ailleurs ? Donc BOL est correct et l'article SQL Storage est faux