AI w SQL – jak sztuczna inteligencja pomaga tworzyć i optymalizować zapytania SQL

Wprowadzenie: gdzie AI realnie pomaga w pracy z SQL i jakie są ograniczenia

Najtrudniejszą częścią pracy z SQL często nie jest sama składnia, lecz przełożenie pytania biznesowego na właściwą logikę. „Przychód z ostatniego miesiąca” może oznaczać wartość zamówień, zaksięgowanych płatności albo sprzedaż pomniejszoną o zwroty. AI pomaga szybciej przygotować zapytanie, ale nie rozstrzygnie samodzielnie, która definicja obowiązuje w danej organizacji. Dlatego warto traktować ją jako asystenta analityka lub programisty, a nie źródło gotowych, niepodważalnych odpowiedzi.

W codziennej pracy największą wartość przynosi skracanie drogi od problemu do rozwiązania, które można sprawdzić. Asystent może przygotować szkic zapytania na podstawie opisu, wyjaśnić działanie nieznanego fragmentu SQL, zaproponować czytelniejszy zapis lub wskazać miejsca wymagające kontroli. Pomaga też uporządkować hipotezy dotyczące wydajności i zaplanować weryfikację wyniku. Początkującemu ułatwia zrozumienie konstrukcji języka; doświadczonemu specjaliście pozwala ograniczyć powtarzalną pracę i szybciej porównać możliwe podejścia.

Trzeba przy tym odróżnić asystenta generującego SQL od optymalizatora w silniku bazy danych. Asystent proponuje rozwiązania na podstawie dostarczonego kontekstu. Optymalizator wybiera sposób wykonania zapytania, korzystając między innymi z dostępnych statystyk i struktur bazy. Sama sugestia AI nie jest więc dowodem, że zapytanie będzie działać szybciej. Podobnie poprawność składniowa nie gwarantuje, że wynik odpowiada na właściwe pytanie biznesowe.

Jakość pomocy zależy od informacji, do których narzędzie ma dostęp. Zwykły czat nie zna automatycznie schematu bazy, relacji między tabelami, znaczenia pól ani używanego dialektu SQL. Narzędzie zintegrowane ze środowiskiem może otrzymać część tego kontekstu, ale zakres dostępu zależy od jego konfiguracji. Bez potrzebnych danych model może wymyślić nazwę kolumny, przyjąć błędne założenie lub zasugerować składnię nieobsługiwaną przez dany silnik — i przedstawić to przekonująco.

Bezpieczne korzystanie z AI wymaga także kontroli nad przekazywanymi informacjami. Do zewnętrznego narzędzia nie należy przesyłać danych osobowych, haseł ani poufnych rekordów bez odpowiednich uprawnień i zabezpieczeń. Często wystarczą ograniczony opis struktury oraz zanonimizowane przykłady, choć sam schemat również może ujawniać informacje biznesowe. Propozycję AI należy traktować jako materiał do weryfikacji, nie polecenie do bezrefleksyjnego uruchomienia — szczególnie gdy operacja może zmienić dane lub obciążyć środowisko produkcyjne.

Generowanie zapytań SQL z opisu biznesowego: od wymagań do poprawnego SELECT/JOIN/CTE

„Pokaż najlepszych klientów z ostatniego kwartału” to zrozumiałe polecenie biznesowe, ale jeszcze nie kompletna specyfikacja zapytania. „Najlepsi” mogą oznaczać klientów z największym przychodem, marżą albo liczbą zamówień. Z kolei „ostatni kwartał” może odnosić się do poprzedniego kwartału kalendarzowego lub ostatnich trzech miesięcy. AI pomaga przełożyć intencję na SQL, jednak nie powinna samodzielnie rozstrzygać takich niejasności. Najpierw potrzebuje definicji wyniku, który ma zwrócić baza.

W Cognity często słyszymy pytania, jak praktycznie przełożyć wymagania biznesowe na poprawne zapytanie SQL z pomocą AI — odpowiadamy na nie także na blogu.

Co przekazać AI przed wygenerowaniem zapytania?

Sam opis oczekiwanego raportu zwykle nie wystarcza. Model potrzebuje kontekstu technicznego i biznesowego — najlepiej ograniczonego do obiektów istotnych dla zadania. Nie trzeba przekazywać rzeczywistych rekordów klientów, aby wyjaśnić strukturę danych.

