Przejdź do treści
Powrót do Centrum Pomocy
SQL Server
Aplikacje Microsoft

Sql server case when — kompletny przewodnik 2026

Spis treści:

16 min czytania·Zaktualizowano dzisiaj
Autor:Piotr ZielińskiSprawdzone przezKatarzyna NowakAktualizacja: 8 czerwca 2026
Faktura VAT 23% + KSeFDostawa 1-3 min e-mailemGwarancja działania klucza5,0 / 5,0(KluczeSoft)

Spis treści:


Czym jest CASE WHEN w SQL Server

CASE WHEN to jeden z najczęściej używanych operatorów warunkowych w języku T-SQL, czyli dialekcie SQL stosowanym przez Microsoft SQL Server. Jego zadaniem jest wykonywanie logiki warunkowej bezpośrednio w zapytaniach — podobnie jak instrukcja if-else w językach programowania, ale osadzona w składni zapytań SQL. Dzięki CASE WHEN można dynamicznie przekształcać dane, budować kolumny obliczeniowe, kategoryzować wiersze oraz sterować sortowaniem i filtrowaniem, nie sięgając po zewnętrzny kod aplikacyjny czy procedury składowane.

W praktyce CASE WHEN w SQL Server 2025 i 2026 znajduje zastosowanie wszędzie tam, gdzie potrzebna jest elastyczna transformacja danych na poziomie bazy. Programiści używają go do tworzenia raportów, etykietowania rekordów, budowania widoków i definiowania reguł biznesowych. W odróżnieniu od prostego mapowania wartości w klauzuli IN czy BETWEEN, CASE WHEN pozwala zdefiniować wielogałęziową logikę, w której każda gałąź zwraca inną wartość w zależności od spełnionego warunku.

Od 2025 roku Microsoft udostępnił SQL Server 2025 w wersji preview, a rok 2026 przynosi stabilne wydanie produkcyjne. W tej wersji CASE WHEN pozostaje w pełni kompatybilny z wcześniejszymi edycjami, ale zyskuje na znaczeniu w kontekście rosnącej popularności chmurowych rozwiązań Microsoft Fabric i Azure SQL Database — środowisk, które premiują czystą logykę osadzoną w zapytaniach zamiast warstw pośrednich.

Warto podkreślić, że CASE WHEN należy do standardu SQL (SQL-92 i nowsze) i jest implementowany praktycznie identycznie we wszystkich silnikach relacyjnych — od MySQL, przez PostgreSQL, aż po Oracle. Dla osób pracujących z Microsoft SQL Server kluczowe jest jednak zrozumienie niuansów T-SQL, takich jak kolejność ewaluacji warunków, typy zwracanych danych czy wpływ na plany wykonania zapytań.


Składnia CASE WHEN — dwa warianty

SQL Server definiuje dwa warianty składniowe operatora CASE: prosty CASE (ang. simple CASE) oraz przeszukiwany CASE (ang. searched CASE). Różnią się one sposobem definiowania warunków i znajdują zastosowanie w nieco innych scenariuszach.

Prosty CASE

W wariancie prostym porównujemy wartość jednego wyrażenia wejściowego z listą wartości stałych:

CASE wyrażenie
    WHEN wartość1 THEN wynik1
    WHEN wartość2 THEN wynik2
    ...
    ELSE wynik_domyślny
END

Przykład — mapowanie kodów statusu zamówienia na etykiety tekstowe:

SELECT
    OrderID,
    OrderDate,
    CASE Status
        WHEN 1 THEN 'Nowe'
        WHEN 2 THEN 'W realizacji'
        WHEN 3 THEN 'Wysłane'
        WHEN 4 THEN 'Anulowane'
        ELSE 'Nieznany'
    END AS StatusOpis
FROM Orders;

Prosty CASE sprawdza się doskonale przy mapowaniach 1:1 — gdy mamy jedną kolumnę źródłową i przypisujemy jej wartościom konkretne wyniki. Jest czytelny i zwięzły, ale nie obsługuje złożonych warunków logicznych.

Przeszukiwany CASE

