O SQL Server não otimiza a junção de mesclagem paralela em duas tabelas particionadas equivalentemente

Pedimos desculpas antecipadamente pela pergunta muito detalhada. Incluí consultas para gerar um conjunto de dados completo para reproduzir o problema e estou executando o SQL Server 2012 em uma máquina de 32 núcleos. No entanto, não acho que isso seja específico do SQL Server 2012 e forcei um MAXDOP de 10 para este exemplo em particular.

Eu tenho duas tabelas que são particionadas usando o mesmo esquema de partição. Ao uni-los na coluna usada para particionar, observei que o SQL Server não é capaz de otimizar uma junção de mesclagem paralela tanto quanto se poderia esperar e, portanto, opta por usar um HASH JOIN. Nesse caso em particular, sou capaz de simular manualmente um MERGE JOIN paralelo muito mais ideal, dividindo a consulta em 10 intervalos disjuntos com base na função de partição e executando cada uma dessas consultas simultaneamente no SSMS. Usando o WAITFOR para executá-las todas exatamente ao mesmo tempo, o resultado é que todas as consultas são concluídas em ~ 40% do tempo total usado pelo HASH JOIN paralelo original.

Existe alguma maneira de o SQL Server fazer essa otimização por conta própria no caso de tabelas particionadas equivalentemente? Eu entendo que o SQL Server geralmente pode gerar muita sobrecarga para tornar um MERGE JOIN paralelo, mas parece que existe um método de sharding muito natural com sobrecarga mínima nesse caso. Talvez seja apenas um caso especializado que o otimizador ainda não seja inteligente o suficiente para reconhecer?

Aqui está o SQL para configurar um conjunto de dados simplificado para reproduzir este problema:

/* Create the first test data table */
CREATE TABLE test_transaction_properties 
    ( transactionID INT NOT NULL IDENTITY(1,1)
    , prop1 INT NULL
    , prop2 FLOAT NULL
    )

/* Populate table with pseudo-random data (the specific data doesn't matter too much for this example) */
;WITH E1(N) AS (
    SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 
    UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
)
, E2(N) AS (SELECT 1 FROM E1 a CROSS JOIN E1 b)
, E4(N) AS (SELECT 1 FROM E2 a CROSS JOIN E2 b)
, E8(N) AS (SELECT 1 FROM E4 a CROSS JOIN E4 b)
INSERT INTO test_transaction_properties WITH (TABLOCK) (prop1, prop2)
SELECT TOP 10000000 (ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) % 5) + 1 AS prop1
                , ABS(CAST(CAST(NEWID() AS VARBINARY) AS INT)) * rand() AS prop2
FROM E8

/* Create the second test data table */
CREATE TABLE test_transaction_item_detail
    ( transactionID INT NOT NULL
    , productID INT NOT NULL
    , sales FLOAT NULL
    , units INT NULL
    )

 /* Populate the second table such that each transaction has one or more items
     (again, the specific data doesn't matter too much for this example) */
INSERT INTO test_transaction_item_detail WITH (TABLOCK) (transactionID, productID, sales, units)
SELECT t.transactionID, p.productID, 100 AS sales, 1 AS units
FROM test_transaction_properties t
JOIN (
    SELECT 1 as productRank, 1 as productId
    UNION ALL SELECT 2 as productRank, 12 as productId
    UNION ALL SELECT 3 as productRank, 123 as productId
    UNION ALL SELECT 4 as productRank, 1234 as productId
    UNION ALL SELECT 5 as productRank, 12345 as productId
) p
    ON p.productRank <= t.prop1

/* Divides the transactions evenly into 10 partitions */
CREATE PARTITION FUNCTION [pf_test_transactionId] (INT)
AS RANGE RIGHT
FOR VALUES
(1,1000001,2000001,3000001,4000001,5000001,6000001,7000001,8000001,9000001)

