Långsam SQL misslyckas sällan högljutt. Den nöter bara ner dina dashboards, appens laddtider och batchjobb tills något viktigt timear ut vid sämsta möjliga tillfälle. Då sitter du och gissar: är det frågan, indexen, datavolymen eller databasmotorn som gör något “smart” du inte bad om?
Den här slow SQL queries är byggd för analytics engineers som försöker snabba upp lagerliknande rapportering utan att bryta definitioner, backendutvecklare som behöver förutsägbar latens under samtidighet, och konsulter som måste kliva in i ett kundsamtal med en konkret optimeringsplan. Resultatet är ett stegvis trimningsflöde: vilka frågor du ska ställa, vilken plan-evidens du ska samla in (EXPLAIN/ANALYZE) och omskriven SQL plus index-först-rekommendationer kopplade till ditt schema.
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 | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: Baron Schwartz-inspirerat arbetsflöde för SQL-optimering
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[DATABASSYSTEM] |
Ange vilket relationsdatabashanteringssystem (RDBMS) som används, gärna inklusive version. Till exempel: "PostgreSQL 15.2 eller MySQL 8.0.33"
|
|
[PRIMART_MAL] |
Beskriv huvudmålet med frågan eller optimeringsarbetet, inklusive vilken data som ska hämtas eller beräknas. Till exempel: "Optimera en fråga för att hämta kunders transaktionssammanställningar för de senaste 30 dagarna med svarstid under en sekund."
|
|
[KONTEXT] |
Ge bakgrundsinformation om systemet, arbetslasten och eventuella begränsningar som är relevanta för frågeprestanda. Till exempel: "Databasen stödjer en e-handelsplattform med topptrafik under kampanjer, och frågor måste bli klara inom 500 ms för att undvika flaskhalsar."
|
|
[UTMANING] |
Förklara det konkreta problemet eller den flaskhals som finns i den nuvarande frågan eller databasuppsättningen. Till exempel: "En fråga med flera JOINs kör långsammare än förväntat, vilket försenar framtagningen av dagliga försäljningsrapporter under högtrafik."
|
|
[KOMPETENSNIVA] |
Ange användarens nivå inom SQL och databasoptimering så att rekommendationerna kan anpassas. Till exempel: "Medelnivå: Van vid grundläggande SQL-syntax och indexering men har begränsad erfarenhet av exekveringsplaner."
|
|
[SCHEMADETALJER] |
Ange relevant schemainformation, inklusive tabellstrukturer, relationer och datatyper. Till exempel: "Tabellen Orders med kolumner: id (PK), customer_id (FK), order_date, total_amount; tabellen Customers med kolumner: id (PK), name, email."
|
|
[INDEXDETALJER] |
Lista vilka index som finns på relevanta tabeller, inklusive indextyper och vilka kolumner de omfattar. Till exempel: "Tabellen Orders har ett B-tree-index på order_date och ett sammansatt index på customer_id, total_amount."
|
|
[NUVARANDE_FRAGA] |
Dela den SQL-fråga som används i dag, inklusive eventuella filter, JOINs eller aggregeringar. Till exempel: "SELECT customer_id, SUM(total_amount) FROM orders WHERE order_date >= '2023-01-01' GROUP BY customer_id;"
|
|
[EXEKVERINGSPLAN] |
Ange exekveringsplanen för den aktuella frågan, inklusive nyckeltal som uppskattat antal rader och kostnad. Till exempel: "EXPLAIN ANALYZE visar en sekventiell scan på tabellen Orders där 1 miljon rader bearbetas samt en hash-aggregering för gruppering."
|
|
[TIDSRAM] |
Ange tidskraven för att genomföra optimeringen eller nå önskad prestandaförbättring. Till exempel: "Inom 3 dagar för att hinna med rapportdeadlines inför kvartalsgenomgången."
|
Proffstips för bättre resultat med AI-prompten
- Ta med planen, inte bara frågan. Klistra in din SQL plus EXPLAIN/ANALYZE-utdata (eller närmaste motsvarighet för din motor). Om du kan, ta med timing, rader granskade vs rader returnerade och den värsta noden i planen så att prompten kan koppla ändringar till evidens.
- Definiera “tillräckligt snabbt” i siffror. Säg inte “den är långsam”; ge ett mål som “p95 under 300 ms vid 50 QPS” eller “rapport under 10 s på 30M rader”. Om du är osäker, fråga: “Givet den här endpointen, vilka frågor om latens och samtidighet behöver du för att sätta ett realistiskt mål?”
- Ta med schema och index för tabellerna som ingår. Minst: tabell-DDL (eller en förenklad kolumnlista), primärnycklar, främmande nycklar och befintliga index. En bra följdfråga är: “Här är befintliga index. Vilka är faktiskt användbara för den omskrivna frågan, och vilka är missvisande?”
- Iterera genom att tvinga fram kontraster. Efter första omskrivningen, fråga: “Ge mig ett konservativt alternativ med minimal förändring, och ett aggressivt alternativ som ändrar join-ordning/CTE:er, och förutsäg hur planen bör skilja sig.” Då får du tydligare tradeoffs, inte en enda “bästa gissning”.
- Testa parametersensitivitet med avsikt. Om frågan använder filter som datumintervall, tenant_id eller status, dela två exempel på parameteruppsättningar (en vanlig, en worst-case). Fråga sedan: “Hur kan planeraren välja en dålig plan för det sällsynta fallet, och vilken omskrivning eller indexstrategi stabiliserar den?”
Vanliga frågor
Databasadministratörer använder den för att göra vaga “det är långsamt”-ärenden till en planstyrd checklista (schema, index, radantal, EXPLAIN/ANALYZE) och en mätbar fix. Backendingenjörer tar hjälp när en endpoints p95-latens sticker iväg under samtidighet och de behöver indexvänliga omskrivningar, inte generella SQL-råd. Analytics engineers använder den på tunga rapportfrågor där det är viktigare att minska antalet skannade rader än att mikrooptimera syntax. Prestandakonsulter använder det stegvisa arbetsflödet för att ställa rätt frågor snabbt och undvika cargo-cult-trimning inför kunder.
E-handelsteam använder den för att snabba upp katalog- och orderfrågor som blir långsammare när antal SKU:er och säsongstrafik ökar, särskilt när filter och sortering börjar tvinga fram stora skanningar. SaaS-plattformar får nytta när multitenant-filtrering (tenant_id plus tidsintervall) skapar planinstabilitet och du behöver förutsägbar latens för både “små” och “stora” tenants. Fintech-grupper använder den för huvudboksliknande frågor där korrekthet är icke förhandlingsbart, men där du ändå måste minska IO och låskonflikter. Media- och innehållssajter använder den för att optimera flödes- och sök-liknande frågor där paginering, rankning och joins kan explodera i arbete om index och accessvägar är fel.
En typisk prompt som “Skriv en optimerad version av den här SQL-frågan” misslyckas eftersom den: saknar schemafakta (nycklar, kardinalitet, befintliga index) som avgör vad som ens är möjligt, ger ingen plan-evidens (EXPLAIN/ANALYZE) så ändringar blir gissningar, ignorerar arbetslastbegränsningar som samtidighet och latensbudgetar, producerar generiska omskrivningar som kan öka arbetet (extra sorteringar, bredare skanningar) i stället för att minska antal berörda rader, och missar motorspecifikt beteende där “rätt” omskrivning skiljer sig mellan Postgres, MySQL, SQL Server och andra. Den här prompten är striktare: den ställer spetsiga frågor först och kopplar sedan varje rekommendation till mätbart arbete i planen.
Ja, men anpassningen sker via detaljerna du delar, eftersom prompten är byggd som ett adaptivt arbetsflöde snarare än en ifyllnadsmall. Dela databasmotor och version, exakt SQL, tabellscheman och befintliga index, ungefärliga radantal och EXPLAIN/ANALYZE-utdata från en representativ körning. Lägg sedan till ditt mål i siffror (latensmål, samtidighet eller batchkörtid). En bra följdfråga är: “Givet de här begränsningarna, föreslå två omskrivningsspår och berätta vilka planförändringar du förväntar dig efter respektive.”
Det största misstaget är att bara ge frågetexten och inget annat; “SELECT … FROM … WHERE …” utan schema, index och EXPLAIN/ANALYZE tvingar fram spekulation, medan “Här är DDL, index, radantal och planen med faktisk timing” möjliggör verklig trimning. Ett annat vanligt fel är att dölja databasmotorn (dåligt: “SQL-databas”; bra: “Postgres 15 på RDS, work_mem 64MB, autovacuum på”), eftersom motorns beteende ändrar den bästa omskrivningen. Folk klistrar också in en plan från en icke-representativ körning (dåligt: pyttelitet dev-dataset; bra: produktionsliknande radantal eller åtminstone ett worst-case-parameterset). Slutligen hoppar de över mål; “gör den snabbare” är otydligt, men “sänk p95 från 900 ms till under 250 ms vid 30 QPS” håller rekommendationerna förankrade.
Den här prompten är inte idealisk om du inte kan komma åt exekveringsplaner eller körtidsstatistik alls, eftersom den medvetet undviker att gissa utan evidens. Den passar också dåligt för team som vill ha en engångs-“skriv om den här frågan” utan iteration, eftersom arbetsflödet förväntar att du validerar ändringar mot EXPLAIN/ANALYZE och verkliga timings. Och om problemet i grunden är en trasig datamodell som kräver en total redesign kan du behöva ett djupare arkitekturarbete snarare än promptdriven trimning. I de fallen: börja med att förbättra observability och mätningar först.
Frågetrimning blir enklare när du slutar gissa och börjar arbeta utifrån planer, radantal och index. Klistra in prompten i ditt AI-verktyg, ta med din EXPLAIN/ANALYZE och gör “långsam” till en konkret, mätbar fix.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.