Wariant przeszukiwany pozwala na stosowanie dowolnych wyrażeń logicznych w każdej gałęzi WHEN:

CASE
    WHEN warunek_logiczny1 THEN wynik1
    WHEN warunek_logiczny2 THEN wynik2
    ...
    ELSE wynik_domyślny
END

Przykład — kategoryzacja produktów na podstawie ceny i stanu magazynowego:

SELECT
    ProductID,
    ProductName,
    UnitPrice,
    UnitsInStock,
    CASE
        WHEN UnitPrice > 100 AND UnitsInStock > 0 THEN 'Premium dostępny'
        WHEN UnitPrice > 100 AND UnitsInStock = 0 THEN 'Premium niedostępny'
        WHEN UnitPrice BETWEEN 20 AND 100 THEN 'Standard'
        ELSE 'Ekonomiczny'
    END AS Kategoria
FROM Products;

Wariant przeszukiwany jest zdecydowanie częściej wykorzystywany w rzeczywistych projektach, ponieważ pozwala budować złożoną logikę przy użyciu operatorów porównania, AND, OR, BETWEEN, LIKE czy EXISTS. Oba warianty mogą też współistnieć z klauzulą ELSE, która jest opcjonalna — pominięcie ELSE powoduje zwrócenie NULL dla wierszy niespełniających żadnego warunku.

Kolejność warunków WHEN ma znaczenie: SQL Server ewaluuje je od góry do dołu i zwraca wynik pierwszej spełnionej gałęzi. Dalsze warunki są ignorowane. To deterministyczne zachowanie jest kluczowe przy projektowaniu przypadków z nakładającymi się przedziałami wartości.

W SQL Server 2026 typ zwracany przez CASE jest ustalany przez mechanizm data type precedence na podstawie wszystkich gałęzi THEN i ELSE. Jeśli jedna gałąź zwraca VARCHAR(10), a druga NVARCHAR(20), wynikiem będzie NVARCHAR(20). Warto mieć to na uwadze, by uniknąć niejawnych konwersji obniżających wydajność.


CASE WHEN w SELECT — praktyczne przykłady

Klauzula SELECT to miejsce, gdzie CASE WHEN występuje najczęściej. Poniżej prezentuję kilka realistycznych scenariuszy z życia programisty baz danych.

Dynamiczne etykietowanie danych

Załóżmy tabelę Employees z kolumnami HireDate i Salary. Chcemy dodać kolumnę opisującą staż pracownika i poziom wynagrodzenia:

SELECT
    EmployeeID,
    FirstName,
    LastName,
    Salary,
    CASE
        WHEN DATEDIFF(YEAR, HireDate, GETDATE()) >= 10 THEN 'Senior'
        WHEN DATEDIFF(YEAR, HireDate, GETDATE()) >= 5 THEN 'Mid'
        WHEN DATEDIFF(YEAR, HireDate, GETDATE()) >= 2 THEN 'Junior'
        ELSE 'Stażysta'
    END AS Poziom,
    CASE
        WHEN Salary > 15000 THEN 'Wysokie'
        WHEN Salary BETWEEN 8000 AND 15000 THEN 'Średnie'
        ELSE 'Niskie'
    END AS WynagrodzenieKategoria
FROM Employees;

W jednym zapytaniu otrzymujemy dwie kolumny obliczeniowe, które w przeciwnym razie wymagałyby osobnych widoków lub logiki w aplikacji. Dzięki CASE WHEN raport staje się samowystarczalny.

Pivotowanie danych z CASE WHEN

Choć SQL Server udostępnia operator PIVOT, wiele zespołów preferuje ręczne pivotowanie za pomocą CASE WHEN ze względu na większą kontrolę i czytelność:

SELECT
    CategoryID,
    SUM(CASE WHEN Quarter = 1 THEN SalesAmount ELSE 0 END) AS Q1,
    SUM(CASE WHEN Quarter = 2 THEN SalesAmount ELSE 0 END) AS Q2,
    SUM(CASE WHEN Quarter = 3 THEN SalesAmount ELSE 0 END) AS Q3,
    SUM(CASE WHEN Quarter = 4 THEN SalesAmount ELSE 0 END) AS Q4