• Silnik i wersja bazy: przykładowo PostgreSQL, SQL Server lub MySQL. Dialekt wpływa między innymi na zapis operacji na datach i ograniczanie liczby wyników.
• Schemat danych: nazwy tabel i kolumn, ich typy oraz klucze określające relacje. Warto dopisać znaczenie pól, których nazwy nie wyjaśniają jednoznacznie zawartości.
• Definicje biznesowe: co oznacza przychód, które statusy zamówień uwzględnić, jak traktować zwroty i według jakiej daty przypisać sprzedaż do okresu.
• Oczekiwany kształt wyniku: co reprezentuje jeden wiersz, jakie kolumny mają się pojawić oraz jak uporządkować i ewentualnie ograniczyć zestawienie.

Szczególnie ważne jest ustalenie poziomu szczegółowości. „Jeden wiersz na klienta” to inne wymaganie niż „jeden wiersz na klienta i miesiąc”. Ta decyzja wyznacza sposób grupowania danych i powinna paść przed prośbą o gotowe zapytanie.

Jak opis biznesowy przekłada się na SELECT, JOIN i CTE?

SELECT określa, jakie informacje ma zwrócić zapytanie — na przykład identyfikator klienta i łączną wartość jego zakupów. Warunki filtrowania zawężają analizowany zbiór, a agregacje pozwalają przekształcić szczegółowe transakcje w zestawienie odpowiadające pytaniu biznesowemu.

JOIN łączy dane z różnych tabel, gdy odpowiedź wymaga na przykład informacji o klientach oraz ich zamówieniach. AI powinna oprzeć takie połączenie na przekazanych relacjach, nie na podobieństwie nazw kolumn. W wymaganiach trzeba również zaznaczyć, czy raport ma obejmować klientów bez zakupów — wpływa to na wybór sposobu łączenia danych.

CTE pozwala nazwać pośredni etap zapytania. Przy bardziej złożonym zadaniu można najpierw wyznaczyć sprzedaż spełniającą warunki raportu, następnie obliczyć wyniki klientów, a na końcu przygotować ranking. Nie każde zapytanie potrzebuje jednak takiego podziału; proste zestawienie może obyć się bez CTE.

Najpierw doprecyzowanie, potem gotowy SQL

Skuteczne polecenie dla AI powinno wymuszać wyjaśnienie braków: „Na podstawie podanego schematu przygotuj zapytanie zwracające dziesięciu klientów o najwyższej wartości opłaconych zamówień w poprzednim kwartale kalendarzowym. Jeden wiersz ma odpowiadać jednemu klientowi. Zanim napiszesz SQL, wskaż brakujące definicje i zadaj pytania. Nie twórz nieistniejących tabel ani kolumn”.

Po doprecyzowaniu wymagań warto poprosić o krótkie przypisanie warunków biznesowych do elementów wygenerowanego zapytania. Dzięki temu łatwiej ocenić, czy AI odwzorowała zamówiony raport, zamiast przygotować jedynie wiarygodnie wyglądający SQL.

Refaktoryzacja i poprawa czytelności SQL: formatowanie, nazewnictwo, upraszczanie logiki, CTE vs podzapytania

Zapytanie SQL może zwracać prawidłowe wyniki, a mimo to być trudne do utrzymania. Jednoliterowe aliasy, wielokrotnie powtarzane wyrażenia i głęboko zagnieżdżone podzapytania sprawiają, że nawet drobna zmiana wymaga odtworzenia całego toku obliczeń. AI pomaga uporządkować taki kod, ale cel warto określić jednoznacznie: poprawić czytelność bez zmiany znaczenia zapytania. Refaktoryzacja nie powinna po cichu zmieniać reguł biznesowych.

Formatowanie, które pokazuje strukturę zapytania

Najprostsze zastosowanie AI to dostosowanie SQL do przyjętego standardu: ujednolicenie wielkości liter słów kluczowych, wcięć, rozmieszczenia przecinków oraz zapisu warunków. Osobne wiersze dla kolumn w SELECT, kolejnych połączeń i warunków filtrowania ułatwiają przegląd kodu oraz porównywanie jego wersji.

Warto podać modelowi wzorcowy fragment zamiast prosić ogólnie o „ładniejsze zapytanie”. Jeśli zadanie dotyczy wyłącznie formatowania, zaznacz, że AI nie ma zmieniać wyrażeń, kolejności kolumn ani nawiasów określających logikę warunków. Oddzielenie zmian kosmetycznych od zmian strukturalnych pozwala szybciej ocenić propozycję.

