AI w SQL – wykorzystanie AI do analizy baz danych i rozwiązywania błędów w zapytaniach

Wprowadzenie: kiedy AI pomaga w analizie baz danych i debugowaniu SQL

Zapytanie wykonuje się bez błędu, ale raport pokazuje podejrzanie wysoką sprzedaż. Albo odwrotnie: wiadomo, jaki wynik jest potrzebny, lecz próba jego uzyskania kończy się komunikatem, którego przyczyna nie jest oczywista. AI w SQL pomaga przede wszystkim skrócić drogę od takiego problemu do hipotezy, którą można sprawdzić. Może objaśnić działanie zapytania, wskazać potencjalne źródła rozbieżności i pomóc przełożyć pytanie biznesowe na sposób analizy danych.

Warto rozróżnić dwa zastosowania. Analiza baz danych służy poszukiwaniu odpowiedzi: jak zmienia się liczba zamówień, które grupy klientów wracają najczęściej lub skąd bierze się różnica między raportami. AI może zaproponować sposób zestawienia danych i pomóc zrozumieć otrzymane wyniki. Debugowanie SQL koncentruje się natomiast na ustaleniu, dlaczego zapytanie nie działa albo nie realizuje zamierzonej logiki. Poprawne wykonanie polecenia nie oznacza bowiem, że odpowiedź jest zgodna z pytaniem biznesowym.

Wsparcie AI jest szczególnie przydatne podczas pracy z nieznanym zapytaniem, przejmowania raportu po innym autorze czy szukania przyczyny nieoczekiwanej liczby rekordów. Model może uporządkować tok rozumowania i zwrócić uwagę na założenia, które łatwo przeoczyć. Początkującym pomaga zrozumieć zależność między konstrukcją zapytania a wynikiem; doświadczonym analitykom i programistom daje dodatkowy punkt widzenia przy diagnozowaniu problemu.

Trzeba jednak odróżnić rozmowę z asystentem od analizy wykonywanej przez narzędzie podłączone do bazy. Sam model językowy nie zna jej aktualnej zawartości i nie uruchamia zapytań bez odpowiedniej integracji. Może więc zaproponować wiarygodnie brzmiące wyjaśnienie, które nie pasuje do rzeczywistych danych lub zasad biznesowych.

Najlepiej traktować AI jako wsparcie analityka, a nie źródło ostatecznych rozstrzygnięć. Jego wartość polega na przyspieszeniu rozumienia problemu i poszukiwania rozwiązań. Ocena poprawności wyniku oraz decyzja o zastosowaniu zmian pozostają po stronie osoby pracującej z bazą.

Przygotowanie kontekstu: opis problemu, oczekiwany wynik i ograniczenia

Zanim poprosisz AI o analizę zapytania SQL, określ, co zapytanie ma ustalić i na czym polega problem. Polecenie „popraw to zapytanie” pozostawia modelowi zbyt wiele miejsca na domysły. Może on zaproponować rozwiązanie poprawne składniowo, ale niezgodne z definicją wskaźnika, zasadami raportowania lub ograniczeniami środowiska. Najważniejszym elementem kontekstu jest cel biznesowy, a nie sam tekst zapytania.

W Cognity często słyszymy pytania, jak przygotować opis zadania, by AI mogło pomóc w analizie SQL – odpowiadamy na nie także na blogu. Na początku rozróżnij trzy sytuacje: zapytanie nie wykonuje się, wykonuje się, lecz zwraca niewłaściwe wyniki, albo daje poprawny rezultat, ale działa zbyt wolno. Każda wymaga innego kierunku pracy. W pierwszej szukasz przeszkody uniemożliwiającej wykonanie, w drugiej — rozbieżności między logiką obliczeń a oczekiwaniem, w trzeciej — możliwości skrócenia czasu wykonania bez zmiany znaczenia wyniku. Jeśli problemów jest kilka, wskaż, który ma pierwszeństwo.

