AI Prompt to Diagnose and Fix Slow Database Queries
This AI prompt helps you diagnose and fix slow database queries by walking through the execution plan, indexing, and query structure instead of guessing at a fix. It's for backend engineers and anyone who owns a production database and wants ChatGPT, Claude, or Gemini to reason through why a specific query is slow rather than hand it a generic "optimize my SQL" request.
You give the model the slow query, its execution plan (EXPLAIN or EXPLAIN ANALYZE output), the relevant table schema, and row counts, and it returns a ranked list of likely causes — a missing or unused index, a bad join order, an N+1 pattern, a non-selective WHERE clause — along with a rewritten query and the exact index or schema change to test first.
Because query-optimization prompts tend to get long once you paste in an execution plan and schema, running the draft through Prompt Optimizer's Coding mode first can tighten the instructions so the model focuses on the actual bottleneck instead of restating the schema back to you.
Prompt template
Want it sharper? Optimize this prompt with Prompt Optimizer, check it with the Prompt Debugger or shorten it with the Token Optimizer.
Example input
When to use it
- A specific query is timing out or consistently slow in production and you need a root cause, not just "add an index"
- You're reviewing a pull request that adds a new query and want a second opinion on its performance before it ships
- You inherited a legacy schema with unexplained slow reports and need help reading an unfamiliar execution plan
- You're deciding between adding an index, denormalizing a table, or rewriting a query, and want the trade-offs laid out
Best practices
- Always paste the actual EXPLAIN or EXPLAIN ANALYZE output, not just the query — the model can't diagnose what it can't see
- Include approximate row counts for the tables involved; a query that's fine at 10,000 rows can be the cause of real degradation at 10 million
- Ask the model to propose the smallest change first, such as an index, before suggesting a structural change like denormalization
- Test the suggested fix against a staging copy of production-scale data before applying it live, since query planners behave differently on small datasets
Common mistakes
- Asking the model to "optimize this query" with no execution plan or schema, which produces generic advice that may not apply to your actual bottleneck
- Applying every suggested index without checking write-performance cost, which can slow down inserts and updates more than the query was ever slowing down reads
- Ignoring the explanation of why a query is slow and only copying the rewritten SQL, leaving you unable to debug the next slow query yourself
- Testing a fix against a tiny local dataset where the query planner picks a different strategy than it will at production scale
FAQs
Why is my SQL query slow even though the table isn't that big?
Table size alone doesn't determine query speed — a missing index, a non-selective filter, or an expensive join can make even a mid-sized table slow. Checking the execution plan rather than the row count is usually the faster way to find the real cause.
How do I read a PostgreSQL EXPLAIN ANALYZE output to find the bottleneck?
Start from the innermost nodes and work outward, comparing the estimated cost and row count against the actual values returned — a large gap between the two usually means the planner's statistics are stale. A Seq Scan on a large table combined with a filter condition is the most common sign that an index is missing.
When should I add an index versus rewriting the query itself?
Add an index first when the query's logic is sound but the database has to scan too much data to satisfy it; rewrite the query when the logic itself is inefficient, such as a correlated subquery that could be a join. Most slow queries in production are fixed with the right index rather than a rewrite.
Can ChatGPT actually read an execution plan accurately?
It can interpret a pasted EXPLAIN or EXPLAIN ANALYZE output reasonably well when given the full text, but it can't see your actual data distribution or run the query itself, so its suggestions should be tested on a realistic dataset before being applied to production.
What Cuelara tool can help me tighten this prompt before I run it?
Prompt Optimizer — its Coding mode is built for exactly this kind of technical prompt with a lot of pasted context. Token Optimizer — worth running once the execution plan and schema make the prompt long, to cut the token cost without losing the details the model needs.