Nazewnictwo, które wyjaśnia rolę danych

Alias powinien pomagać zrozumieć, co reprezentuje tabela lub wynik pośredni. Nazwy takie jak monthly_sales czy active_customers zwykle mówią więcej niż t1 i tmp2. Nie oznacza to jednak, że każdy alias musi być długi: w krótkim zapytaniu zwięzłe, konsekwentne oznaczenia mogą być wystarczające.

AI może zaproponować spójną konwencję, lecz potrzebuje informacji o znaczeniu danych. Nie powinno na przykład nazywać sumy kwot net_revenue, jeśli nie wiadomo, czy uwzględnia ona podatki, rabaty i zwroty. Ostrożności wymagają też aliasy kolumn wynikowych — mogą być wykorzystywane przez raporty lub aplikacje. Ich zmiana nie zawsze jest wyłącznie kosmetyczna.

Upraszczanie logiki bez skracania kodu za wszelką cenę

Podczas refaktoryzacji AI może wskazać powtarzane obliczenia, rozbudowane wyrażenia CASE oraz fragmenty łączące kilka etapów przetwarzania. Pomocne bywa wydzielenie obliczenia do nazwanego kroku albo rozdzielenie przygotowania danych od końcowej prezentacji wyniku.

Krótszy SQL nie musi być czytelniejszy. Kilka jawnie opisanych etapów często lepiej komunikuje intencję niż jedno zwarte wyrażenie. Warto poprosić model o uzasadnienie każdej zmiany i wskazanie założeń potrzebnych do zachowania równoważności. Komentarze powinny wyjaśniać przyczynę zastosowania reguły biznesowej, a nie powtarzać treść instrukcji SQL.

CTE czy podzapytanie — co lepiej porządkuje kod?

CTE, definiowane za pomocą WITH, pozwala nadać nazwę wynikowi pośredniemu i odwołać się do niego w obrębie jednej instrukcji. Dobrze sprawdza się wtedy, gdy zapytanie ma kilka wyraźnych etapów, na przykład przygotowanie danych, agregację i wybór kolumn wynikowych. Nazwy tych etapów mogą pełnić funkcję krótkiej dokumentacji.

Podzapytanie pozostaje dobrym wyborem, gdy jest krótkie, używane lokalnie i łatwe do zrozumienia w miejscu zastosowania. Przenoszenie każdego drobnego fragmentu do CTE może niepotrzebnie rozpraszać logikę. Kryterium wyboru powinna być łatwość śledzenia przepływu danych, a nie sama liczba zagnieżdżeń. Zamiana podzapytania na CTE nie gwarantuje przyspieszenia — czytelność i wydajność to odrębne kwestie.

Jak zlecić AI bezpieczną refaktoryzację?

Podaj dialekt SQL, konwencję nazewnictwa i granice dozwolonych zmian. Przykładowe polecenie:

Uporządkuj poniższe zapytanie PostgreSQL bez zmiany jego znaczenia. Zachowaj nazwy i kolejność kolumn wynikowych. Ujednolić formatowanie i zaproponuj czytelniejsze aliasy wewnętrzne. Wydziel CTE tylko tam, gdzie upraszcza to śledzenie obliczeń. Oddziel zmiany formatowania od zmian strukturalnych, uzasadnij te drugie i wskaż miejsca, w których nie możesz potwierdzić równoważności bez dodatkowych informacji.

Wykrywanie błędów i ryzyk logicznych: duplikaty, błędne JOIN-y, filtry, agregacje i NULL-e

Zapytanie może wykonać się bez błędu, a mimo to zawyżyć przychód, pominąć część klientów lub policzyć niewłaściwą średnią. Silnik bazy danych sprawdza poprawność składni i możliwość wykonania operacji, ale nie wie, czy wynik odpowiada definicji biznesowej. AI może pomóc wychwycić rozbieżności między tym, co zapytanie robi, a tym, co powinno robić — pod warunkiem że otrzyma kontekst, a nie tylko kod SQL.

Do takiej analizy warto dołączyć schemat tabel, klucze główne i obce, informację o unikalności kolumn oraz opis oczekiwanego wyniku. Szczególnie ważne jest określenie, co ma reprezentować jeden wiersz: klienta, zamówienie, pozycję zamówienia czy podsumowanie miesiąca. Bez tego model może wskazać podejrzaną konstrukcję, ale nie rozstrzygnie wiarygodnie, czy rzeczywiście jest błędem. W Cognity omawiamy weryfikację zapytań SQL zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników.

