Långsam SQL i produktion är brutalt. En fråga kan sluka I/O, spika CPU och plötsligt blir varje “snabb” sida en laddningssnurra. Och de vanliga råden (“lägg till ett index”, “undvik SELECT *”) löser sällan den verkliga boven som gömmer sig i planen.
Den här slow SQL queries är byggd för data engineers som ansvarar för prestandaregressioner i datalagret, backendutvecklare som försöker stoppa en enskild endpoint från att tajma ut, och DBA:er som behöver evidensbaserade omskrivningar som behåller semantiken helt intakt. Resultatet är en planstyrd diagnos plus en logiskt ekvivalent omskriven fråga, med en tajt plan‑mot‑plan‑jämförelse som visar vad som ändrades och varför.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det här får du |
|---|---|---|
|
|
|
Hela AI-prompten: SQL-omsrivning för snabbare exekvering baserat på exekveringsplan
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[LANGSAM_FORGFRAGAN] |
Ange hela SQL-frågan som just nu har prestandaproblem och behöver optimeras. Till exempel: "SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'West') AND order_date > '2023-01-01';"
|
|
[TABELLSTRUKTURER] |
Ange schemadetaljer för alla tabeller som ingår i frågan, inklusive kolumnnamn, datatyper och index. Till exempel: "Tabell: orders (id INT PRIMARY KEY, customer_id INT, order_date DATE, total_amount DECIMAL, INDEX idx_order_date(order_date))"
|
|
[RADANTAL] |
Ange ungefärligt antal rader för varje tabell som ingår i frågan, så att datavolym och kardinalitet kan bedömas. Till exempel: "orders: ~1 000 000 rader, customers: ~50 000 rader"
|
|
[DATABASSYSTEM] |
Ange vilken databasmotor och version som används, eftersom optimeringsstrategier kan skilja sig åt beroende på system. Till exempel: "PostgreSQL 15.2"
|
|
[EXEKVERINGSPLAN] |
Ange hela exekveringsplanen för frågan, inklusive operatordetaljer, kostnader, uppskattat antal rader och faktiskt antal bearbetade rader. Till exempel: "Seq Scan on orders (cost=0.00..12345.67 rows=1000000 width=50) Filter: (order_date > '2023-01-01')"
|
|
[PRESTANDAKRAV] |
Beskriv de konkreta prestandamål eller begränsningar som gäller, till exempel acceptabel körtid eller gränser för resursanvändning. Till exempel: "Minska frågans körtid till under 500 ms och håll minnesanvändningen under 1 GB."
|
|
[KONTEXT] |
Ange eventuell ytterligare kontext om frågan, till exempel dess roll i applikationen, hur ofta den körs eller kända datamönster. Till exempel: "Den här frågan ingår i en daglig rapportgenerering och körs vanligtvis under lågtrafiktid på en datamängd med kraftig skevhet i kolumnen 'region'."
|
Proffstips för bättre resultat med AI-prompten
- Ta med den faktiska planen, inte bara SQL:en. Klistra in hela exekveringsplansutskriften (helst med faktiska rader/tid), samt databasmotor och version. Till exempel: “PostgreSQL 15, EXPLAIN (ANALYZE, BUFFERS) output nedan.” Utan detta kommer prompten med rätta att be om saknade uppgifter eftersom den är byggd för att koppla ändringar till operatorer.
- Ge kardinalitetskontext som planen inte kan förklara på egen hand. Lägg till antal rader per tabell, ungefärlig selektivitet för viktiga predikat och om filtervärdena är vanliga eller sällsynta. En bra följdfråga att använda: “Anta orders=120M rader, customers=8M; status=’REFUNDED’ är ~0,7% av raderna; created_at är kraftigt skevt mot senaste datum.”
- Säg vad “snabbt” betyder i din verklighet. Ange mål-latens och arbetslastens form (enskilt OLTP-anrop vs batch/rapportering). Testa: “Mål: p95 under 150 ms vid 50 QPS; undvik höga minnesspikar eftersom detta körs på en delad primär.” Det ändrar vilka avvägningar som är acceptabla.
- Iterera med kontrollerade varianter. Efter första svaret, be: “Behåll samma semantik, men ta fram två alternativa omskrivningar: en som prioriterar färre läsningar och en som prioriterar lägre CPU.” Eller: “Gör alternativ 1 mer aggressivt med ett nytt index, och alternativ 2 konservativt med enbart SQL-ändringar.”
- Använd den för att rimlighetskontrollera planstabilitet, inte bara omskrivningen. Om planen skiftar mellan körningar, säg det och be den diagnosticera varför. En praktisk uppföljning: “Anta planinstabilitet mellan hash join och nested loop beroende på parametervärde; föreslå en omskrivning som är mindre känslig för skevhet och förklara vilken statistik som ska uppdateras.”
Vanliga frågor
Databasadministratörer (DBA:er) använder den för att omvandla en exekveringsplan till en exakt uppsättning ändringar som går att motivera vid incidentgenomgångar. Backendingenjörer förlitar sig på den när en enskild endpoint-fråga måste skrivas om utan att resultatet ändras (ingen “nästan samma”-logik). Data engineers använder den för att stabilisera warehouse- och rapportfrågor där fel i radestimat och skevhet kan få körtider att explodera utan att det märks direkt. Teknikledare med fokus på prestanda använder plan‑mot‑plan‑jämförelsen för att skapa samsyn i teamet om vad som förbättrades och vad som ska mätas härnäst.
E-handel och marknadsplatser får värde när produkt-, lager- och ordertabeller växer snabbt och en join-tung fråga börjar dra ner checkout eller sök. Prompten hjälper dig att hålla semantiken stabil samtidigt som den minskar I/O, vilket oftast är den verkliga smärtan i skala. SaaS-bolag gynnas när multi-tenant-filtrering och frågor om “senaste aktivitet” skapar dyra sorteringar eller nested loops som exploderar vid peak-trafik. Fintech- och betalningsteam använder den för korrekthetskritiska omskrivningar där “snabbare” inte får ske på bekostnad av edge-case-korrekthet. Medie- och innehållsplattformar ser vinster i feed-, rekommendations- och analysfrågor där skeva predikat och heta partitioner snedvrider kardinalitet.
En typisk prompt som “Skriv om den här SQL:en så att den går snabbare” misslyckas eftersom den: saknar bevis i exekveringsplanen som behövs för att koppla ändringar till en specifik operator eller accessväg, ger ingen struktur för att validera logisk ekvivalens (så subtil semantik kan ändras), ignorerar kardinalitet och fel i radestimat som styr join-ordning och minnesanvändning, producerar generella “best practices” i stället för en planmedveten omskrivning, och missar faktorer bakom planinstabilitet som skevhet och statistikens hälsa som kan radera förbättringen på verklig data.
Ja, men anpassningen sker genom det du klistrar in tillsammans med prompten, inte via ifyllnadsvariabler (den här prompten har noll inbyggda variabler). De mest effektfulla tilläggen är databasmotor/version, exakt exekveringsplansutskrift (helst med actuals), tabellstorlekar och prestandamålet (p95-latens, batch-körtid eller resurstak). Om parametrar eller skevhet spelar roll, ta med två exempel på bindvärden: ett “vanligt” och ett “sällsynt”. En bra uppföljningsbegäran är: “Generera två omskrivningar: en med enbart SQL och en som inkluderar minsta möjliga indexändring som direkt förbättrar den långsamma operatorn; lista sedan valideringsfrågor för att bekräfta identiska resultat.”
Det största misstaget är att bara klistra in SQL:en och utelämna planen — i stället för “Här är min fråga” ska du ge “Här är min fråga plus EXPLAIN (ANALYZE, BUFFERS)-output och Postgres 15.” Ett annat vanligt fel är att inte ange prestandamålet; “gör den snabb” är otydligt, medan “minska läsningar; mål p95 under 200 ms” ger prompten en tydlig optimeringsriktning. Många missar också datans form: “users-tabellen är stor” säger lite, men “users=12M, orders=220M, status-predikat matchar 0,5%” hjälper den att resonera om join-ordning och indexselektivitet. Till sist glömmer team att nämna planinstabilitet; om den ibland väljer hash join och ibland nested loops, säg det uttryckligen så att omskrivningen kan göras mindre känslig för skevhet.
Den här prompten är inte optimal för engångsgissningar när du inte kan komma åt exekveringsplaner eller inte kan köra mätningar, eftersom rekommendationerna är evidensdrivna. Den passar också dåligt om ditt verkliga problem är arkitektoniskt (saknade partitioner, felaktig datamodell eller en rapportlast som tvingas på en OLTP-primär) och du inte är öppen för schema- eller workload-förändringar. Om du bara behöver en grundläggande SQL-genomgång eller en mallfråga är en lärresurs ett bättre val; det här är triage och optimering, inte grunderna.
När du slutar gissa och börjar optimera utifrån planen kommer vinsterna snabbare och med mindre risk. Klistra in din långsamma sats och dess exekveringsplan i promptvisaren och iterera tills “före vs efter” berättar en tydlig historia.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.