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