CREATE PARTITION SCHEME [ps_test_transactionId]
AS PARTITION [pf_test_transactionId]
ALL TO ( [PRIMARY] )

/* Apply the same partition scheme to both test data tables */
ALTER TABLE test_transaction_properties
ADD CONSTRAINT PK_test_transaction_properties
PRIMARY KEY (transactionID)
ON ps_test_transactionId (transactionID)

ALTER TABLE test_transaction_item_detail
ADD CONSTRAINT PK_test_transaction_item_detail
PRIMARY KEY (transactionID, productID)
ON ps_test_transactionId (transactionID)

Agora estamos finalmente prontos para reproduzir a consulta abaixo do ideal!

/* This query produces a HASH JOIN using 20 threads without the MAXDOP hint,
    and the same behavior holds in that case.
    For simplicity here, I have limited it to 10 threads. */
SELECT COUNT(*)
FROM test_transaction_item_detail i
JOIN test_transaction_properties t
    ON t.transactionID = i.transactionID
OPTION (MAXDOP 10)

No entanto, o uso de um único encadeamento para processar cada partição (exemplo para a primeira partição abaixo) levaria a um plano muito mais eficiente. Testei isso executando uma consulta como a abaixo para cada uma das 10 partições exatamente no mesmo momento, e todas as 10 terminaram em pouco mais de 1 segundo:

SELECT COUNT(*)
FROM test_transaction_item_detail i
INNER MERGE JOIN test_transaction_properties t
    ON t.transactionID = i.transactionID
WHERE t.transactionID BETWEEN 1 AND 1000000
OPTION (MAXDOP 1)

Você está certo que o otimizador do SQL Server prefere não gerar MERGEplanos de junção paralela (custa essa alternativa bastante alta). O paralelo MERGEsempre exige reparticionar trocas nas entradas de junção e, mais importante, exige que a ordem das linhas seja preservada nessas trocas.

O paralelismo é mais eficiente quando cada thread pode ser executado independentemente; a preservação de pedidos geralmente leva a freqüentes esperas de sincronização e, em última análise, pode causar o derramamento de trocas tempdbpara resolver uma condição de conflito intra-consulta.

Esses problemas podem ser contornados executando várias instâncias de toda a consulta em um segmento cada, com cada segmento processando um intervalo exclusivo de dados. Entretanto, essa não é uma estratégia que o otimizador considere nativamente. Como é, o modelo original do SQL Server para paralelismo interrompe a consulta nas trocas e executa os segmentos do plano formados por essas divisões em vários segmentos.

Existem maneiras de conseguir executar planos de consulta completos em vários encadeamentos em intervalos exclusivos de conjuntos de dados, mas exigem truques com os quais nem todos ficarão satisfeitos (e não serão suportados pela Microsoft ou terão garantia de funcionar no futuro). Uma dessas abordagens é iterar sobre as partições de uma tabela particionada e atribuir a cada thread a tarefa de produzir um subtotal. O resultado é o número SUMde contagens de linhas retornadas por cada encadeamento independente:

A obtenção de números de partição é fácil com os metadados:

DECLARE @P AS TABLE
(
    partition_number integer PRIMARY KEY
);

INSERT @P (partition_number)
SELECT
    p.partition_number
FROM sys.partitions AS p 
WHERE 
    p.[object_id] = OBJECT_ID(N'test_transaction_properties', N'U')
    AND p.index_id = 1;

Em seguida, usamos esses números para gerar uma junção correlacionada ( APPLY) e a $PARTITIONfunção de limitar cada thread ao número da partição atual:

SELECT
    row_count = SUM(Subtotals.cnt)
FROM @P AS p
CROSS APPLY
(
    SELECT
        cnt = COUNT_BIG(*)
    FROM dbo.test_transaction_item_detail AS i
    JOIN dbo.test_transaction_properties AS t ON
        t.transactionID = i.transactionID
    WHERE 
        $PARTITION.pf_test_transactionId(t.transactionID) = p.partition_number
        AND $PARTITION.pf_test_transactionId(i.transactionID) = p.partition_number
) AS SubTotals;