Opis zadania warto uporządkować wokół trzech elementów:

• Problem: napisz, co obserwujesz, od kiedy występuje rozbieżność i jakiego zakresu dotyczy. Zamiast „raport źle liczy sprzedaż” podaj, że miesięczna wartość sprzedaży jest wyższa od wartości w zatwierdzonym zestawieniu, mimo zastosowania tego samego okresu.
• Oczekiwany wynik: określ, co ma oznaczać pojedynczy wiersz wyniku, jakie informacje powinien zawierać i według jakich reguł mają powstawać obliczenia. Doprecyzuj zakres dat, poziom agregacji oraz istotne wyłączenia.
• Ograniczenia: wskaż, co wolno zmienić, a co musi pozostać bez zmian. Możesz na przykład dopuścić modyfikację wyłącznie treści zapytania, przy zachowaniu nazw kolumn, formatu wyniku i zgodności z określoną wersją silnika bazy danych.

Szczególnej uwagi wymagają pojęcia, które brzmią jednoznacznie, lecz mają różne definicje. „Aktywny klient” może oznaczać osobę z zakupem w ostatnich 30 dniach albo z co najmniej jednym opłaconym zamówieniem w bieżącym miesiącu. „Przychód” może uwzględniać zwroty lub je pomijać. AI nie powinno samodzielnie rozstrzygać takich kwestii. Jeśli definicja nie została ustalona, zaznacz tę niepewność i poproś o pytania doprecyzowujące zamiast przyjmowania założeń.

Ustal również zakres oczekiwanej pomocy: samo wyjaśnienie problemu, wskazanie możliwych przyczyn czy przygotowanie propozycji zmiany. Zaznacz, jeśli zadanie ma charakter wyłącznie analityczny i nie dopuszczasz operacji modyfikujących dane. Dobrze przygotowany kontekst wyznacza kryterium poprawności odpowiedzi: rozwiązanie ma realizować konkretny cel w podanych granicach, a nie tylko wyglądać jak poprawny SQL.

Dostarczanie materiałów do analizy: schemat, przykładowe dane (zanonimizowane) i metadane

Zapytanie SQL pokazuje, jakie operacje mają zostać wykonane, ale nie wyjaśnia w pełni, na jakich danych pracuje. Kolumna customer_id może być kluczem obcym, identyfikatorem z zewnętrznego systemu albo polem bez gwarancji spójności. Aby AI nie musiała zgadywać, warto przekazać jej trzy uzupełniające się materiały: schemat opisujący strukturę, próbkę pokazującą rzeczywiste właściwości danych oraz metadane wyjaśniające ich znaczenie i pochodzenie.

Schemat: tylko potrzebny fragment, ale z relacjami

Nie trzeba udostępniać definicji całej bazy. Zwykle wystarczy struktura tabel i widoków, do których odwołuje się analizowane zapytanie, wraz z istotnymi zależnościami. Najbardziej użyteczny jest tekstowy zapis DDL, na przykład instrukcje CREATE TABLE, lub zwięzły opis zachowujący te same informacje. Taki materiał jest łatwiejszy do jednoznacznego odczytania niż zrzut ekranu diagramu.

W opisie powinny znaleźć się:

• nazwy tabel i kolumn oraz dokładne typy danych, w tym precyzja liczb i rodzaj pól daty oraz czasu;
• klucze główne i obce, ograniczenia unikalności oraz dopuszczalność wartości NULL;
• relacje między tabelami, również te istniejące wyłącznie w logice aplikacji;
• definicje wykorzystywanych widoków i kolumn obliczanych, jeśli wpływają na analizowany wynik.

Odróżniaj ograniczenia wymuszane przez bazę od założeń biznesowych. Informacja „każdy klient powinien mieć jeden aktywny adres” nie jest równoważna ograniczeniu, które faktycznie uniemożliwia zapisanie dwóch takich adresów.

Próbka danych: mała, lecz zachowująca istotne przypadki

