Why did my SQL query suddenly get slow?

Almost always because the data grew past a threshold where the plan changed. The optimizer switches from an index seek to a full scan, or from a nested loop join to a hash join, once its estimate of matching rows crosses a limit. Nothing in the query changed; the plan under it did. Stale statistics have the same effect, because the optimizer is choosing based on a row count that is months out of date. Check the execution plan first, then compare it with what the plan used to be.

What makes a SQL query slow?

In order of how often it matters: a filter the database cannot use an index for, such as WHERE YEAR(created_at) = 2026, which forces a scan of every row; a join on columns with no index; SELECT * pulling columns nobody reads; a correlated subquery running once per row; and ORDER BY on an unindexed column, which forces a sort of the whole result. Missing indexes and non-SARGable filters together account for most real-world cases.

Can AI optimize SQL queries?

AI can rewrite a query into an equivalent form that is easier for the optimizer — rewriting non-SARGable filters into range conditions, replacing correlated subqueries with joins, removing redundant DISTINCT, narrowing the column list. What it cannot see is your data distribution, your existing indexes or your execution plan, so it cannot tell you which index to create with certainty. Use it to fix the query shape, then confirm with the execution plan.

Should I add an index to make my query faster?

Often yes, but not blindly. An index speeds reads and slows every insert, update and delete on that table, and an index the optimizer never chooses is pure cost. Add one when a filter or join column has high selectivity and appears in queries that run often. Check the execution plan before and after: if the plan does not switch to using it, the index is not helping.

SQLPerformance

How to Optimize a Slow SQL Query with AI

The nightly report used to finish before you got in. Now it is still running at 10am. Here is how to find what is slow and what to change — starting from the query you already have.

Aug 11, 202610 min

Look at the plan before changing anything

Query tuning without an execution plan is guessing. Every database will show you what it intends to do:

PostgreSQL and MySQL — EXPLAIN ANALYZE <query>
SQL Server — SET STATISTICS IO ON, or the Include Actual Execution Plan button
Oracle — EXPLAIN PLAN FOR <query> then SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY)

Two things to look for: a full table scan on a large table, and a row-count estimate that is wildly different from the actual. The second means the optimizer is planning against statistics that no longer describe your data, and no rewrite will fix that — refresh the statistics first.

What actually makes queries slow

Filters an index cannot be used for

This is the most common cause and the easiest to fix. Wrapping a column in a function hides it from the index:

-- scans every row
WHERE YEAR(created_at) = 2026

-- uses an index on created_at
WHERE created_at >= '2026-01-01'
  AND created_at <  '2027-01-01'

The same applies to WHERE UPPER(email) = ... and to leading wildcards: LIKE '%acme%' cannot use a normal index, while LIKE 'acme%' can.

Correlated subqueries

A subquery in the SELECT list that references the outer row runs once per row. At ten thousand rows that is ten thousand queries. Rewriting it as a join with a grouped subquery turns it into one pass:

-- once per customer
SELECT c.name,
       (SELECT COUNT(*) FROM orders o WHERE o.customer_id = c.id) AS orders
FROM customers c

-- once, total
SELECT c.name, COALESCE(o.cnt, 0) AS orders
FROM customers c
LEFT JOIN (SELECT customer_id, COUNT(*) AS cnt
           FROM orders GROUP BY customer_id) o
       ON o.customer_id = c.id

SELECT * on wide tables

Every unused column is read from disk and pushed over the network. Worse, it can prevent a covering index from being used: if the index contains every column the query needs, the database never touches the table at all — and SELECT * guarantees it has to.

Sorting and DISTINCT you did not need

ORDER BY on an unindexed column sorts the entire result set. DISTINCT is often there to paper over a join that duplicates rows; fixing the join is faster than deduplicating afterwards.

Getting the rewrite

Paste the query into the box at the top of this page. What comes back is an equivalent query plus a list of what changed and why it is faster — a filter made index-usable, a correlated subquery flattened, a redundant sort removed, a column list narrowed.

Treat it as a shape change, not a verdict. The rewrite cannot see your indexes, your data distribution or your plan, so the honest sequence is: rewrite the query, run the plan again, and keep the version the plan likes.

On adding indexes

An index is a trade: faster reads, slower writes, more storage. Add one when a column is selective, appears in a filter or join, and is used by queries that run often. Then confirm the plan switched to it — an index the optimizer ignores costs you on every write and returns nothing.

For composite indexes, order matters: put the column used in equality filters first, the range filter last. An index on (status, created_at) serves WHERE status = 'open' AND created_at > ...; reversed, it mostly does not.

A short checklist

Get the execution plan. Find the scan.
Check whether estimated and actual row counts agree. If not, refresh statistics.
Make filters index-usable — no functions on the filtered column.
Replace correlated subqueries with joins.
Name the columns you need instead of *.
Remove DISTINCT by fixing the join that duplicates.
Re-run the plan and keep what is faster.

If the query is also hard to read, have it explained first — optimising a query you do not understand is how a fast wrong answer gets shipped.