SQL Query Prompt: Add Your Schema and Request, Get a Working Query Explained Step by Step

The real convenience of an SQL query prompt is that people who barely write queries can still pull their own numbers from a database. But ask plainly for "last month's sales by store" and the AI can only guess table and column names — guess wrong and you get an error, or worse, a neat-looking set of figures built on the wrong definitions. The prompt below states the schema and database type up front, then writes "queries only, never invent a column, give me a way to check first" into the rules. Copy it, fill in the variables, and run it.

Before you start, prepare these three things

1. The table schema: a CREATE TABLE statement works, and so does a column list with each column's name, type, and a one-line note on what it holds. If two or more tables have to be joined, mark which column joins them. If you truly cannot get the schema, make the AI ask what it is missing instead of letting it write blind.
2. The database type: name one of MySQL, PostgreSQL, SQL Server, or SQLite. Date functions and paging syntax differ between them; leave it out and the AI defaults to one dialect that errors on another system.
3. What the result should look like: give one sample row, or state which columns you want, how they should be sorted, and whether they should be aggregated. The same words "check the sales" can mean one total, a per-day split, or a per-store split — three completely different queries.

If your data still lives in a spreadsheet file rather than a database, do not detour through SQL at all: analysing the sheet directly with the prompt for analysing Excel data with AI is quicker. Come back to this one once the data sits in a database and you need to pull it repeatedly.

Copy this prompt as-is

# Role
You are a data analyst who knows {{database type}} well. Write queries only from the schema I give you; never guess a column that is not in it, and ask me first when information is missing.

# Input
Database type: {{database type}}
Table schema: {{table schema}}
What I want to know: {{my question}}
Definitions and scope: {{definitions}}

# Rules
1. Write SELECT queries only — nothing that inserts, deletes, or updates data;
2. Use only table and column names that appear in the schema; if a filter in my question is unclear, list what is ambiguous and ask me instead of assuming;
3. Handle the time range exactly as the definitions say, and state which time column you used and whether the boundary days are included;
4. For money and counts, state the aggregation you used (sum, count, or count of distinct values); handle empty values as the definitions say, and ask me if they say nothing;
5. Give me a checking query that counts rows first, so I can confirm the count before the real query;
6. After the real query, explain what each part does, section by section, and point out which columns of the result I should check most carefully.

# Output format
First, the questions you need me to confirm (write "none" if there are none);
then the checking count query;
then the real query, in a code block;
finally the section-by-section explanation, plus one way to verify a single row by hand.

With an orders table, the variables look like this

• {{database type}}: MySQL 8.0
• {{table schema}}: an orders table with columns order_id (order number), store_name (store), amount (amount), pay_time (payment time), and status (paid means paid, refunded means refunded)
• {{my question}}: for last month, the total amount and the number of paid orders per store, sorted by total amount from high to low
• {{definitions}}: count only orders whose status is paid; use pay_time for the time range, and "last month" means the previous calendar month; orders with an empty amount do not count into the total, but tell me in the explanation how many such orders there are

Once filled in, the checking query the AI returns first is the key step: run it in your database and compare the number with the order count exported from your business system. Only run the real query when the two match. If they do not, the definitions or the time column were misunderstood — fixing the definitions is faster than fixing the query itself.

With the result in hand, verify these three steps before using it

1. Match the total: the per-store order counts in the real result should add up to the number from the checking query. When they do not, the usual cause is a join that multiplied rows, counting one order several times.
2. Recalculate one row by hand: pick one store and compute its subtotal separately, with a filter or the simplest possible second query. Only when both agree is the aggregation really on track.
3. Check the edges: look at the earliest and latest times in the result and confirm no extra day crept in and none went missing; also watch whether rows with empty amounts or odd statuses were quietly counted in.

When it errors or the numbers look wrong, follow up like this

• On an error, ask: "Here is the exact error message: {{error message}}. Change only the part that fails, keep everything else unchanged, and tell me what you changed."
• When the figures look too large, ask: "The result is about {{factor}} times larger than expected. Check whether a join inflated the row count, and list, one by one, where double counting could happen."
• When it runs slowly, ask: "This query took {{run time}} on about {{data volume}} of data. Rewrite it without changing the result, and tell me which column should get an index."

Each of these follow-ups carries concrete information from the scene — the exact error, the factor, the data volume — so the AI can repair one spot precisely. A bare "that's wrong, redo it" forces it to tear the whole query down and guess again, and each round drifts further.