Pierwszych kilkanaście wierszy tabeli nie zawsze dobrze przedstawia problem. Lepsza jest niewielka próbka obejmująca zarówno typowe rekordy, jak i występujące w analizowanym przypadku odstępstwa: brakujące wartości, powtarzające się identyfikatory czy rekordy bez odpowiednika w powiązanej tabeli. Nie chodzi o projektowanie testów, lecz o pokazanie AI, z jakimi danymi rzeczywiście ma do czynienia.

Przykładowo, przy analizie połączenia klientów z zamówieniami przydatne będą dane klienta bez zamówień oraz klienta z kilkoma zamówieniami. Sama para rekordów połączonych w relacji jeden do jednego nie ujawni pełnego charakteru tej relacji. Próbkę można przekazać jako CSV, JSON lub krótkie instrukcje INSERT, wyraźnie rozróżniając NULL, pusty tekst i zero.

Usuwanie danych wrażliwych nie powinno niszczyć zależności potrzebnych do analizy. Jeśli zastępujesz identyfikatory, stosuj to samo mapowanie we wszystkich powiązanych tabelach. Zachowaj również istotne powtórzenia, kolejność zdarzeń i odstępy czasu. Samo zastąpienie nazwisk czy adresów e-mail nie gwarantuje anonimowości — osobę może nadal ujawniać kombinacja pozostałych atrybutów. Gdy bezpieczne udostępnienie próbki jest niemożliwe, lepiej przygotować dane syntetyczne odtwarzające jej ważne właściwości i oznaczyć je jako syntetyczne.

Metadane: znaczenie i pochodzenie danych

Do schematu i próbki dołącz nazwę oraz wersję silnika bazy, przybliżoną liczebność istotnych tabel i moment pobrania danych. Wyjaśnij też nieoczywiste konwencje: czy kwoty zapisano w złotych czy groszach, jaka strefa czasowa obowiązuje dla dat oraz co oznaczają kody statusów. Jeśli rekordy są oznaczane jako usunięte zamiast fizycznie kasowane, zaznacz tę zasadę.

Warto wskazać, czy próbka jest losowa, celowo dobrana czy ograniczona do konkretnego okresu. Dzięki temu model nie powinien traktować jej jako pełnego obrazu bazy. Materiały przekazuj wyłącznie w zakresie dopuszczonym przez zasady organizacji, bez haseł, tokenów, ciągów połączeniowych i niepotrzebnych danych poufnych.

Interpretacja komunikatów błędów i identyfikacja przyczyn: dialekty SQL, uprawnienia i typy danych

Komunikat błędu wskazuje, na czym silnik bazy danych przerwał wykonanie zapytania — nie zawsze jednak wyjaśnia pierwotną przyczynę problemu. Błąd zgłoszony przy słowie FROM może wynikać z brakującego przecinka wcześniej, a nieudana konwersja może dotyczyć pojedynczej wartości wśród tysięcy poprawnych rekordów. AI pomaga przełożyć treść komunikatu na hipotezy diagnostyczne, ale nie powinna przedstawiać ich jako potwierdzonej diagnozy.

Najważniejsze jest rozróżnienie, czy silnik nie rozumie składni, nie może odnaleźć obiektu lub uzyskać do niego dostępu, czy też nie potrafi wykonać operacji na konkretnych danych. Każda z tych sytuacji wymaga innego kierunku analizy. W Cognity omawiamy diagnostykę błędów SQL zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników.

Dialekt SQL: poprawna składnia nie jest uniwersalna

Zapytanie działające w jednym systemie może zostać odrzucone przez inny. PostgreSQL i MySQL obsługują ograniczanie liczby wierszy przez LIMIT, natomiast SQL Server udostępnia między innymi TOP. Różnią się również funkcje operujące na datach, sposoby łączenia tekstu oraz reguły cytowania identyfikatorów. Znaczenie ma także wersja silnika: funkcja dostępna w nowszym wydaniu nie musi istnieć w starszym.

