SELECT

SELECT to podstawowe polecenie SQL zwracające dane z jednej lub kilku tabel.

Budowa polecenia i kolejność, w jakiej silnik je czyta

Zapisujemy zapytanie zaczynając od SELECT, ale silnik bazy przetwarza je w innej kolejności: najpierw FROM wraz ze złączeniami, potem WHERE, następnie GROUP BY, dalej HAVING, dopiero potem lista kolumn w SELECT, a na końcu ORDER BY. Ta pozornie akademicka zasada rozwiązuje w praktyce dwie zagadki. Po pierwsze tłumaczy, dlaczego aliasu kolumny zdefiniowanego w SELECT nie można użyć w WHERE, ale można w ORDER BY. Po drugie wyjaśnia różnicę między WHERE a HAVING: pierwszy filtruje pojedyncze wiersze przed grupowaniem, drugi całe grupy po agregacji. Zrozumienie tej sekwencji jest ważniejsze niż znajomość składni, bo większość błędów w raportach bierze się z filtrowania w niewłaściwym momencie.

Zapytanie w konsoli kontra zapytanie w aplikacji

To samo polecenie zachowuje się inaczej uruchomione ręcznie w SQL Server Management Studio i wywołane przez program handlowy. Aplikacja zwykle przesyła je jako sparametryzowane wywołanie, więc plan wykonania jest współdzielony dla wielu różnych wartości parametru i bywa nieoptymalny dla skrajnych przypadków — stąd sytuacja, w której to samo zapytanie w konsoli działa sekundę, a w programie minutę. Druga różnica to ustawienia sesji, na przykład poziom izolacji transakcji, inny dla połączenia z aplikacji niż domyślny w konsoli. Trzecia to zakres zwracanych danych: raport pobierający wszystkie kolumny gwiazdką przenosi przez sieć wielokrotnie więcej bajtów niż zapytanie wskazujące pięć potrzebnych pól, a przy tym uniemożliwia silnikowi skorzystanie z węższego indeksu pokrywającego.

Nawyki, które kosztują wydajność i poprawność

Największym grzechem jest SELECT z gwiazdką w kodzie produkcyjnym — poza narzutem transferu psuje się przy każdej zmianie struktury tabeli, bo kolejność i liczba kolumn przestają się zgadzać z oczekiwaniami aplikacji. Drugim jest owijanie kolumny funkcją w warunku WHERE, na przykład porównywanie roku wyciągniętego z daty zamiast przedziału dat; silnik traci wtedy możliwość wyszukania po indeksie i skanuje całą tabelę. Trzecim jest podpowiedź NOLOCK dopisywana odruchowo dla przyspieszenia raportów: pozwala czytać dane niezatwierdzone, więc raport sprzedaży potrafi pokazać dokument, który za chwilę zostanie wycofany, albo policzyć ten sam wiersz dwa razy. Czwartym jest brak klauzuli ORDER BY przy jednoczesnym zakładaniu, że wyniki przyjdą w kolejności założenia rekordów — bez jawnego sortowania kolejność nie jest gwarantowana przez nic.

Raporty i zapytania w systemach handlowych

Piszemy i optymalizujemy zapytania do baz Subiekta, systemów WAPRO i Comarch, kiedy standardowe zestawienia w programie nie pokrywają potrzeb firmy albo gdy własny raport zamula całą instancję w godzinach szczytu. Wskazujemy brakujące indeksy, przenosimy ciężkie wyliczenia poza czas pracy biura i pilnujemy, żeby zapytania odczytowe nie blokowały wystawiania dokumentów.