Jest dość dobrze udokumentowane, że UDF wymuszają ogólny plan szeregowy.
Nie jestem pewien, czy to wszystko jest tak dobrze udokumentowane.
- Skalarna funkcja T-SQL zapobiega równoległości w dowolnym miejscu w planie.
- Skalarną funkcję CLR można wykonywać równolegle, o ile nie ma ona dostępu do bazy danych.
- Funkcja T-SQL o wielu instrukcjach o wartości tabeli wymusza strefę szeregową w planie, który może wykorzystywać równoległość w innym miejscu.
- Wbudowana w tabelę funkcja T-SQL jest rozwinięta jak widok, więc nie ma bezpośredniego efektu.
Zobacz Wymuszanie planu równoległego wykonywania i / lub prezentację równoległego wykonywania Craiga Freedmana .
Istnieją twierdzenia, że UDF jako czarna skrzynka muszą używać kursora.
Twierdzenia te są nieprawidłowe.
Dodatkowe punkty za wyjaśnienie, dlaczego silnik wymusza szeregowanie całego planu zamiast samego etapu obliczeń UDF.
Rozumiem, że obecne ograniczenia są wyłącznie wynikiem pewnych szczegółów implementacyjnych. Nie ma podstawowego powodu, dla którego funkcje nie mogłyby być wykonywane przy użyciu równoległości.
W szczególności funkcje skalarne T-SQL wykonują się w osobnym kontekście T-SQL, co znacznie komplikuje prawidłowe działanie, koordynację i zamknięcie (szczególnie w przypadku błędu).
Podobnie, zmienne tabelowe ogólnie obsługują odczyty równoległe (ale nie zapisują), ale zmienna tabelowa ujawniona przez funkcję wycenioną w tabeli nie jest w stanie obsługiwać odczytów równoległych z powodów specyficznych dla implementacji. Obawiam się, że potrzebujesz kogoś z dostępem do kodu źródłowego (i swobodą udostępniania szczegółów), aby udzielić wiarygodnej odpowiedzi.
Czy wsparcie dla równoległego UDF jest rozsądną funkcją, o którą można poprosić?
Oczywiście, jeśli potrafisz zrobić wystarczająco mocną skrzynkę. Uważam, że zaangażowana praca byłaby obszerna, więc twoja propozycja musiałaby spełnić bardzo wysoki poziom. Na przykład powiązane (i znacznie prostsze) żądanie dostarczenia wbudowanych funkcji skalarnych ma świetne wsparcie, ale od lat nie funkcjonuje.
Może chcesz przeczytać artykuł Microsoft:
... który przedstawia podejście, jakie Microsoft zamierza zastosować w celu rozwiązania problemów z wydajnością funkcji skalarnej T-SQL w wydaniu po SQL Server 2017.
Celem Froid jest umożliwienie programistom korzystania z abstrakcji funkcji UDF i procedur bez uszczerbku dla wydajności. Froid osiąga ten cel za pomocą nowatorskiej techniki automatycznego przekształcania programów imperatywnych w równoważne relacyjne formy algebraiczne, gdy tylko jest to możliwe. Froid modeluje bloki kodu imperatywnego jako wyrażenia relacyjne i systematycznie łączy je w jedno wyrażenie za pomocą operatora Zastosuj, umożliwiając w ten sposób optymalizatorowi zapytań wybranie wydajnych, równoległych planów zapytań zorientowanych na zestaw .
(moje podkreślenie)
Wbudowane funkcje skalarne T-SQL są teraz zaimplementowane w SQL Server 2019 .