Przy błędach składni AI powinna więc najpierw ocenić zgodność zapytania z konkretnym dialektem. Dopiero później warto szukać brakujących nawiasów, separatorów czy niepoprawnego użycia słów zastrzeżonych. Podświetlony fragment jest punktem, w którym parser nie mógł kontynuować analizy — rzeczywista usterka może znajdować się wcześniej.

Uprawnienia: brak dostępu to nie błąd zapytania

Komunikat o odmowie dostępu nie oznacza, że składnia lub logika SQL są niepoprawne. Problem może dotyczyć uprawnień do tabeli, widoku, schematu albo funkcji. Istotna jest również tożsamość używana przez bieżące połączenie: aplikacja i konsola administratora mogą wykonywać identyczne zapytanie jako różni użytkownicy lub z różnymi aktywnymi rolami.

AI może pomóc odróżnić brak obiektu od braku dostępu, lecz nie zawsze da się to ustalić na podstawie samego komunikatu. Niektóre systemy ograniczają widoczność metadanych, dlatego informacja o nieistniejącym obiekcie nie musi dowodzić, że obiekt rzeczywiście nie istnieje. Podobny objaw może też wynikać z połączenia z inną bazą lub odwołania do niewłaściwego schematu. Sugestia nadania szerokich uprawnień bez ustalenia przyczyny nie jest rzetelną diagnozą.

Typy danych: problem może ujawnić się dopiero podczas wykonania

Błędy typów pojawiają się między innymi przy porównywaniu niezgodnych wartości, konwersji tekstu na liczbę, interpretacji dat lub przekroczeniu zakresu typu liczbowego. Część silników wykonuje konwersje niejawne, inne wymagają jawnego określenia typu. To, co w jednym środowisku przejdzie bez błędu, w innym może zostać odrzucone albo zinterpretowane inaczej.

W tej kategorii AI powinna rozróżniać niezgodność zadeklarowanych typów od niepoprawnej zawartości danych. Kolumna tekstowa może zawierać głównie liczby, lecz pojedynczy pusty ciąg lub zapis z jednostką wystarczy, by konwersja zakończyła się błędem. Przy datach znaczenie mogą mieć ustawienia sesji i format wejściowy, a przy parametrach zapytania — typ przekazany przez sterownik aplikacji.

Wartość analizy AI zależy od tego, czy oddziela ona fakty wynikające z komunikatu od przypuszczeń. Dobra interpretacja wskazuje najbardziej prawdopodobną kategorię błędu, uzasadnia ją i określa, czego jeszcze nie da się rozstrzygnąć. Powinna też uwzględniać komunikat pochodzący bezpośrednio z silnika: ogólny wyjątek wyświetlony przez aplikację może ukrywać właściwy kod i opis błędu.

Propozycje poprawek: refaktoryzacja zapytań, walidacja logiki i bezpieczne modyfikacje

Poprawka SQL zaproponowana przez AI może usunąć błąd wykonania, a jednocześnie zmienić znaczenie wyniku. Dlatego przed jej przyjęciem warto rozdzielić trzy cele: naprawę błędu, uporządkowanie kodu i zmianę logiki biznesowej. Każdy wymaga innego uzasadnienia. Zapytanie, które działa, niekoniecznie odpowiada na właściwe pytanie, a krótszy zapis nie musi być czytelniejszy ani szybszy.

Refaktoryzacja: czytelniejszy kod bez zmiany znaczenia

Refaktoryzacja powinna zachować wynik zapytania, w tym liczbę wystąpień poszczególnych wierszy i sposób obsługi wartości NULL. AI może pomóc uporządkować aliasy, jawnie wskazać potrzebne kolumny lub podzielić złożone zapytanie na nazwane etapy za pomocą CTE. Takie zmiany ułatwiają przegląd kodu, ale same w sobie nie gwarantują poprawy wydajności.