O plano de consulta mostra uma MERGEassociação sendo executada para cada linha da tabela @P. As propriedades da verificação de índice em cluster confirmam que apenas uma única partição é processada em cada iteração:

Infelizmente, isso resulta apenas no processamento serial seqüencial de partições. No conjunto de dados que você forneceu, meu laptop de 4 núcleos (com hiper-rosca a 8) retorna o resultado correto em 7 segundos com todos os dados na memória.

Para que os MERGEsubplanos sejam executados simultaneamente, precisamos de um plano paralelo em que os IDs das partições sejam distribuídos pelos encadeamentos disponíveis ( MAXDOP) e cada MERGEsubplano seja executado em um único encadeamento usando os dados em uma partição. Infelizmente, o otimizador geralmente decide contra o paralelo MERGEpor motivos de custo e não há uma maneira documentada de forçar um plano paralelo. Há uma maneira não documentada (e não suportada), usando o sinalizador de rastreamento 8649 :

SELECT
    row_count = SUM(Subtotals.cnt)
FROM @P AS p
CROSS APPLY
(
    SELECT
        cnt = COUNT_BIG(*)
    FROM dbo.test_transaction_item_detail AS i
    JOIN dbo.test_transaction_properties AS t ON
        t.transactionID = i.transactionID
    WHERE 
        $PARTITION.pf_test_transactionId(t.transactionID) = p.partition_number
        AND $PARTITION.pf_test_transactionId(i.transactionID) = p.partition_number
) AS SubTotals
OPTION (QUERYTRACEON 8649);

Agora, o plano de consulta mostra que os números das partições @Psão distribuídos entre os threads em rodízio. Cada encadeamento executa o lado interno da junção de loops aninhados para uma única partição, atingindo nosso objetivo de processar dados separados simultaneamente. O mesmo resultado agora é retornado em 3 segundos nos meus 8 hiper-núcleos, com todos os oito com 100% de utilização.

Não estou recomendando que você use essa técnica necessariamente - veja meus avisos anteriores -, mas trata da sua pergunta.

Veja meu artigo Melhorando o desempenho de junção de tabela particionada para obter mais detalhes.

Columnstore

Como você está usando o SQL Server 2012 (e assumindo que seja Enterprise), você também tem a opção de usar um índice columnstore. Isso mostra o potencial das junções de hash do modo em lote onde há memória suficiente disponível:

CREATE NONCLUSTERED COLUMNSTORE INDEX cs 
ON dbo.test_transaction_properties (transactionID);

CREATE NONCLUSTERED COLUMNSTORE INDEX cs 
ON dbo.test_transaction_item_detail (transactionID);

Com esses índices no lugar, a consulta ...

SELECT
    COUNT_BIG(*)
FROM dbo.test_transaction_properties AS ttp
JOIN dbo.test_transaction_item_detail AS ttid ON
    ttid.transactionID = ttp.transactionID;

... resulta no seguinte plano de execução do otimizador sem nenhum truque:

Resultados corretos em 2 segundos , mas a eliminação do processamento no modo de linha do agregado escalar ajuda ainda mais:

SELECT
    COUNT_BIG(*)
FROM dbo.test_transaction_properties AS ttp
JOIN dbo.test_transaction_item_detail AS ttid ON
    ttid.transactionID = ttp.transactionID
GROUP BY
    ttp.transactionID % 1;

A consulta otimizada de armazenamento de colunas é executada em 851ms .

Geoff Patterson criou o relatório de erros Partition Wise Joins, mas foi fechado como Won't Fix.

A maneira de fazer o otimizador funcionar da maneira que você achar melhor é através de dicas de consulta.

Nesse caso, OPTION (MERGE JOIN)

Ou você pode ir todo o porco e usar USE PLAN