Dlaczego w SQL Server skanowanie wstecz klastrowanego indeksu nie może wykorzystywać równoległości?

21

Czytałem o wewnętrznych elementach SQL Server i każda książka lub blog wspomina o skanowaniu wstecznym.

Wsteczne skanowanie indeksu klastrowego nie może wykorzystywać równoległości

Jedyny post, który coś powiedział, to ten poniżej. W poście podano, że zespół SQL Server nie wdrożył wymaganych optymalizacji dla skanowania wstecz. https://www.itprotoday.com/sql-server/descending-indexes

Ponieważ strony na poziomie liścia są połączone za pomocą podwójnie połączonej listy, nie rozumiem, dlaczego skanowanie wstecz jest inne niż skanowanie do przodu. Wszelkie wyjaśnienia są bardzo mile widziane.

Kishan Dasari
źródło

Odpowiedzi:

19

W artykule, o którym mowa, wyraźnie podano, że powód, dla którego skany zamówione wstecz nie zostały zrównoleglone w SQL Server 2008 (od CU6), nie jest techniczny, ale ponieważ klienci nie zażądali tej funkcji, a zespół programistów nie zadał sobie trudu, aby ją wdrożyć.

Uwaga: artykuł został napisany prawie 10 lat temu w kontekście nieobsługiwanej wersji SQL Server 2008. Nastąpiły znaczące zmiany w silniku pamięci i optymalizatorze. To powiedziawszy, nadal widzę plan równoległy dla ASCzapytania i plan szeregowy dla DESCwersji z kwerendy demonstracyjnej artykułu na SQL Server 2017:

SELECT *
FROM dbo.Orders
WHERE orderid <= 100000
ORDER BY orderdate ASC;

SELECT *
FROM dbo.Orders
WHERE orderid <= 100000
ORDER BY orderdate DESC;

Uruchomienie tych samych zapytań w programie SQL 2019 CTP 3.2 pokazuje plan szeregowy dla obu, chyba że zmieniłem zapytanie na WHERE orderid <= 50000, w którym zaobserwowałem to samo zachowanie co SQL Server 2017. Wygląda więc na to, że albo równoległe skanowanie wstecz nie zostało jeszcze zaimplementowane, albo potrzebny jest inny scenariusz, aby to zaobserwować.

Dan Guzman
źródło