Wzorce optymalizacji SQL

Wzorce optymalizacji SQL obejmują podłączenie serwera MCP bazy danych do Cursora, Claude Code lub Codeksa, dzięki czemu asystent czyta prawdziwy plan wykonania, prawdziwe statystyki tabel i prawdziwe użycie indeksów zamiast zgadywać, a następnie zamienia te dane w uszeregowane poprawki wąskich gardeł, rekomendacje indeksów i przepisania podzapytań na funkcje okna zachowujące wyniki.

Zapytanie do dashboardu, które na Twoim laptopie wykonywało się w 40 ms, w produkcji przekracza limit czasu po 12 sekundach. Tabela urosła z 50 tys. wierszy do 80 mln, optymalizator po cichu przełączył się na skanowanie sekwencyjne, a Twój APM świeci się na czerwono. Wklejasz zapytanie do asystenta AI i dostajesz pewną siebie odpowiedź „dodaj indeks na customer_id” — tyle że ten indeks już istnieje, a planner i tak go ignoruje.

Rozwiązaniem jest przestać zgadywać. Kiedy podłączysz serwer MCP bazy danych do Cursora, Claude Code lub Codeksa, asystent czyta Twój rzeczywisty plan wykonania, Twoje rzeczywiste statystyki tabel i Twoje rzeczywiste użycie indeksów — a potem proponuje zmiany, które możesz zweryfikować na prawdziwych liczbach zamiast na ludowych wierzeniach.

Co wyniesiesz ze wzorców optymalizacji SQL

• Podłączony serwer MCP Postgresa, dzięki któremu asystent czyta żywy schemat i wynik EXPLAIN zamiast halucynować
• Gotowy prompt, który zamienia zrzut EXPLAIN (ANALYZE, BUFFERS) w uporządkowaną listę wąskich gardeł
• Prompt rekomendujący indeksy na podstawie rzeczywistych wzorców zapytań — i odrzucający te zbędne
• Prompt przepisujący podzapytanie na funkcję okna z zachowaniem wyników
• Jasne wyczucie, kiedy rady AI wprowadzą Cię w błąd (małe tabele, zmaterializowane CTE, efekty uboczne EXPLAIN ANALYZE)

Najpierw podłącz serwer MCP bazy danych

Bez serwera MCP asystent rozumuje o schemacie, którego nie widzi. Z nim może uruchomić EXPLAIN, zajrzeć do pg_stat_user_indexes i sprawdzić statystyki kolumn bezpośrednio. Konfiguracja jest identyczna w Cursorze, Claude Code i Codeksie — wszystkie czytają tę samą konfigurację MCP; różni się tylko lokalizacja pliku.

Do pracy lokalnej i operacji świadomych schematu Prisma Postgres MCP jest dostarczany w ramach Prisma CLI i nie wymaga dodatkowej instalacji:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "prisma", "mcp"]
    }
  }
}

Notatka

Stary pakiet @modelcontextprotocol/server-postgres jest przestarzały i nie jest już utrzymywany — nie sięgaj po niego. Dla baz produkcyjnych, w których chcesz, by Row Level Security było respektowane, użyj Supabase MCP (npx -y @supabase/mcp-server-supabase). Dla Amazon Aurora/RDS AWS udostępnia oficjalny serwer: uvx awslabs.postgres-mcp-server@latest (oparty na Pythonie, więc poleceniem jest uvx, a nie npx). MySQL nie ma serwera MCP od producenta; istnieją opcje społecznościowe w stylu mongodb-mcp-server, ale dla MySQL większość zespołów wkleja wynik EXPLAIN bezpośrednio do promptu.

Wrzuć konfigurację do .cursor/mcp.json (Cursor), zarejestruj ją przez claude mcp add (Claude Code) lub dodaj do ~/.codex/config.toml w sekcji [mcp_servers.postgres] (Codex). Potem opisany niżej przepływ pracy jest wszędzie taki sam.

Czytaj plan wykonania jak doświadczony DBA

Pojedynczym ruchem o największej dźwigni jest podanie asystentowi prawdziwego planu EXPLAIN (ANALYZE, BUFFERS) i poproszenie go o uszeregowanie problemów według kosztu. Ogólne prompty „zoptymalizuj to zapytanie” dają ogólne porady; prompt oparty na planie daje konkrety.

Gotowy prompt do analizy planu wykonania

Using the Postgres MCP server, run EXPLAIN (ANALYZE, BUFFERS, VERBOSE, FORMAT TEXT) on the query below against a staging copy, then rank the problems by actual time, not estimated cost.

For each bottleneck tell me: (1) the node (seq scan, nested loop, sort, hash) and how long it took, (2) why the planner chose it — check pg_stats for the relevant columns and tell me if the row estimate is off by more than 10x, (3) the single highest-impact fix, and (4) the exact DDL or query rewrite to apply.

Do NOT suggest an index that already exists — query pg_indexes for the table first. Flag any node where Rows Removed by Filter exceeds the rows returned.

SELECT c.customer_name,
       COUNT(o.order_id)                  AS order_count,
       SUM(oi.quantity * oi.unit_price)   AS total_spent