Warto poprosić model najpierw o minimalną poprawkę, a dopiero osobno o wariant refaktoryzacji. Dzięki temu łatwiej ustalić, która modyfikacja usuwa problem, a która służy wyłącznie czytelności. Przydatne polecenie brzmi: „Zaproponuj najmniejszą zmianę rozwiązującą wskazany problem. Następnie pokaż osobny wariant porządkujący kod. Przy każdej zmianie opisz jej wpływ na wynik oraz założenia potrzebne do zachowania równoważności”.

Walidacja logiki: czy poprawka zachowuje sens zapytania?

Najwięcej ostrożności wymagają zmiany złączeń, filtrów i agregacji. Dodanie DISTINCT może ukryć zwielokrotnienie rekordów po złączeniu, zamiast usunąć jego przyczynę. Zastąpienie UNION przez UNION ALL zmienia sposób traktowania duplikatów, a zamiana COUNT(*) na COUNT(kolumna) wyklucza z liczenia wiersze, w których wskazana kolumna ma wartość NULL. Takich modyfikacji nie należy przedstawiać jako czysto kosmetycznych.

Przykładowo, jeśli zestawienie ma obejmować wszystkich klientów oraz ich opłacone zamówienia, warunek dotyczący statusu można umieścić w klauzuli ON:

SELECT k.id, z.id AS zamowienie_id
FROM klienci AS k
LEFT JOIN zamowienia AS z
  ON z.klient_id = k.id
 AND z.status = 'oplacone';

Przeniesienie tego warunku do WHERE wykluczyłoby klientów bez dopasowanego opłaconego zamówienia. To zmiana logiki, nie tylko miejsca zapisu filtra. AI powinno więc wyjaśnić, jaką regułę biznesową realizuje poprawka, zamiast ograniczać uzasadnienie do stwierdzenia, że zapytanie jest poprawne składniowo.

Bezpieczne modyfikacje danych

Propozycje UPDATE, DELETE i zmian struktury bazy należy traktować jako kod do przeglądu, nie jako polecenia gotowe do automatycznego wykonania. Przed operacją modyfikującą dane warto przygotować SELECT z odpowiadającym jej warunkiem wyboru rekordów. Pozwala to ocenić zakres zmiany, choć nie gwarantuje, że pozostanie on identyczny, jeśli w międzyczasie inne procesy zmodyfikują dane.

Bezpieczna propozycja powinna wskazywać zakres operacji, sposób jej zatwierdzenia oraz możliwość wycofania. Gdy silnik i rodzaj polecenia na to pozwalają, zmiany można objąć transakcją. Nie należy jednak zakładać, że ROLLBACK cofnie każdą operację — szczególnie polecenia DDL mogą podlegać innym zasadom. AI nie powinno również usuwać ograniczeń integralności ani wyłączać zabezpieczeń tylko po to, by polecenie przestało zgłaszać błąd.

Testy regresji i weryfikacja wyników: przypadki testowe, porównania i automatyzacja

Zapytanie poprawione przez AI może wykonać się bez błędu, a mimo to zwrócić nieprawidłowy wynik. Zmiana warunku filtrowania może wykluczyć część rekordów, a inne połączenie tabel — zwielokrotnić kwoty w zestawieniu. Dlatego brak komunikatu błędu nie jest dowodem poprawności SQL. Potrzebne są zarówno sprawdzenie zgodności wyniku z wymaganiami, jak i testy wykrywające niezamierzone skutki zmiany.

Weryfikacja odpowiada na pytanie: „Czy zapytanie zwraca to, czego oczekujemy?”. Testy regresji sprawdzają natomiast, czy poprawka nie naruszyła zachowań, które wcześniej działały prawidłowo. AI może pomóc przygotować scenariusze i porównania, ale nie powinno samodzielnie wyznaczać, co jest poprawnym wynikiem biznesowym.

Przypadki testowe, które ujawniają błędy logiki

