Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Le query che leggono le variabili di tabella possono generare piani di esecuzione paralleli in SQL Server 2008?

OK, ho una selezione parallela ma non sulla variabile tabella

L'ho reso anonimo e:

  • BigParallelTable è largo 900.000 righe
  • Per motivi legacy, BigParallelTable è parzialmente denormalizzato (lo sistemerò, più tardi, promesso)
  • BigParallelTable genera spesso piani paralleli perché non è l'ideale ed è "costoso"
  • SQL Server 2005 x64, SP3, build 4035, 16 core

Query + piano:

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]))

Ora, a pensarci bene, una variabile di tabella è quasi sempre una scansione di tabella, non ha statistiche e si assume una riga "Numero stimato di righe =1", "Actual.. =3".

Possiamo dichiarare che le variabili di tabella non vengono utilizzate in parallelo, ma il piano contenitore può utilizzare il parallelismo altrove? Quindi BOL è corretto e l'articolo sull'archiviazione SQL è sbagliato