FROM SalesData
GROUP BY CategoryID;

Ten wzorzec jest szczególnie popularny w systemach raportowych, gdzie dane w kolumnach (miesiąc, kwartał, rok) muszą stać się nagłówkami.

Obsługa wartości NULL

CASE WHEN doskonale współpracuje z IS NULL / IS NOT NULL, umożliwiając zastępowanie pustych wartości opisowymi etykietami:

SELECT
    CustomerID,
    CompanyName,
    CASE
        WHEN Phone IS NULL AND Email IS NULL THEN 'Brak kontaktu'
        WHEN Phone IS NULL THEN 'Tylko email'
        WHEN Email IS NULL THEN 'Tylko telefon'
        ELSE 'Pełny kontakt'
    END AS TypKontaktu
FROM Customers;

Translacja kodów bez tabel słownikowych

Gdy baza nie posiada tabel słownikowych (np. ze względu na integrację z systemem zewnętrznym), CASE WHEN staje się szybkim słownikiem:

SELECT
    InvoiceID,
    CASE PaymentMethod
        WHEN 'CC' THEN 'Karta kredytowa'
        WHEN 'BT' THEN 'Przelew bankowy'
        WHEN 'PP' THEN 'PayPal'
        WHEN 'BL' THEN 'BLIK'
        ELSE 'Inna metoda'
    END AS MetodaPlatnosci
FROM Invoices;

W tym przykładzie CASE WHEN zastępuje JOIN z tabelą słownikową, co upraszcza kod, ale przy bardzo dużych zbiorach danych lepszą wydajność zapewni właśnie tabela słownikowa z indeksem.


CASE WHEN w klauzulach WHERE, ORDER BY i GROUP BY

Choć CASE WHEN kojarzy się głównie z SELECT, jego prawdziwa siła ujawnia się w pozostałych klauzulach zapytania SQL.

CASE WHEN w WHERE

SQL Server pozwala na warunkowe filtrowanie za pomocą CASE WHEN, ale trzeba pamiętać, że CASE zwraca wartość skalarną — nie zastępuje dynamicznej konstrukcji warunku:

SELECT *
FROM Products
WHERE
    CASE
        WHEN @FilterType = 'Category' THEN CategoryID
        WHEN @FilterType = 'Supplier' THEN SupplierID
        ELSE 0
    END = @FilterValue;

Powyższy wzorzec działa, ale bywa problematyczny wydajnościowo — optymalizator zapytań SQL Server 2026 może nie być w stanie wykorzystać indeksów, ponieważ warunek staje się nieprzejrzysty. Lepszym podejściem jest budowanie dynamicznego SQL-a lub rozbicie na osobne zapytania. CASE WHERE sprawdza się natomiast w prostych scenariuszach, takich jak warunkowe ignorowanie filtrów:

WHERE (@IgnoreDate = 1 OR OrderDate >= @StartDate)

CASE WHEN w ORDER BY

Dynamiczne sortowanie to jeden z najczęstszych przypadków użycia CASE WHEN poza SELECT. Pozwala zmieniać kolejność sortowania na podstawie parametru wejściowego:

SELECT ProductID, ProductName, UnitPrice, UnitsInStock
FROM Products
ORDER BY
    CASE WHEN @SortBy = 'Name' THEN ProductName END ASC,
    CASE WHEN @SortBy = 'Price' THEN UnitPrice END DESC,
    CASE WHEN @SortBy = 'Stock' THEN UnitsInStock END ASC;

Trik polega na tym, że CASE zwraca NULL dla gałęzi, które nie odpowiadają wybranemu kryterium, a NULL-e są ignorowane w sortowaniu (chyba że ustawimy NULLS FIRST / NULLS LAST, co w T-SQL wymaga dodatkowej obsługi). W SQL Server 2026 można też użyć IIF jako skróconej formy CASE w ORDER BY, ale o tym w dalszej części.

CASE WHEN w GROUP BY

Grupowanie według wyrażeń CASE WHEN umożliwia tworzenie niestandardowych kategorii w agregacjach:

SELECT
    CASE
        WHEN UnitPrice < 50 THEN 'Niska'
        WHEN UnitPrice BETWEEN 50 AND 200 THEN 'Średnia'
        ELSE 'Wysoka'
    END AS PrzedzialCenowy,
    COUNT(*) AS LiczbaProduktow,
    AVG(UnitsInStock) AS SredniStan
FROM Products
GROUP BY
    CASE
        WHEN UnitPrice < 50 THEN 'Niska'
        WHEN UnitPrice BETWEEN 50 AND 200 THEN 'Średnia'
        ELSE 'Wysoka'
    END;

Częstym błędem jest grupowanie po aliasie kolumny (np. GROUP BY PrzedzialCenowy), co w T-SQL nie jest dozwolone — konieczne jest powtórzenie pełnego wyrażenia CASE WHEN w klauzuli GROUP BY. Alternatywą jest użycie podzapytania lub CTE, które nadaje alias przed grupowaniem.


Zagnieżdżone CASE WHEN i pułapki

Zagnieżdżanie CASE WHEN — czyli umieszczanie CASE wewnątrz THEN innego CASE — jest technicznie możliwe, ale rodzi pytania o czytelność i utrzymywalność kodu.

SELECT
    OrderID,
    CASE
        WHEN TotalAmount > 1000 THEN
            CASE
                WHEN CustomerTier = 'VIP' THEN 'Duże zamówienie VIP'
                ELSE 'Duże zamówienie standardowe'
            END
        WHEN TotalAmount > 100 THEN
            CASE
                WHEN CustomerTier = 'VIP' THEN 'Średnie zamówienie VIP'
                ELSE 'Średnie zamówienie standardowe'
            END
        ELSE 'Małe zamówienie'
    END AS KategoriaZamowienia
FROM Orders;

Zagnieżdżenia działają, ale są trudne do debugowania. Zespół utrzymaniowy, który za rok będzie analizował taki kod, może mieć problem z odtworzeniem logiki. Zamiast zagnieżdżania lepiej rozważyć:

  • Wielopoziomowy CTE: każdy poziom logiki w osobnym Common Table Expression.
  • Funkcję skalarną: definiujemy logikę w czytelnej funkcji i wywołujemy ją w SELECT.
  • Tabelę tymczasową: dla bardzo złożonej logiki można rozbić przetwarzanie na etapy.

Najczęstsze pułapki CASE WHEN

  1. Kolejność warunków: jeśli przedziały się pokrywają, CASE zwróci wynik pierwszego pasującego WHEN. Przykład błędu: WHEN Score >= 80 THEN 'B' WHEN Score >= 90 THEN 'A' — ocena 95 dostanie 'B', nie 'A'.

  2. Typy danych: THEN 1 ELSE 'brak' — konflikt typów. SQL Server podejmie niejawną konwersję według priorytetów typów, co może skończyć się błędem Conversion failed.

  3. Brak ELSE: pominięcie ELSE zwraca NULL. Jeśli zapytanie zakłada, że każdy wiersz pasuje do któregoś WHEN, pojawienie się nieoczekiwanych danych może wprowadzić NULL-e i zaburzyć wyniki.

  4. CASE WHEN a NULL-e w warunkach: WHEN Kolumna = NULL nigdy nie zwróci TRUE — poprawny zapis to WHEN Kolumna IS NULL.

  5. Do 10 poziomów zagnieżdżenia: SQL Server ogranicza maksymalne zagnieżdżenie CASE do 10 poziomów. Próba przekroczenia skutkuje błędem składniowym.


CASE WHEN a wydajność zapytań

Wpływ CASE WHEN na wydajność SQL Server 2026 zależy od kontekstu użycia i skali danych. Poniżej kluczowe obserwacje potwierdzone w testach na najnowszej wersji silnika.

CASE WHEN w SELECT

Operator CASE WHEN w SELECT jest ewaluowany dla każdego zwróconego wiersza. Przy milionach rekordów złożone wyrażenia CASE mogą wydłużyć czas wykonania, zwłaszcza jeśli zawierają funkcje skalarne (np. DATEDIFF, SUBSTRING). Sam CASE jest jednak operacją niskonakładową — głównym źródłem spowolnienia są funkcje wewnątrz warunków.