Najbardziej użyteczny zestaw testowy nie musi być duży. Powinien obejmować sytuacje, w których nawet drobna zmiana SQL wpływa na rezultat. Dla każdego przypadku warto zapisać oczekiwane wiersze lub konkretną właściwość wyniku, na przykład jeden rekord na klienta.

• Przypadek typowy: kilka rekordów z jednoznacznym, niezależnie obliczonym wynikiem.
• Brak danych i brak dopasowania: pusta tabela, filtr bez trafień lub rekord bez powiązania w drugiej tabeli.
• Wartości NULL: sprawdzenie, czy brak wartości jest właściwie obsługiwany w filtrach, obliczeniach i agregacjach.
• Wielokrotne dopasowania: duplikaty oraz relacje jeden-do-wielu, które mogą zwiększać liczbę wierszy i zawyżać sumy.
• Wartości graniczne: daty na początku i końcu okresu, wartości zerowe oraz liczby dokładnie na progu warunku.

Można poprosić AI o wskazanie, które z tych przypadków są istotne dla zmienionego zapytania i jaki błąd każdy z nich wykrywa. Oczekiwanych rezultatów nie należy jednak wyprowadzać wyłącznie z testowanego SQL — test mógłby wtedy utrwalić tę samą pomyłkę.

Porównanie wyników przed zmianą i po niej

Obie wersje zapytania należy uruchomić na tym samym, niezmiennym zestawie danych. Inaczej różnice mogą wynikać z nowych transakcji lub aktualizacji rekordów, a nie z poprawki. Jeśli stara wersja zawierała błąd, nie jest wzorcem dla całego wyniku: oczekiwane odstępstwa trzeba opisać osobno.

Sama zgodność liczby wierszy lub sumy końcowej nie wystarcza. Porównanie powinno uwzględniać także liczbę wystąpień identycznych rekordów — operacje zbiorowe usuwające duplikaty mogą zamaskować problem. Bez ORDER BY nie należy traktować kolejności wierszy jako gwarantowanej. Przy liczbach zmiennoprzecinkowych warto ustalić uzasadnioną tolerancję zamiast wymagać bezwarunkowej równości.

Automatyzacja kontroli i rola AI

Sprawdzone przypadki warto zamienić w automatyczne testy uruchamiane po każdej zmianie zapytania. Wydzielone środowisko testowe powinno odtwarzać stałe dane, wykonywać SQL i sprawdzać zapisane oczekiwania. W procesie CI niezgodność może blokować wdrożenie, a raport powinien wskazywać konkretny test oraz różnicę między wynikiem oczekiwanym a otrzymanym.

AI może przygotować szkielety asercji, zaproponować brakujące scenariusze i pomóc objaśnić raport różnic. Ostateczną podstawą akceptacji pozostają jednak wykonane testy i zatwierdzone reguły biznesowe, nie zapewnienie modelu, że zapytania są równoważne.

Optymalizacja i tuning: plany zapytań, indeksy, statystyki i antywzorce

Zapytanie może zwracać poprawny wynik, a mimo to odczytywać miliony zbędnych wierszy, wykonywać kosztowne sortowania lub nadmiernie obciążać pamięć. W tuningu SQL AI pomaga przede wszystkim łączyć informacje z planu wykonania z konstrukcją zapytania i właściwościami bazy. Potrafi wskazać prawdopodobne wąskie gardła i zaproponować kierunki optymalizacji, ale na podstawie samego tekstu SQL nie rozstrzygnie, która zmiana rzeczywiście przyspieszy działanie.

Plan zapytania: przewidywania a rzeczywisty przebieg

Plan szacowany pokazuje, jak silnik zamierza pobrać i połączyć dane oraz jakie koszty przewiduje. Plan rzeczywisty, zależnie od systemu bazodanowego i sposobu jego zebrania, dostarcza również informacji o przebiegu wykonania — na przykład liczbie przetworzonych wierszy, czasach operacji czy odczytach. Koszt podany przez optymalizator nie jest bezpośrednią prognozą czasu w sekundach.

