SQLFormatter
FormatterConvertPricingDocsGet Pro
AI Tool · Optimize

Optimize a slow SQL query

Paste a query that’s dragging and get specific, actionable suggestions — indexes to add, sargable rewrites, joins that beat correlated subqueries — each with a short reason so you learn why it’s faster, not just what to change.

1Paste your SQL into the formatter.
2Click Optimize.
3Apply the suggested indexes and rewrites.
Optimize a query

Free account, 3 free AI credits. Formatting stays free without signing in.

before — slow
SELECT *
FROM orders o
WHERE YEAR(o.created_at) = 2026
  AND o.customer_id IN (SELECT id FROM customers WHERE country = 'US')
ORDER BY o.total DESC;
Suggested optimizations
Avoid wrapping the column in a function
YEAR(o.created_at) = 2026 can't use an index on created_at. Rewrite as a range: created_at >= '2026-01-01' AND created_at < '2027-01-01'.
Turn the IN-subquery into a JOIN
A JOIN to customers on a filtered country lets the planner use an index and estimate rows better than a correlated IN.
Select only the columns you need
SELECT * forces the engine to read and return every column; list the ones the caller actually uses.
Add a supporting index
An index on orders(created_at, total) helps both the range filter and the ORDER BY.

Why optimize SQL with AI?

Most slow queries share a handful of causes: a function wrapped around an indexed column, SELECT * pulling columns nobody reads, a correlated subquery the planner can’t flatten, or a missing composite index. Spotting them in someone else’s query takes experience — the optimizer names the specific issue in your SQL and gives you the rewrite.

It’s a starting point, not a replacement for EXPLAIN: use the suggestions to form a hypothesis, then confirm the win against your real data and query plan.

Frequently asked questions

Does the optimizer see my database?

No. It reads the query text only — it has no access to your schema, indexes, statistics or data volumes. That is why the suggestions name what to try (an index, a rewrite) rather than promising a speed-up: verify each one with EXPLAIN ANALYZE against your own data.

What is a sargable query?

One whose WHERE clause can use an index — the indexed column appears bare on one side of the comparison. YEAR(created_at) = 2026 is not sargable because the column is wrapped in a function; created_at >= '2026-01-01' AND created_at < '2027-01-01' is, and can seek the index instead of scanning the table.

Is SELECT * really a performance problem?

Often, yes — for two reasons. It forces the engine to read every column, including wide text or JSON ones the caller ignores, and it prevents an index-only scan when a narrower column list would have been covered by an existing index. It also makes the query break silently when someone adds a column.

Which databases does it work with?

PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, SQLite, Snowflake, BigQuery and Redshift. Tell it which one you are on — index syntax and the available rewrites differ enough that the answer changes per engine.

Is it free?

A free account includes 3 AI credits, enough to judge the output on a real query. Formatting, minifying and validating stay free and need no account at all.

More SQL tools

Read an EXPLAIN planConvert between dialectsSQL minifierSQL validator