Execution Plan Analysis — Read What the Engine Actually Chose
Optimize what the engine does, not what the SQL looks like: cost concentration, estimate-vs-actual gaps, and plan warnings — with forensic evidence rules.
View Resource →Coding Workflows
SQL Optimization Prompt
"Optimize this query" gets generic indexing advice. Pick a goal, a database platform, and an evidence mode — and get an optimization contract: execution-plan thinking, per-platform guidance, justified index recommendations with their write tax, and a forensic mode where generic advice is forbidden and missing evidence becomes a command to gather it. Runs entirely in your browser.
Which query, slow in what way? E.g. "Find why the order-search query behind GET /orders takes four seconds."
Evidence Mode
Forensic is the flagship: every conclusion cites evidence, and generic advice is forbidden.
Paste it and the prompt carries it verbatim — the detector also flags SELECT * and non-sargable patterns.
If you have it, the analysis grounds in it. If not, the prompt demands the capture command instead of inventing one.
How slow, since when, for which inputs — measured, not felt.
Optimization Preview (live — the contract's shape, not the output)
SQL Optimization Prompt
Missing Index Analysis — Which Indexes, at What Cost
Map every predicate, join, and sort to the index that serves it — or doesn't. Composite order rules, covering decisions, and the write tax nobody mentions.
View Resource →MySQL Query Optimization — InnoDB Realities, type=ALL
EXPLAIN shows type=ALL on a 1.2M-row table: full scan on every search. MySQL optimization with InnoDB clustering realities, version-aware optimizer limits, and covering reads.
View Resource →Optimize Reporting Queries — Read Millions, Return Rows
An 11-minute report that reads two years of orders to return 24 rows: the rows-read to rows-returned ratio is the target — filters pushed down, pre-aggregation costed honestly.
View Resource →Optimize SQL Query — Joins, Cardinality, and Wasted Work
A five-table join that got slow as data grew: establish cardinality first, check each join strategy against the data shape, and hunt the fan-out doing wasted work.
View Resource →PostgreSQL Query Analysis — EXPLAIN (ANALYZE, BUFFERS) Reading
A real plan with the story inside: estimate says 42 rows, actual is 51,840. PostgreSQL analysis grounded in the plan — stale statistics, bloat, planner costs, and the index arsenal.
View Resource →Slow Query Investigation — Degrading Month Over Month
Queries that were instant at launch and crawl a year later: scale-aware investigation of work that grows faster than the data, before it owns the server.
View Resource →SQL Optimization Prompt — the Evidence-Based Contract
"Optimize this query" gets generic indexing advice. The optimization contract demands evidence: real bottlenecks, justified indexes with their write tax, and no invented plans.
View Resource →SQL Performance Analysis — Surviving the Billion-Row Table
At 240M rows and growing: keyset pagination over OFFSET, partition pruning, and the PostgreSQL specifics — analysis aimed at the scale the table will reach, not the scale it passed.
View Resource →SQL Server Query Tuning — Plans, Sniffing, Clustering Keys
Fast for most customers, 30x slower for the largest two — the parameter sniffing signature. SQL Server tuning with actual plans, clustering-key economics, and CONVERT_IMPLICIT hunting.
View Resource →How it works
State the optimization objective, pick the goal — Query Speed, Join Optimization, Index Strategy, Large Dataset Scaling, Reporting Query Optimization, or Execution Plan Analysis — and choose the database platform and evidence mode. Each goal is a different optimization philosophy with its own priorities and analysis areas; each platform adds real engine-specific guidance — actual-plan tooling, optimizer quirks, clustered-index realities — not just a label. Then provide what evidence you have: the query (the detector flags SELECT * and non-sargable patterns), the execution plan, tables with row counts, existing indexes, and measured symptoms. What you can't provide changes the contract: no plan means the prompt demands the exact capture command instead of inventing one; no index list means no index may be assumed. Click Generate SQL Optimization Prompt for the full contract — bottleneck analysis, impact-ordered opportunities, justified index recommendations with their write tax, tradeoffs, and an assumptions ledger. Forensic mode adds the rule that defines the tool: generic advice is forbidden. Nothing leaves your browser.
Use cases
- Turning "optimize this query" into an evidence-based analysis contract
- Reading an EXPLAIN ANALYZE output operator by operator
- Getting index recommendations that name their clause and their write tax
- Making queries survive growth instead of just passing today
Pro tips
- Paste the actual execution plan if you possibly can — it is the single most valuable input. Estimate-vs-actual row gaps in a real plan settle arguments that query text alone never will.
- Use Forensic mode when you're tired of generic advice: its rule that "a recommendation that would read the same without ever seeing this query does not belong in the analysis" changes what the model dares to say.
- Fill in row counts even roughly (12M, 900K, 40). Join strategy and index advice without cardinality is guesswork — and the contract will say so instead of guessing.
- Take the verification step seriously: every recommendation comes with how to measure it — plan and timing before and after, on production-shaped data. An optimization that was never measured is a hypothesis.
FAQ
Does this tool optimize my query?
No — it builds the contract. The output is a prompt that instructs an AI how to analyze and optimize your SQL: which philosophy to apply, what platform realities to respect, what evidence to demand, and how to justify every recommendation. The flagship is the evidence discipline — no invented execution plans, no assumed indexes, no assumed row counts, and in Forensic mode, no generic advice at all.
Why is "optimize this query" a weak prompt?
Because it gets generic database advice: "add an index on the WHERE columns, avoid SELECT *" — recommendations that read the same for every query ever written. Real optimization is evidence work: which operator concentrates the cost, what the estimate-vs-actual gap says about statistics, whether the join order matches the cardinalities, what each candidate index taxes on writes. The contract demands exactly that, and forbids the rest.
Why is the database platform a mode and not separate tools?
Same reasoning as frameworks in the Test Case Prompt Generator: the optimization question is identical — only the engine realities differ. SQL Server brings parameter sniffing and clustering-key economics; PostgreSQL brings EXPLAIN (ANALYZE, BUFFERS), bloat, and planner cost settings; MySQL brings InnoDB realities and version-specific optimizer limits. Each platform mode injects that real guidance into the same contract — and the platform-specific search intents live as resources.
My app is slow — should I use this or the Debugging Prompt Generator?
Depends on what you know. If you don't yet know where the time goes — could be code, could be network, could be the database — start with the Debugging Prompt Generator's performance investigation: it finds the bottleneck. Once the suspect is a specific query, this tool takes over: query-level analysis is its entire job. In this category's verbs: Debugging investigates, SQL Optimization optimizes.
What happens if I don't have the execution plan?
The contract refuses to fake one. Its non-goals open with "do not invent execution plans" — so instead, the prompt demands the exact capture command for your platform (EXPLAIN (ANALYZE, BUFFERS) on PostgreSQL, the Actual Execution Plan plus SET STATISTICS IO, TIME ON on SQL Server) and marks every plan-dependent conclusion as pending that evidence. In Forensic mode, gathering the missing evidence becomes the first recommendation itself.
How is this different from the Code Review Prompt Generator's SQL option?
Review's SQL language mode judges code that happens to contain SQL — injection risks, readability, obvious anti-patterns — from a reviewer's perspective. This tool owns performance: execution plans, cardinality, join strategy, index economics. The category rule is strict: everything SQL-performance belongs here, which is why the review tool deliberately has no database-review resources.
Will it recommend indexes?
Only with a pedigree. The contract's index rules: every recommendation must name the exact predicates, joins, or sorts it serves — no index without a clause; composite column order must be justified; covering decisions come with their storage and write cost; and every index states its write tax — which inserts and updates it slows. It also checks existing indexes first: extending a near-miss index beats creating an overlapping new one.