Zalecenie: jeśli CASE w SELECT spowalnia zapytanie, przenieś logikę do kolumny obliczeniowej (persisted computed column) w tabeli. SQL Server 2026 indeksuje kolumny obliczeniowe, co drastycznie przyspiesza filtrowanie i grupowanie po wartościach kategoriowanych przez CASE.

CASE WHEN w WHERE a SARGeability

SARGeability (Search ARGument) to zdolność optymalizatora do wykorzystania indeksu przy wyszukiwaniu. CASE WHEN w WHERE prawie zawsze niszczy SARGeability, zmuszając SQL Server do skanowania indeksu (index scan) zamiast seek.

-- NIE SARGeable:
WHERE CASE WHEN @Flag = 1 THEN ColumnA ELSE ColumnB END = @Value

-- SARGeable:
WHERE (@Flag = 1 AND ColumnA = @Value) OR (@Flag <> 1 AND ColumnB = @Value)

Drugi wariant, choć bardziej rozwlekły, pozwala optymalizatorowi na użycie indeksów. W SQL Server 2026 poprawiono zdolność upraszczania wyrażeń OR do operatora UNION ALL w planie wykonania, co dodatkowo premiuje ten styl.

CASE WHEN w ORDER BY

Sortowanie z CASE WHEN jest relatywnie tanie, o ile kolumna w CASE jest indeksowana. Jeśli jednak sortujemy po CASE zawierającym funkcje na nieindeksowanej kolumnie, SQL Server wykonuje pełne sortowanie (sort operator w planie). Dla dużych zbiorów warto rozważyć sortowanie po stronie aplikacji lub utworzenie indeksu dopasowanego do wyrażenia CASE.

CASE WHEN w JOIN

CASE WHEN w warunku JOIN to przepis na katastrofę wydajnościową — optymalizator nie może zastosować hash join ani merge join efektywnie i często wymusza nested loops z pełnym skanowaniem:

-- NIE RÓB TEGO:
FROM Orders o
JOIN Discounts d ON d.DiscountTier = CASE WHEN o.Total > 1000 THEN 'High' ELSE 'Low' END

Zamiast tego lepiej użyć CTE lub tabeli tymczasowej, gdzie CASE w SELECT wstępnie kategoryzuje dane przed JOIN.

Monitorowanie

W SQL Server 2026 warto monitorować zapytania z CASE WHEN przez Query Store i analizować rzeczywiste plany wykonania. Operator Compute Scalar, który reprezentuje obliczenia CASE, pojawia się jawnie w planie i pozwala oszacować koszt.


IIF i CHOOSE — alternatywy dla CASE WHEN

T-SQL od wersji 2012 oferuje dwie funkcje skrótowe, które w niektórych sytuacjach zastępują CASE WHEN: IIF i CHOOSE.

IIF — skrócony CASE z dwoma gałęziami

Funkcja IIF przyjmuje trzy argumenty: warunek, wartość gdy prawda, wartość gdy fałsz. Jest wewnętrznie tłumaczona na CASE WHEN przez optymalizator SQL Server:

IIF(warunek, wartość_true, wartość_false)

-- odpowiednik:
CASE WHEN warunek THEN wartość_true ELSE wartość_false END

Przykład:

SELECT
    ProductID,
    ProductName,
    IIF(UnitsInStock > 0, 'Dostępny', 'Niedostępny') AS StatusDostepnosci
FROM Products;

IIF jest czytelniejszy dla prostych wyrażeń warunkowych, ale dla więcej niż dwóch gałęzi CASE WHEN pozostaje jedynym sensownym wyborem (choć technicznie można zagnieżdżać IIF-y, jest to nieczytelne). W SQL Server 2026 IIF zachowuje identyczną wydajność co CASE WHEN, ponieważ jest jedynie nakładką składniową.

CHOOSE — wybór z listy na podstawie indeksu

Funkcja CHOOSE zwraca element z listy na podstawie indeksu numerycznego (1-based):

