Toutes mes excuses à l'avance pour la question très détaillée. J'ai inclus des requêtes pour générer un ensemble de données complet pour reproduire le problème et j'exécute SQL Server 2012 sur une machine à 32 cœurs. Cependant, je ne pense pas que cela soit spécifique à SQL Server 2012, et j'ai forcé un MAXDOP de 10 pour cet exemple particulier.
J'ai deux tables qui sont partitionnées en utilisant le même schéma de partition. En les joignant ensemble sur la colonne utilisée pour le partitionnement, j'ai remarqué que SQL Server n'est pas en mesure d'optimiser une jointure de fusion parallèle autant qu'on pourrait s'y attendre et choisit donc d'utiliser à la place un HASH JOIN. Dans ce cas particulier, je suis capable de simuler manuellement un MERGE JOIN parallèle beaucoup plus optimal en divisant la requête en 10 plages disjointes en fonction de la fonction de partition et en exécutant chacune de ces requêtes simultanément dans SSMS. En utilisant WAITFOR pour les exécuter toutes exactement en même temps, le résultat est que toutes les requêtes se terminent en ~ 40% du temps total utilisé par le HASH JOIN parallèle d'origine.
Existe-t-il un moyen pour que SQL Server procède à cette optimisation seul dans le cas de tables partitionnées de manière équivalente? Je comprends que SQL Server peut généralement entraîner beaucoup de surcharge afin de rendre un MERGE JOIN parallèle, mais il semble qu'il existe une méthode de partitionnement très naturelle avec une surcharge minimale dans ce cas. Peut-être s'agit-il simplement d'un cas spécialisé que l'optimiseur n'est pas encore assez intelligent pour reconnaître?
Voici le SQL pour configurer un ensemble de données simplifié afin de reproduire ce problème:
/* 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)
Maintenant, nous sommes enfin prêts à reproduire la requête sous-optimale!
/* 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)
Cependant, l'utilisation d'un seul thread pour traiter chaque partition (exemple pour la première partition ci-dessous) conduirait à un plan beaucoup plus efficace. J'ai testé cela en exécutant une requête comme celle ci-dessous pour chacune des 10 partitions exactement au même moment, et toutes les 10 ont terminé en un peu plus d'une seconde:
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)