Duplikaty i JOIN-y: kiedy połączenie zmienia znaczenie wyniku

Nie każdy powtarzający się identyfikator oznacza niepoprawne dane. Połączenie zamówienia z jego pozycjami naturalnie tworzy kilka wierszy dla jednego zamówienia. Problem pojawia się wtedy, gdy dalsza część zapytania traktuje je jak niezależne zamówienia — na przykład sumuje pełną wartość zamówienia przy każdej pozycji.

AI warto poprosić o prześledzenie relacji między tabelami: jeden do jednego, jeden do wielu i wiele do wielu. Szczególnej uwagi wymagają połączenia dwóch tabel szczegółowych z tą samą tabelą nadrzędną. Jeśli zamówienie ma kilka pozycji i kilka płatności, ich niezależne dołączenie może zwielokrotnić wiersze, a następnie zawyżyć agregaty.

Model może również wskazać niepełny warunek połączenia, np. użycie tylko jednej części klucza złożonego, lub nieuzasadnione założenie, że kolumna jest unikalna. Dodanie DISTINCT nie jest uniwersalną naprawą: może ukryć objaw, nie usuwając przyczyny, a po zawyżeniu sum nie przywróci prawidłowych wartości.

Filtry: poprawny warunek w niewłaściwym miejscu

Położenie filtra potrafi zmienić zbiór zwracanych rekordów. Typowy przykład to warunek dotyczący prawej tabeli umieszczony w WHERE po LEFT JOIN:

SELECT c.customer_id, o.order_id
FROM customers AS c
LEFT JOIN orders AS o
  ON o.customer_id = c.customer_id
WHERE o.status = 'paid';

Takie zapytanie nie zachowa klientów bez pasującego opłaconego zamówienia. Jeżeli wymaganie brzmi „pokaż wszystkich klientów i dołącz ich opłacone zamówienia”, warunek statusu powinien znaleźć się w ON. Jeżeli chodzi wyłącznie o klientów z opłaconymi zamówieniami, odrzucenie pozostałych jest zamierzone. AI powinno więc najpierw zestawić kod z wymaganiem, zamiast automatycznie uznawać filtr za błąd.

Podobnej kontroli wymagają nawiasy przy łączeniu AND i OR oraz rozróżnienie WHERE i HAVING: pierwszy filtruje wiersze przed grupowaniem, drugi — utworzone grupy. Pozornie podobne warunki mogą przez to odpowiadać na inne pytania biznesowe.

Agregacje i NULL-e: wynik zależy od definicji miary

Przy agregacjach AI może sprawdzić, czy poziom grupowania odpowiada oczekiwanemu wynikowi, czy miary nie zostały zwielokrotnione przez JOIN oraz czy średnia jest liczona z właściwych obserwacji. Przykładowo średnia ze średnich dla grup nie musi być równa średniej dla wszystkich rekordów, jeżeli grupy mają różną liczebność.

Osobnej uwagi wymagają brakujące wartości. COUNT(*) liczy wiersze, a COUNT(kolumna) pomija NULL-e w danej kolumnie. Porównanie z NULL za pomocą znaku równości nie zastępuje IS NULL. Z kolei NOT IN może dać nieoczekiwany wynik, jeśli zbiór po prawej stronie zawiera NULL. Także zastąpienie braku wartości zerem przez COALESCE wymaga uzasadnienia: „wartość nieznana” nie zawsze znaczy „zero”.

Przypadki brzegowe i granice oceny przez AI

W przeglądzie logicznym warto uwzględnić rekordy bez powiązań, remisy przy wyborze „najnowszego” wpisu, zerowy mianownik oraz granice przedziałów czasu. Filtr obejmujący datę końcową może na przykład pominąć większość tego dnia, jeśli porównywana kolumna przechowuje również godzinę. Znaczenie mogą mieć także strefa czasowa i dialekt SQL.

Przydatne polecenie brzmi: „Przeanalizuj zapytanie pod kątem poprawności logicznej. Dla każdego ryzyka podaj fragment kodu, warunki wystąpienia problemu i wpływ na wynik. Oddziel pewne błędy od przypuszczeń oraz wskaż brakujące informacje o danych i regułach biznesowych”. Taka forma ogranicza pochopne poprawki: sugestia AI pozostaje hipotezą do sprawdzenia, a nie dowodem, że zapytanie działa nieprawidłowo.