AI może pomóc zauważyć duże rozbieżności między szacowaną a rzeczywistą liczbą wierszy, wielokrotnie wykonywane operacje lub sortowania korzystające z przestrzeni dyskowej. Takie sygnały pozwalają zawęzić poszukiwania, lecz nie przesądzają o przyczynie. Pełny skan tabeli nie musi być błędem: przy odczycie znacznej części danych bywa tańszy niż użycie indeksu. Warto też pamiętać, że pozyskanie planu rzeczywistego często wymaga uruchomienia zapytania, co może obciążyć bazę, a przy operacjach zapisu również zmienić dane.

Indeksy: szybszy odczyt ma swój koszt

Analizując warunki filtrowania, łączenia i sortowania, AI może zaproponować indeksy odpowiadające sposobowi korzystania z danych. W przypadku indeksów wielokolumnowych znaczenie mają kolejność kolumn, rodzaje warunków oraz możliwości konkretnego silnika. Indeks pokrywający zapytanie może ograniczyć dodatkowe odczyty tabeli, ale zajmuje miejsce i zwiększa koszt utrzymania danych.

Nie warto automatycznie dodawać każdego sugerowanego indeksu. Najpierw należy sprawdzić, czy podobny już istnieje i czy korzyść dotyczy często wykonywanych, istotnych zapytań. Nadmiar indeksów spowalnia operacje zapisu i zwiększa zapotrzebowanie na przestrzeń dyskową. Rekomendację AI trzeba więc oceniać w kontekście całego obciążenia bazy, nie tylko jednego wolnego odczytu.

Statystyki: podstawa decyzji optymalizatora

Statystyki opisują między innymi rozkład wartości w kolumnach i pomagają oszacować, ile wierszy spełni dany warunek. Nieaktualne lub niewystarczające informacje mogą prowadzić do nietrafnego wyboru sposobu łączenia tabel albo dostępu do danych. AI może wskazać taki scenariusz, gdy plan pokazuje duży rozdźwięk między szacunkami a wykonaniem.

Aktualizacja statystyk nie jest jednak uniwersalnym rozwiązaniem. Problem może wynikać również z nierównomiernego rozkładu danych, zależności między kolumnami lub wykorzystania planu przygotowanego dla innych wartości parametrów. Dostępne mechanizmy diagnostyczne i naprawcze zależą od silnika bazy.

Antywzorce: sygnały do sprawdzenia, nie bezwzględne zakazy

AI dobrze sprawdza się we wstępnym przeglądzie konstrukcji, które często zwiększają koszt zapytań. Należą do nich pobieranie niepotrzebnych kolumn, zbędne usuwanie duplikatów, nadmiarowe sortowanie czy funkcje i konwersje typów w warunkach, które mogą utrudniać wykorzystanie indeksów. Każdy taki przypadek wymaga oceny: sam wygląd zapytania nie dowodzi problemu wydajnościowego.

Najbardziej użyteczna rekomendacja AI wskazuje konkretną obserwację, hipotezę przyczyny i spodziewany efekt zmiany. O jej wartości decydują pomiary w reprezentatywnych warunkach: czas wykonania, liczba odczytów, zużycie procesora oraz wpływ na równoległe operacje. Celem tuningu jest mniejszy koszt obsługi rzeczywistego obciążenia, a nie uzyskanie pozornie prostszego zapytania lub planu z większą liczbą odwołań do indeksów.

Przykładowe prompty oraz lista kontrolna informacji, które warto przekazać AI

Dobry prompt do pracy z SQL określa nie tylko problem, lecz także zadanie dla modelu: wyjaśnienie działania zapytania, wskazanie możliwych przyczyn błędu, sprawdzenie poprawności obliczeń albo ocenę wydajności. Zamiast prosić ogólnie o „poprawę SQL”, warto wskazać jeden cel i oczekiwaną formę odpowiedzi. Dzięki temu łatwiej oddzielić diagnozę od propozycji zmian.

