Zgodność typów w funkcjach skalarnych

Zgodność typów w funkcjach skalarnych zapobiega niejawnym konwersjom obniżającym wydajność zapytania.

Na czym polega zgodność typów w funkcjach skalarnych

Zgodność typów w funkcjach skalarnych oznacza dopasowanie typów danych przekazywanych do funkcji oraz typu wartości, którą funkcja zwraca. Funkcja skalarna oblicza pojedynczą wartość dla każdego przetwarzanego wiersza, na przykład zamienia tekst na wielkie litery, wyznacza długość napisu, zaokrągla liczbę albo przekształca datę. Jeżeli argument ma typ zgodny z wymaganiami funkcji, silnik bazy danych może wykonać operację bez dodatkowego przekształcania wartości.

Problem pojawia się wtedy, gdy argument funkcji, kolumna i wartość porównywana należą do różnych kategorii typów, takich jak tekst, liczba, data lub wartość logiczna. Przykładowo funkcja oczekująca liczby nie powinna otrzymywać tekstu zawierającego cyfry, a porównanie kolumny liczbowej z parametrem tekstowym może wymusić konwersję jednej ze stron wyrażenia. Dokładny sposób rozstrzygania konfliktu typów zależy od konkretnego silnika SQL i jego reguł konwersji, dlatego nie należy zakładać, że identyczne wyrażenie zachowa się tak samo w każdej bazie.

Konwersje niejawne a wykonanie zapytania

Konwersja niejawna jest wykonywana automatycznie, gdy silnik uzna, że wartości różnych typów można sprowadzić do wspólnego typu. Taka konwersja może zmienić plan wykonania zapytania. Szczególnie istotny jest przypadek, w którym funkcja lub operacja obejmuje kolumnę używaną w warunku filtrowania. Zastosowanie przekształcenia do kolumny może utrudnić bezpośrednie wykorzystanie indeksu, ponieważ silnik musi najpierw obliczyć wynik funkcji dla kolejnych wartości.

Nie każda konwersja niejawna powoduje spadek wydajności. Jeżeli przekształcany jest parametr, a kolumna pozostaje w postaci zgodnej z indeksem, optymalizator może nadal wykorzystać dostęp indeksowy. Znaczenie ma również kierunek konwersji, rozmiar tabeli, selektywność warunku, statystyki oraz rodzaj planu wykonania. Dlatego wpływ należy potwierdzić analizą planu i rzeczywistych czasów wykonania, a nie wyłącznie na podstawie samego tekstu zapytania.

Jawne określanie typu w wyrażeniach

Jawne przekształcenie typu zwiększa czytelność zapytania i pozwala wskazać, która wartość ma zostać przekonwertowana. W SQL służy do tego między innymi konstrukcja CAST, na przykład CAST(parametr AS INTEGER), o ile dany silnik obsługuje typ INTEGER w takim znaczeniu. W praktyce typ docelowy powinien odpowiadać definicji kolumny oraz formatowi danych wejściowych. Konwersję należy wykonywać po stronie parametru lub stałej, jeżeli dzięki temu kolumna może pozostać bez modyfikacji w warunku.

Jawna konwersja nie naprawia błędnych danych. Próba zamiany tekstu, który nie przedstawia poprawnej liczby lub daty, może zakończyć się błędem albo odrzuceniem wiersza, zależnie od funkcji i silnika. Trzeba także uwzględnić utratę precyzji, zmianę zakresu wartości oraz sposób interpretacji tekstu zawierającego separator dziesiętny lub zapis daty. W wyrażeniach arytmetycznych typ wyniku powinien być sprawdzony osobno, ponieważ działania na liczbach całkowitych, dziesiętnych i zmiennoprzecinkowych mogą mieć różne zasady zaokrąglania.

Diagnostyka w codziennej pracy z bazą

Analizę warto rozpocząć od sprawdzenia definicji kolumn, typów parametrów oraz typów literałów użytych w zapytaniu. Następnie należy wyszukać funkcje skalarne występujące w filtrach, złączeniach i warunkach sortowania. Wątpliwe miejsca powinny zostać porównane z planem wykonania: trzeba sprawdzić, czy występuje operacja konwersji, czy kolumna jest odczytywana bezpośrednio oraz czy używany indeks ogranicza liczbę analizowanych wierszy.

Przydatnym testem jest porównanie dwóch równoważnych wersji zapytania: jednej pozostawiającej konwersję niejawną i drugiej z jawnym przekształceniem parametru do typu kolumny. Wyniki należy oceniać na danych reprezentatywnych dla rzeczywistej tabeli, z uwzględnieniem liczby wierszy i rozkładu wartości. W środowisku serwisowym diagnostyka może obejmować również sprawdzenie definicji schematu, parametrów aplikacji, logów błędów konwersji oraz powtarzalności problemu po zmianie typu lub funkcji. Taka weryfikacja pozwala odróżnić rzeczywisty problem planu wykonania od zwykłego ostrzeżenia o konwersji, które nie wpływa na działanie zapytania.