Optymalizacja wydajności: sugestie indeksów, przebudowa zapytań, unikanie antywzorców

AI może wskazać, gdzie zapytanie wykonuje zbędną pracę: odczytuje zbyt wiele wierszy, sortuje szeroki zestaw danych albo wielokrotnie przetwarza te same informacje. Nie potrafi jednak wiarygodnie ocenić kosztu wykonania na podstawie samego kodu SQL. Propozycja optymalizacji to hipoteza do sprawdzenia, a nie gwarancja przyspieszenia. Jej trafność zależy m.in. od silnika bazy, rozmiaru tabel, rozkładu wartości i istniejących indeksów.

Sugestie indeksów: mniej odczytów, ale dodatkowy koszt zapisu

Model może przeanalizować kolumny używane w filtrach, połączeniach i sortowaniu, a następnie zaproponować indeksy wspierające konkretny sposób dostępu do danych. Najbardziej użyteczne są rekomendacje powiązane z często wykonywanymi, kosztownymi zapytaniami — nie lista indeksów na każdej kolumnie występującej w WHERE.

Przykładowo dla wyszukiwania zamówień jednego klienta w określonym przedziale dat kandydatem jest indeks złożony na (customer_id, created_at). Równość na pierwszej kolumnie i zakres na drugiej często dobrze odpowiadają takiemu wzorcowi odczytu. Nie oznacza to jednak, że ten sam indeks będzie równie skuteczny przy wyszukiwaniu zamówień wszystkich klientów wyłącznie według daty.

Każdą sugestię indeksu trzeba zestawić z kosztem jego utrzymania. Dodatkowy indeks zajmuje miejsce i może spowalniać operacje zapisu. Warto poprosić AI o sprawdzenie, czy propozycja nie powiela istniejącego indeksu, jakie zapytania ma wspierać oraz w jakich warunkach może nie przynieść korzyści. Indeksy częściowe lub pokrywające należy rozważać z uwzględnieniem możliwości konkretnego silnika.

Przebudowa zapytań: ograniczenie pracy zamiast kosmetyki

Zmiana zapisu ma znaczenie wtedy, gdy umożliwia bazie przetworzenie mniejszej ilości danych lub zastosowanie lepszej ścieżki dostępu. Dobrym obszarem do analizy są warunki, które nakładają funkcję na indeksowaną kolumnę. Dla zwykłego indeksu może to utrudniać wykorzystanie go do wyszukiwania zakresowego.

W PostgreSQL, dla kolumny created_at typu timestamp without time zone, filtr obejmujący jeden dzień można zapisać następująco:

-- Zamiast przekształcania wartości w kolumnie:
WHERE created_at::date = DATE '2025-01-15'

-- Zakres na oryginalnej wartości:
WHERE created_at >= TIMESTAMP '2025-01-15 00:00:00'
  AND created_at < TIMESTAMP '2025-01-16 00:00:00'

Drugi zapis daje optymalizatorowi możliwość użycia zwykłego indeksu na created_at, choć nie przesądza o jego wyborze. Przy danych uwzględniających strefy czasowe granice dnia wymagają osobnego doprecyzowania.

Antywzorce, które warto poddać analizie AI

• Nadmierny zakres odczytu: SELECT * pobiera także niepotrzebne kolumny, zwiększając transfer i niekiedy koszty dalszego przetwarzania.
• Kosztowne stronicowanie: duży OFFSET może wymagać przetworzenia wielu pomijanych rekordów. Przy przechodzeniu do kolejnych stron alternatywą bywa paginacja oparta na ostatniej wartości stabilnego, jednoznacznego klucza sortowania.
• Wyszukiwanie z początkowym wildcardem: LIKE '%fraza%' zwykle nie korzysta efektywnie ze standardowego indeksu B-tree. Rozwiązaniem może być mechanizm wyszukiwania dobrany do silnika i oczekiwanej semantyki.
• Powtarzana praca: wielokrotne obliczanie tego samego kosztownego wyrażenia lub podzapytania warto przeanalizować pod kątem przebudowy. Samo przeniesienie fragmentu do CTE nie gwarantuje jednak jednorazowego wykonania ani przyspieszenia.

Aby uzyskać przydatne rekomendacje, przekaż AI definicje tabel i indeksów, wersję silnika, przybliżoną liczbę wierszy oraz typowe wartości parametrów. Poproś o uzasadnienie każdej zmiany, jej koszt i warunki opłacalności. Krótszy SQL nie musi być szybszy — o wartości optymalizacji decyduje zachowanie bazy przy rzeczywistym obciążeniu, z zachowaniem znaczenia zapytania.