Prompty dopasowane do zadania

Poniższe szablony można uzupełnić własnymi materiałami. Fragmenty w nawiasach kwadratowych oznaczają informacje do zastąpienia, a nie gotowe założenia o bazie. W Cognity łączymy teorię z praktyką – dlatego tworzenie promptów do pracy z SQL ćwiczymy także na szkoleniach.

Analiza danych i wybór sposobu obliczeń

„Pracuję w [silnik i wersja bazy]. Chcę odpowiedzieć na pytanie biznesowe: [pytanie]. Dostępne dane opisuję poniżej: [opis tabel, relacji i znaczenia pól]. Wynik ma zawierać [miary, wymiary i zakres czasu], a jeden wiersz ma reprezentować [jednostka analizy]. Zaproponuj sposób analizy. Zanim przygotujesz zapytanie, wskaż niejednoznaczności i zadaj pytania o brakujące informacje. Nie zakładaj istnienia nieopisanych kolumn.”

Diagnoza błędu wykonania

„Pomóż zdiagnozować błąd w zapytaniu działającym w [silnik i wersja]. Przekazuję treść zapytania, pełny komunikat błędu oraz opis użytych obiektów. Oddziel fakty wynikające z materiałów od hipotez. Uszereguj możliwe przyczyny według prawdopodobieństwa i dla każdej wskaż sposób sprawdzenia. Zaproponuj minimalną poprawkę, która zachowa zamierzony wynik.”

Sprawdzenie wyniku, który wygląda nieprawidłowo

„Zapytanie wykonuje się bez błędu, ale zwraca [zaobserwowana rozbieżność]. Oczekuję [wynik i jego uzasadnienie]. Poniżej podaję zapytanie oraz mały, zanonimizowany przykład danych. Sprawdź, czy logika odpowiada opisanej regule biznesowej. Wskaż, na którym etapie może powstawać rozbieżność, i zaproponuj przypadki testowe, które pozwolą to potwierdzić.”

Ocena możliwości przyspieszenia zapytania

„Oceń możliwości optymalizacji poniższego zapytania w [silnik i wersja]. Załączam plan wykonania i dostępne informacje o tabelach oraz indeksach. Celem jest [oczekiwana poprawa], bez zmiany wyników. Ograniczenia obejmują [niedozwolone modyfikacje]. Oddziel obserwacje potwierdzone planem od przypuszczeń. Dla każdej propozycji podaj sposób pomiaru efektu; nie deklaruj przyspieszenia bez testów.”

Lista kontrolna przed wysłaniem promptu

• Cel: czy wiadomo, jaką decyzję lub czynność ma ułatwić odpowiedź?
• Środowisko: czy podano silnik, wersję bazy i istotne ograniczenia dostępu?
• Materiały: czy dołączono zapytanie oraz informacje potrzebne do konkretnego zadania, zamiast całej dokumentacji bazy?
• Oczekiwany rezultat: czy opisano znaczenie wyniku i kryterium uznania rozwiązania za poprawne?
• Granice zmian: czy wskazano, czego nie wolno modyfikować i czy propozycje mają dotyczyć wyłącznie odczytu?
• Poufność: czy usunięto dane osobowe, hasła, tokeny i inne informacje, których nie można przekazać używanemu narzędziu?
• Forma odpowiedzi: czy model ma przedstawić diagnozę, minimalną poprawkę, pytania doprecyzowujące czy plan testów?

Warto dopisać do każdego szablonu: „Jeśli brakuje danych do wiarygodnej oceny, nazwij te braki zamiast je uzupełniać domysłami”. Taka instrukcja ułatwia ocenę odpowiedzi, ale nie zastępuje sprawdzenia propozycji AI przed zastosowaniem ich w bazie.

Power BI zaawansowany – jak tworzyć profesjonalne modele danych 03 października 2026

Power BI zaawansowany – DAX w praktyce: miary, kalkulacje i analiza danych 01 października 2026