FROM customers c
JOIN orders o       ON c.customer_id = o.customer_id
JOIN order_items oi ON o.order_id   = oi.order_id
WHERE o.order_date >= DATE '2024-01-01'
GROUP BY c.customer_id, c.customer_name
ORDER BY total_spent DESC
LIMIT 100;

To właśnie więzy oparte na danych — „sprawdź pg_stats”, „nie sugeruj istniejących indeksów”, „oznacz Rows Removed by Filter” — odróżniają tę odpowiedź od tego, co zwróciłaby wyszukiwarka. Rozjazd szacunku liczby wierszy o 10x niemal zawsze oznacza nieaktualne statystyki (ANALYZE tabeli), a nie brakujący indeks — i asystent wychwyci to tylko wtedy, gdy każesz mu spojrzeć.

Rekomenduj indeksy na podstawie rzeczywistego użycia

Gdy plan wskaże na skanowanie, kolejne pytanie brzmi: który indeks — i czy już nie masz takiego, który wykonuje to zadanie. Tu czytanie pg_stat_user_indexes bije intuicję: zespoły rutynowo dźwigają po kilkanaście nieużywanych indeksów, które spowalniają każdy zapis.

Cursor

W trybie Agent, z podłączonym Postgres MCP, dołącz schemat i folder migracji jako kontekst i pozwól agentowi zarówno zdiagnozować, jak i napisać migrację:

@migrations Using the Postgres MCP, query pg_stat_user_indexes and
pg_stat_user_tables for the orders and order_items tables. Then:

- List indexes with idx_scan = 0 over the last stats window (candidates to drop)
- Propose the minimal set of indexes for the WHERE/JOIN/ORDER BY in
  the slow dashboard query, preferring one composite index over several
  single-column ones where the leading column is selective
- Write the CREATE INDEX CONCURRENTLY statements as a new migration file
- Estimate the write-amplification cost of each new index

Claude Code

Wskaż Claude Code katalog migracji (katalog, nie plik) i steruj nim z terminala:

claude --add-dir db/migrations

Następnie w sesji:

Using the Postgres MCP server, analyze index usage on orders and
order_items via pg_stat_user_indexes. Recommend indexes for the slow
dashboard query, reject any that duplicate an existing index, and write
them as a timestamped migration using CREATE INDEX CONCURRENTLY so we
don't lock the table in production.

Codex

Codex czyta tę samą konfigurację MCP z ~/.codex/config.toml. Uruchom go lokalnie z zapisem ograniczonym do workspace, by wygenerować migrację jako gotowy do przejrzenia diff:

codex --sandbox workspace-write -c approval_policy=on-request \
  "Using the Postgres MCP server, query pg_stat_user_indexes for orders
   and order_items, propose the minimal index set for the slow dashboard
   query, and write CREATE INDEX CONCURRENTLY statements to a new file in
   db/migrations. Reject indexes that duplicate existing ones."

codex exec utrzymuje przebieg w trybie nieinteraktywnym i pozostawia zmianę jako diff, który przeglądasz przed zastosowaniem — idealne do wpięcia w worktree lub check CI.

Gotowy prompt do rekomendacji indeksów

From the pg_stat_user_indexes and pg_stats data you just read, recommend the smallest set of indexes that covers this query’s WHERE, JOIN, and ORDER BY clauses. Prefer a single composite index when the leading column is selective (check n_distinct). For each recommendation, give me the CREATE INDEX CONCURRENTLY statement, the expected plan change, and one sentence on the write cost. Then list any existing index with zero scans that I should consider dropping. If a partial index (WHERE status = 'active') would be smaller and still cover the hot path, prefer it.

Wzorce przepisywania, z których optymalizator Cię nie wybawi

Część wolnych zapytań to nie problem indeksowania — to problem kształtu. Skorelowane podzapytania, które uruchamiają się ponownie dla każdego wiersza, to klasyczny przypadek, a lekarstwem jest funkcja okna. Zawsze proś asystenta, by udowodnił, że przepisana wersja zwraca identyczne wiersze.

Gotowy prompt do przepisania podzapytania na funkcję okna

Rewrite this correlated subquery as a window function and prove the results are identical. Show me the rewritten query, then write a verification query using EXCEPT in both directions that returns zero rows when the outputs match. Explain why the window version avoids the per-row re-execution.

SELECT customer_id, order_date, order_amount,
       (SELECT SUM(o2.order_amount)
          FROM orders o2
         WHERE o2.customer_id = o1.customer_id
           AND o2.order_date <= o1.order_date) AS running_total
FROM orders o1;

Asystent powinien zwrócić oczywistą postać SUM(...) OVER (PARTITION BY customer_id ORDER BY order_date) — ale to weryfikacja EXCEPT w obie strony jest tym, co naprawdę się liczy. Domyślne ramki okna różnią się od naiwnego podzapytania (RANGE kontra ROWS, obsługa remisów przy równym order_date), a po cichu zmienione wyniki to najdroższy rodzaj „optymalizacji”.