Interpretacja planów zapytań: jak pytać AI o EXPLAIN/ANALYZE i wyciągać wnioski

Plan wykonania pokazuje, w jaki sposób silnik bazy zamierza pobrać i połączyć dane. AI może pomóc przełożyć ten techniczny zapis na zrozumiałą diagnozę: wskazać rozbieżności między szacunkami a rzeczywistą liczbą wierszy, wyjaśnić kolejność operacji i wytypować miejsca wymagające sprawdzenia. Nie zastępuje jednak pomiarów — wiarygodność interpretacji zależy od danych, które otrzyma.

EXPLAIN a EXPLAIN ANALYZE — co właściwie analizujesz?

Najpierw ustal, czy przekazujesz AI plan szacowany, czy plan zawierający dane z rzeczywistego wykonania. To rozróżnienie decyduje o tym, jakie wnioski można wyciągnąć.

Takie rozróżnienie dotyczy m.in. PostgreSQL. Składnia, dostępne metryki i sposób prezentacji planów różnią się między silnikami; przykładowo SQL Server udostępnia szacowane i rzeczywiste plany wykonania innymi mechanizmami. Dlatego w rozmowie z AI zawsze podawaj nazwę oraz wersję bazy.

EXPLAIN ANALYZE faktycznie wykonuje zapytanie. Nawet odczyt może mocno obciążyć serwer, a polecenia modyfikujące dane mogą wprowadzić zmiany. Nie uruchamiaj tej analizy na produkcji bez oceny ryzyka. W PostgreSQL przydatnym punktem wyjścia dla bezpiecznego zapytania odczytowego jest:

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT ...;

Opcja BUFFERS dodaje informacje o wykorzystaniu buforów i odczytach bloków, a format JSON ułatwia przekazanie struktury planu do narzędzia AI. Sam odczyt bloku nie przesądza jednak o fizycznym dostępie do dysku — dane mogły znajdować się w pamięci podręcznej systemu operacyjnego.

Jak przygotować pytanie, które da użyteczną odpowiedź?

Przekaż pełny plan, treść zapytania, istotne definicje tabel i indeksów oraz reprezentatywne wartości parametrów. Dopisz, ile trwa wykonanie i w jakich warunkach zebrano pomiar. Wycięty fragment planu może ukrywać operację odpowiedzialną za problem. Przed wysłaniem materiału do zewnętrznego narzędzia usuń dane wrażliwe i sprawdź zasady ich udostępniania.

Zamiast ogólnego „zoptymalizuj SQL” użyj polecenia ukierunkowanego na interpretację:

Analizujesz plan PostgreSQL [wersja], zebrany przez EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON). Na podstawie poniższego zapytania i pełnego planu wskaż maksymalnie trzy najważniejsze problemy. Dla każdego podaj konkretny węzeł i metryki uzasadniające ocenę. Porównaj szacowane i rzeczywiste liczby wierszy, uwzględnij loops oraz operacje korzystające z plików tymczasowych. Oddziel obserwacje od hipotez. Wskaż brakujące informacje i zaproponuj pomiar, który pozwoli sprawdzić każdą hipotezę. Nie zakładaj, że skan sekwencyjny jest błędem.

Jak oceniać wnioski AI?

Dobra odpowiedź odwołuje się do konkretnych wartości, zamiast uznawać określony typ operacji za automatycznie niekorzystny. Skan sekwencyjny może być właściwy przy odczycie dużej części tabeli. Z kolei duża rozbieżność między liczbą wierszy szacowaną i rzeczywistą jest sygnałem do zbadania estymacji, ale sama nie dowodzi, że statystyki są nieaktualne.

Sprawdź również sposób interpretacji czasu. W PostgreSQL czasy i liczby wierszy raportowane dla węzła wykonywanego wielokrotnie są wartościami średnimi na wykonanie, więc wymagają uwzględnienia loops. Czasy węzłów nadrzędnych obejmują pracę ich potomków — nie należy sumować czasów wszystkich węzłów, a plany równoległe wymagają dodatkowej ostrożności. Koszt optymalizatora nie jest natomiast czasem wyrażonym w milisekundach.