CHOOSE(indeks, wartość1, wartość2, wartość3, ...)

Przykład — zwracanie nazwy dnia tygodnia:

SELECT
    OrderID,
    DATEPART(WEEKDAY, OrderDate) AS DzienNumer,
    CHOOSE(DATEPART(WEEKDAY, OrderDate),
        'Poniedziałek', 'Wtorek', 'Środa', 'Czwartek', 'Piątek', 'Sobota', 'Niedziela'
    ) AS DzienTygodnia
FROM Orders;

CHOOSE sprawdza się przy mapowaniu sekwencyjnych liczb (1, 2, 3…) na wartości. Jeśli indeks przekracza liczbę elementów, zwracany jest NULL. W przeciwieństwie do CASE WHEN, CHOOSE nie obsługuje dowolnych warunków — wymaga numerycznego indeksu od 1 do n.

Kiedy używać której konstrukcji

ScenariuszRekomendacja
Jeden warunek, dwie ścieżkiIIF
Mapowanie indeksu 1..n na wartościCHOOSE (jeśli indeksy są ciągłe od 1)
Wiele warunków (3+)CASE WHEN
Złożone wyrażenia logiczneCASE WHEN (przeszukiwany)
CASE w wielu miejscach zapytaniaCASE WHEN (spójność składni)

W praktyce najlepszą czytelność zapewnia konsekwentne stosowanie CASE WHEN jako podstawowego narzędzia, a IIF i CHOOSE tylko jako udogodnień dla prostych przypadków.


Częste pytania

1. Jaka jest różnica między prostym a przeszukiwanym CASE WHEN w SQL Server?

Prosty CASE (CASE wyrażenie WHEN wartość THEN wynik) porównuje jedno wyrażenie z listą stałych wartości. Przeszukiwany CASE (CASE WHEN warunek THEN wynik) umożliwia stosowanie dowolnych operatorów logicznych, porównań, LIKE, BETWEEN czy EXISTS. Przeszukiwany jest częściej używany w praktyce, bo pozwala na złożoną logikę warunkową. Oba mogą zawierać ELSE (opcjonalne) i są ewaluowane od góry do dołu aż do pierwszego spełnionego warunku.

2. Czy CASE WHEN można stosować w klauzuli WHERE SQL Server?

Tak, CASE WHEN jest dozwolony w WHERE, ale psuje SARGeability, czyli zdolność optymalizatora do używania indeksów. W efekcie zapytanie może wykonać index scan zamiast index seek, co przy dużych tabelach drastycznie spowalnia odpowiedź. Lepszym rozwiązaniem jest użycie konstrukcji OR z jawnymi warunkami lub dynamicznego SQL-a.

3. Czy CASE WHEN zwraca NULL, gdy żaden warunek nie jest spełniony i nie ma ELSE?

Tak. Jeśli wszystkie warunki WHEN zwrócą FALSE, a ELSE nie zostało zdefiniowane, CASE WHEN zwraca NULL. Jest to zgodne ze standardem SQL i dotyczy wszystkich implementacji, nie tylko SQL Server. Aby uniknąć nieoczekiwanych NULL-i w wynikach, zawsze warto jawnie dodawać ELSE z wartością domyślną.

4. Ile poziomów zagnieżdżenia CASE WHEN obsługuje SQL Server?

SQL Server dopuszcza maksymalnie 10 poziomów zagnieżdżenia wyrażenia CASE. Przekroczenie tego limitu powoduje błąd składniowy podczas parsowania zapytania. Jednak już przy 3-4 poziomach kod staje się bardzo trudny w utrzymaniu — zalecane jest rozbijanie logiki na CTE lub funkcje skalarne.

5. Czy IIF jest szybszy od CASE WHEN w SQL Server 2026?

Nie. IIF jest nakładką składniową, która podczas parsowania zapytania jest wewnętrznie tłumaczona na CASE WHEN. Optymalizator otrzymuje identyczne drzewo wyrażeń i generuje ten sam plan wykonania. Wybór między IIF a CASE WHEN powinien wynikać wyłącznie z czytelności kodu, nie z wydajności.