Konkretnie dla PostgreSQL 18 dopominaj się o właściwy typ indeksu pod dany wzorzec dostępu, zamiast wszędzie wstawiać B-tree:

-- Indeks częściowy dla gorącej ścieżki (tylko aktywne wiersze) — mniejszy, szybszy
CREATE INDEX CONCURRENTLY idx_active_customers
  ON customers (customer_id) WHERE status = 'active';

-- GIN dla zawierania JSONB / wyszukiwania pełnotekstowego
CREATE INDEX CONCURRENTLY idx_product_attributes
  ON products USING gin (attributes);

-- BRIN dla danych naturalnie uporządkowanych w czasie, tylko-do-dopisywania — maleńki na dysku
CREATE INDEX CONCURRENTLY idx_events_created_at
  ON events USING brin (created_at);

Strategiczna denormalizacja dla ścieżek ciężkich odczytowo

Gdy złączenie jest gorące, a leżące pod nim wiersze rzadko się zmieniają, utrzymywana tabela podsumowań bije ponowne agregowanie przy każdym żądaniu. Poproś asystenta o wygenerowanie zarówno tabeli, jak i wyzwalacza, który utrzymuje ją w poprawnym stanie — to o wyzwalaczu ludzie zapominają, a nieaktualne podsumowanie jest gorsze niż wolne zapytanie.

Gotowy prompt do denormalizacji

This schema is 95% reads. Propose a denormalized customer_order_summary table (lifetime orders, lifetime value, last order date) maintained by a trigger on orders. Write the table DDL, the AFTER INSERT OR UPDATE OR DELETE trigger function, and a one-time backfill query. Then tell me the failure mode if the trigger and a bulk COPY race, and how to reconcile drift with a nightly check.

Liczenia przybliżone: poznaj swój silnik

Subtelna pułapka dokładności: APPROX_COUNT_DISTINCT() nie jest natywną funkcją PostgreSQL ani MySQL. Istnieje w BigQuery, Snowflake i Sparku, więc sugestie AI, które ją zawierają, na czystym Postgresie rzucą błędem function approx_count_distinct does not exist.

• BigQuery / Snowflake: APPROX_COUNT_DISTINCT(customer_id) jest natywne — używaj śmiało.
• PostgreSQL: zainstaluj rozszerzenie hll i używaj hll_cardinality(hll_add_agg(hll_hash_bigint(customer_id))) albo pogódź się z dokładnym COUNT(DISTINCT ...) wspartym indeksem pokrywającym.
• MySQL: nie ma wbudowanego przybliżonego liczenia odrębnych wartości; użyj dokładnego COUNT(DISTINCT ...) lub utrzymuj tabelę licznikową.

To dokładnie ten rodzaj błędu między silnikami, któremu zapobiega podłączony serwer MCP — asystent może potwierdzić, że funkcja istnieje, zanim ją zaproponuje.

Kiedy zawodzą porady optymalizacyjne SQL

Tryby awarii, które gryzą w produkcji

• Optymalizator ignoruje Twój błyszczący nowy indeks. Zwykle to nieaktualne statystyki — uruchom ANALYZE <table> i sprawdź plan ponownie. Jeśli szacunek nadal jest błędny, planner może odrzucać indeks, bo predykat nie jest sargowalny (np. WHERE date_trunc('day', created_at) = ... nie może użyć zwykłego indeksu na created_at).
• Zmaterializowane (MATERIALIZED) CTE szkodzą na małych wejściach. Wymuszanie materializacji niweczy przepychanie predykatów w dół. Na 500-wierszowym CTE optymalizatorowi lepiej było wstawić je inline — materializuj tylko wtedy, gdy CTE jest duże i odwołujesz się do niego wielokrotnie.
• EXPLAIN ANALYZE naprawdę wykonuje zapytanie. Przy UPDATE/DELETE/INSERT zatwierdza efekty uboczne. Owiń je w BEGIN; ... ROLLBACK; na kopii staging, nigdy na danych produkcyjnych.
• CREATE INDEX bez CONCURRENTLY blokuje tabelę. Na obciążonej tabeli produkcyjnej to awaria. Zawsze używaj CONCURRENTLY (nie może działać wewnątrz bloku transakcji, więc nie zmieści się w pojedynczym kroku migracji — zaplanuj to).
• Serwer MCP potrafi pisać. Jeśli przyznasz dostęp do zapisu, źle odczytany prompt może naprawdę zrobić DROP INDEX. Do prac analitycznych kieruj poświadczenia MCP na replikę odczytu lub kopię staging.

Dokąd pójść dalej ze wzorcami SQL

Wzorce migracji Generuj i przeglądaj bezpieczne, odwracalne migracje — w tym budowy indeksów CONCURRENTLY.

Wzorce ORM Powstrzymaj ORM przed generowaniem zapytań N+1 i nieindeksowanych skanów za Twoimi plecami.

Wzorce NoSQL Modeluj i odpytuj magazyny dokumentów i klucz-wartość z AI, gdy model relacyjny nie pasuje.

Wzorce debugowania Zamień czerwone dashboardy APM i bezużyteczne logi w poprawki sięgające przyczyny dzięki AI.