Najbardziej użyteczny wynik analizy ma postać: obserwacja → możliwe wyjaśnienie → sposób sprawdzenia. AI powinno pomóc zawęzić obszar poszukiwań, a nie przedstawiać jednego planu jako ostatecznego dowodu przyczyny spowolnienia.

Tworzenie testów i walidacji: dane testowe, asercje, regresja wyników i wydajności

Zapytanie przygotowane lub zmienione z pomocą AI trzeba sprawdzić pod dwoma względami: czy zwraca właściwe wyniki i czy wykonuje się z akceptowalnym kosztem. To odrębne kryteria — szybsze wykonanie nie rekompensuje błędnych obliczeń, a poprawny wynik na kilku rekordach nie potwierdza wydajności na danych produkcyjnych. AI może pomóc przygotować scenariusze testowe, warunki sprawdzające i procedurę porównania, ale oczekiwane rezultaty powinny wynikać z reguł biznesowych, nie z założeń przyjętych przez model.

Dane testowe: mały zestaw do kontroli logiki, większy do pomiarów

Do weryfikacji wyników najlepiej przygotować niewielki, syntetyczny zbiór danych, dla którego da się niezależnie ustalić poprawną odpowiedź. W poleceniu dla AI warto podać schemat tabel, relacje, ograniczenia oraz reguły obliczeń. Zamiast prosić ogólnie o dane testowe, lepiej zażądać przypadków wraz z uzasadnieniem: co sprawdzają i jaki wynik powinny dać.

Taki zestaw powinien obejmować sytuacje typowe, brak danych oraz przypadki graniczne wynikające z wymagań — na przykład rekord dokładnie na początku i końcu badanego okresu. Do testów wydajności potrzebny jest natomiast zbiór o reprezentatywnej skali i rozkładzie wartości. Równomiernie wygenerowane dane mogą nie ujawnić problemów występujących wtedy, gdy duża część rekordów dotyczy niewielkiej grupy klientów lub produktów. Nie trzeba przekazywać modelowi danych produkcyjnych; często wystarczą opis struktury, zagregowane charakterystyki i przykłady syntetyczne.

Asercje: konkretne warunki zamiast oceny „wygląda dobrze”

Asercja określa, co musi być prawdą, aby test został zaliczony. AI może przełożyć wymagania biznesowe na takie warunki, lecz każdy z nich wymaga przeglądu. W zależności od przeznaczenia zapytania można sprawdzać:

• Dokładny wynik — zgodność zwróconych rekordów i wartości z ręcznie ustalonym wzorcem.
• Własności wyniku — na przykład jeden wiersz na zamówienie albo zgodność sumy szczegółów z wartością raportu.
• Zachowanie po zmianie danych — dodanie rekordu spoza analizowanego okresu nie powinno zmienić wyniku raportu za ten okres.

Warto poprosić AI również o wskazanie założeń, których nie da się rozstrzygnąć na podstawie opisu. Dzięki temu niejasność w wymaganiach nie zostanie po cichu zamieniona w oczekiwany rezultat testu.

Regresja wyników i wydajności po zmianie SQL

Test regresji wyników porównuje działanie wcześniejszej i zmienionej wersji zapytania na tym samym zestawie danych. Porównanie powinno uwzględniać wartości i liczbę wystąpień poszczególnych wierszy, a nie tylko łączną liczbę rekordów. Kolejność należy oceniać wtedy, gdy jest częścią wymagań i została jawnie określona w zapytaniu. Zgodność ze starą wersją potwierdza zachowanie dotychczasowego działania, ale nie dowodzi poprawności biznesowej — obie wersje mogą powielać ten sam błąd.

Regresję wydajności sprawdza się osobno, porównując czas wykonania oraz dostępne miary zużycia zasobów w możliwie porównywalnych warunkach. Pomiary warto powtarzać, uwzględniając wpływ pamięci podręcznej, obciążenia serwera i parametrów zapytania. AI może pomóc opracować procedurę oraz kryteria akceptacji, natomiast progi należy ustalić na podstawie pomiarów i wymagań systemu. Zatwierdzone testy warto uruchamiać automatycznie po każdej zmianie, aby kontrolować zarówno poprawność wyników, jak i koszt ich uzyskania.

Przykładowe prompty oraz bezpieczeństwo danych: minimalizacja, maskowanie i dobre praktyki udostępniania