6. Jak CASE WHEN wpływa na plan wykonania zapytania?

CASE WHEN w SELECT pojawia się w planie wykonania jako operator Compute Scalar. Jego koszt jest zwykle niski, chyba że zawiera złożone funkcje skalarne (np. operacje na stringach czy datach) wywoływane dla milionów wierszy. W WHERE CASE WHEN uniemożliwia index seek. W ORDER BY CASE WHEN może wymusić operację sortowania, jeśli kolumna nie jest indeksowana.

7. Czy CASE WHEN działa w kolumnach obliczeniowych (computed columns) w SQL Server?

Tak, CASE WHEN można stosować w definicji kolumn obliczeniowych, zarówno zwykłych jak i persisted (utrwalonych). Kolumna persisted z CASE WHEN może być indeksowana, co znacząco przyspiesza zapytania filtrujące po jej wartościach. SQL Server 2026 rozszerza indeksowanie kolumn obliczeniowych o kompresję i columnstore.

8. Jak poprawnie obsłużyć NULL w warunku CASE WHEN w SQL Server?

Wyrażenie WHEN Kolumna = NULL nigdy nie jest prawdziwe, ponieważ NULL reprezentuje nieznaną wartość i każde porównanie z NULL daje UNKNOWN. Poprawny zapis to WHEN Kolumna IS NULL. Można też użyć ISNULL(Kolumna, wartość_zastępcza), ale zmienia to semantykę — NULL zostaje zastąpiony przed ewaluacją CASE.

9. Czy CASE WHEN w SQL Server 2026 obsługuje short-circuit evaluation?

Tak. SQL Server ewaluuje warunki WHEN sekwencyjnie od góry do dołu i przerywa po znalezieniu pierwszego pasującego. Jednak optymalizator może w niektórych przypadkach zmienić kolejność ewaluacji wyrażeń wewnątrz WHEN w ramach optymalizacji, więc nie należy polegać na short-circuit do unikania błędów (np. dzielenia przez zero). Jedynym gwarantowanym sposobem uniknięcia błędu jest upewnienie się, że każde wyrażenie jest bezpieczne niezależnie.

10. Czy CASE WHEN może zwracać różne typy danych w różnych gałęziach THEN?

Tak, ale SQL Server dokonuje niejawnej konwersji do typu o najwyższym priorytecie (data type precedence). Jeśli jedna gałąź zwraca INT, a druga VARCHAR, SQL Server skonwertuje INT na VARCHAR. Jeśli konwersja jest niemożliwa (np. VARCHAR 'abc' na INT), zapytanie zakończy się błędem konwersji. Zalecane jest jawne rzutowanie wszystkich gałęzi na ten sam typ docelowy.


Mam nadzieję, że ten przewodnik wyczerpuje tematykę CASE WHEN w Microsoft SQL Server i pomoże Ci pisać czystsze, szybsze i bardziej przewidywalne zapytania w 2026 roku. Jeśli poszukujesz legalnego oprogramowania SQL Server — od edycji Express po pełne licencje Standard i Enterprise — w przystępnych cenach, zapraszamy do zapoznania się z ofertą naszego sklepu.

Sprawdź też

Potrzebujesz licencji? Microsoft SQL Server — sprawdź ofertę KluczeSoft.pl — legalne klucze, faktura VAT, dostawa e-mail.

Najczęściej zadawane pytania

