Z góry przepraszamy za bardzo szczegółowe pytanie. Dołączyłem zapytania, aby wygenerować pełny zestaw danych do odtworzenia problemu, i korzystam z programu SQL Server 2012 na komputerze z 32 rdzeniami. Jednak nie sądzę, że jest to specyficzne dla SQL Server 2012 i dla tego konkretnego przykładu wymusiłem MAXDOP wynoszący 10.
Mam dwie tabele, które są podzielone na partycje przy użyciu tego samego schematu partycji. Łącząc je razem w kolumnie używanej do partycjonowania, zauważyłem, że SQL Server nie jest w stanie zoptymalizować łączenia równoległego scalania tak bardzo, jak można się spodziewać, i dlatego zamiast tego zdecydował się na użycie HASH JOIN. W tym konkretnym przypadku jestem w stanie ręcznie zasymulować znacznie bardziej optymalną równoległą łączenie MERGE JOIN, dzieląc zapytanie na 10 rozłącznych zakresów w oparciu o funkcję partycji i uruchamiając każde z tych zapytań jednocześnie w SSMS. Używając WAITFOR do uruchomienia ich wszystkich dokładnie w tym samym czasie, wynik jest taki, że wszystkie zapytania kończą się w ~ 40% całkowitego czasu używanego przez oryginalne równoległe ŁĄCZENIE HASH.
Czy jest jakiś sposób, aby SQL Server sam przeprowadził tę optymalizację w przypadku równo podzielonych tabel? Rozumiem, że SQL Server może generalnie wiązać się z dużym nakładem pracy w celu równoległego połączenia MERGE JOIN, ale wydaje się, że w tym przypadku istnieje bardzo naturalna metoda dzielenia fragmentów z minimalnym narzutem. Być może jest to tylko specjalistyczny przypadek, w którym optymalizator nie jest jeszcze wystarczająco sprytny, aby go rozpoznać?
Oto instrukcja SQL umożliwiająca skonfigurowanie uproszczonego zestawu danych w celu odtworzenia tego problemu:
/* 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)
Teraz jesteśmy w końcu gotowi odtworzyć suboptymalne zapytanie!
/* 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)
Jednak użycie jednego wątku do przetworzenia każdej partycji (przykład dla pierwszej partycji poniżej) doprowadziłoby do znacznie bardziej wydajnego planu. Przetestowałem to, uruchamiając zapytanie podobne do poniższego dla każdej z 10 partycji dokładnie w tym samym momencie, a wszystkie 10 zakończyło się w nieco ponad 1 sekundę:
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)
źródło
Sposób, w jaki optymalizator działa tak, jak myślisz, jest lepszy dzięki wskazówkom dotyczącym zapytań.
W tym przypadku,
OPTION (MERGE JOIN)
Lub możesz przejść cały wieprz i użyć
USE PLAN
źródło