Dobry prompt do pracy z SQL powinien dostarczać modelowi kontekst techniczny i biznesowy, ale nie ujawniać więcej, niż wymaga zadanie. Do przygotowania propozycji zapytania często wystarczą: silnik i wersja bazy, fragment schematu, relacje między tabelami oraz definicja oczekiwanego wyniku. Pełny eksport danych zwykle nie jest potrzebny. Najpierw opisz strukturę i reguły, a przykładowe rekordy dodawaj tylko wtedy, gdy bez nich nie da się wyjaśnić problemu.

Jak formułować użyteczne prompty

W poleceniu rozdziel cel biznesowy, dostępne informacje i ograniczenia. Wskaż dialekt SQL oraz poproś model, aby przedstawił przyjęte założenia i dopytał o brakujące definicje. Dzięki temu łatwiej zauważysz, czy odpowiedź opiera się na rzeczywistym schemacie, czy na domysłach. W Cognity łączymy teorię z praktyką — dlatego formułowanie promptów do pracy z SQL rozwijamy także w formie ćwiczeń na szkoleniach.

Poniższe wzorce można uzupełnić kontekstem, którego udostępnienie zostało zatwierdzone w organizacji:

• Przygotowanie zapytania: „Pracuję w [silnik i wersja]. Na podstawie poniższego schematu przygotuj zapytanie realizujące [cel biznesowy]. Korzystaj wyłącznie z podanych tabel i kolumn. Jeśli brakuje definicji wskaźnika lub relacji, najpierw zadaj pytania. Nie zakładaj istnienia dodatkowych pól”.
• Analiza bez rzeczywistych rekordów: „Pomóż przeanalizować poniższe zapytanie na podstawie schematu i opisu oczekiwanego wyniku. Nie mam możliwości udostępnienia danych produkcyjnych. Wskaż, jakich minimalnych informacji potrzebujesz i czy wystarczą przykłady syntetyczne”.
• Praca z danymi syntetycznymi: „Poniższe rekordy są sztuczne. Ilustrują relacje, powtarzalność wartości i braki danych, ale nie odzwierciedlają rozkładu danych produkcyjnych. Uwzględnij to ograniczenie i oddziel wnioski wynikające z przykładów od hipotez wymagających sprawdzenia”.

Minimalizacja, maskowanie i anonimizacja — różne poziomy ochrony

Minimalizacja polega na ograniczeniu przekazywanych informacji do niezbędnego zakresu: kilku potrzebnych kolumn zamiast całej tabeli czy odpowiedniego fragmentu schematu zamiast dokumentacji całej bazy. Dotyczy także metadanych — nazwy tabel, komentarze i warunki zapytania mogą ujawniać poufne procesy biznesowe.

Maskowanie ukrywa lub zastępuje wartości wrażliwe, lecz samo w sobie nie gwarantuje anonimowości. Zastąpienie identyfikatora klienta przypisanym mu stałym symbolem może zachować powiązania między rekordami, ale jeśli nadal można przypisać je osobie, mamy do czynienia z pseudonimizacją, nie pełną anonimizacją. Takie dane nadal wymagają ochrony.

Anonimizacja wymaga, aby identyfikacja osoby nie była racjonalnie możliwa również przez połączenie udostępnionych informacji z innymi źródłami. Usunięcie nazwiska nie wystarczy, jeśli pozostają na przykład dokładna data zdarzenia, lokalizacja i unikalna historia transakcji. Do objaśniania problemów SQL często bezpieczniej przygotować niewielki zestaw danych syntetycznych niż przekształcać rekordy produkcyjne.

Co sprawdzić przed wysłaniem materiału do AI

Korzystaj z narzędzia dopuszczonego przez organizację i sprawdź warunki dotyczące przechowywania treści, ich wykorzystywania do trenowania modeli oraz dostępu do historii rozmów. Usuń hasła, tokeny, ciągi połączeń i dane osobowe także z komentarzy, komunikatów błędów oraz załączników. Polecenie „nie zapisuj tych danych” nie zastępuje ustawień usługi ani odpowiednich ustaleń umownych.

Jeśli asystent ma bezpośredni dostęp do bazy, stosuj minimalne uprawnienia, ogranicz zakres dostępnych danych i wymagaj zatwierdzania operacji zmieniających dane. Bezpieczeństwo zależy nie tylko od treści promptu, lecz także od tego, co narzędzie może odczytać i wykonać.

Power Query – jak łączyć dane z wielu plików i źródeł bez ręcznego kopiowania 02 października 2026

Power Query – jak automatyzować przygotowanie i porządkowanie danych 30 września 2026