Prosty CASE (`CASE wyrażenie WHEN wartość THEN wynik`) porównuje jedno wyrażenie z listą stałych wartości. Przeszukiwany CASE (`CASE WHEN warunek THEN wynik`) umożliwia stosowanie dowolnych operatorów logicznych, porównań, LIKE, BETWEEN czy EXISTS. Przeszukiwany jest częściej używany w praktyce, bo pozwala na złożoną logikę warunkową. Oba mogą zawierać ELSE (opcjonalne) i są ewaluowane od góry do dołu aż do pierwszego spełnionego warunku.
Tak, CASE WHEN jest dozwolony w WHERE, ale psuje SARGeability, czyli zdolność optymalizatora do używania indeksów. W efekcie zapytanie może wykonać index scan zamiast index seek, co przy dużych tabelach drastycznie spowalnia odpowiedź. Lepszym rozwiązaniem jest użycie konstrukcji `OR` z jawnymi warunkami lub dynamicznego SQL-a.
Tak. Jeśli wszystkie warunki WHEN zwrócą FALSE, a ELSE nie zostało zdefiniowane, CASE WHEN zwraca NULL. Jest to zgodne ze standardem SQL i dotyczy wszystkich implementacji, nie tylko SQL Server. Aby uniknąć nieoczekiwanych NULL-i w wynikach, zawsze warto jawnie dodawać ELSE z wartością domyślną.
SQL Server dopuszcza maksymalnie 10 poziomów zagnieżdżenia wyrażenia CASE. Przekroczenie tego limitu powoduje błąd składniowy podczas parsowania zapytania. Jednak już przy 3-4 poziomach kod staje się bardzo trudny w utrzymaniu — zalecane jest rozbijanie logiki na CTE lub funkcje skalarne.
Nie. IIF jest nakładką składniową, która podczas parsowania zapytania jest wewnętrznie tłumaczona na CASE WHEN. Optymalizator otrzymuje identyczne drzewo wyrażeń i generuje ten sam plan wykonania. Wybór między IIF a CASE WHEN powinien wynikać wyłącznie z czytelności kodu, nie z wydajności.
CASE WHEN w SELECT pojawia się w planie wykonania jako operator `Compute Scalar`. Jego koszt jest zwykle niski, chyba że zawiera złożone funkcje skalarne (np. operacje na stringach czy datach) wywoływane dla milionów wierszy. W WHERE CASE WHEN uniemożliwia index seek. W ORDER BY CASE WHEN może wymusić operację sortowania, jeśli kolumna nie jest indeksowana.
Tak, CASE WHEN można stosować w definicji kolumn obliczeniowych, zarówno zwykłych jak i persisted (utrwalonych). Kolumna persisted z CASE WHEN może być indeksowana, co znacząco przyspiesza zapytania filtrujące po jej wartościach. SQL Server 2026 rozszerza indeksowanie kolumn obliczeniowych o kompresję i columnstore.
Wyrażenie `WHEN Kolumna = NULL` nigdy nie jest prawdziwe, ponieważ NULL reprezentuje nieznaną wartość i każde porównanie z NULL daje UNKNOWN. Poprawny zapis to `WHEN Kolumna IS NULL`. Można też użyć `ISNULL(Kolumna, wartość_zastępcza)`, ale zmienia to semantykę — NULL zostaje zastąpiony przed ewaluacją CASE.
Tak. SQL Server ewaluuje warunki WHEN sekwencyjnie od góry do dołu i przerywa po znalezieniu pierwszego pasującego. Jednak optymalizator może w niektórych przypadkach zmienić kolejność ewaluacji wyrażeń wewnątrz WHEN w ramach optymalizacji, więc nie należy polegać na short-circuit do unikania błędów (np. dzielenia przez zero). Jedynym gwarantowanym sposobem uniknięcia błędu jest upewnienie się, że każde wyrażenie jest bezpieczne niezależnie.
Tak, ale SQL Server dokonuje niejawnej konwersji do typu o najwyższym priorytecie (data type precedence). Jeśli jedna gałąź zwraca INT, a druga VARCHAR, SQL Server skonwertuje INT na VARCHAR. Jeśli konwersja jest niemożliwa (np. VARCHAR 'abc' na INT), zapytanie zakończy się błędem konwersji. Zalecane jest jawne rzutowanie wszystkich gałęzi na ten sam typ docelowy. --- Mam nadzieję, że ten przewodnik wyczerpuje tematykę CASE WHEN w Microsoft SQL Server i pomoże Ci pisać czystsze, szybsze i bardziej przewidywalne zapytania w 2026 roku. Jeśli poszukujesz legalnego oprogramowania SQL Server — od edycji Express po pełne licencje Standard i Enterprise — w przystępnych cenach, zapraszamy do zapozna

Czy ten artykuł był pomocny?