# Investigate a slow query step by step

Begin with the exact query, representative data and the result the reader actually needs. A slow request can be expensive SQL, a large result or delayed response delivery. Do not change several limits before identifying which observation supports the diagnosis.

First inspect the access plan without executing a write:

```sql
EXPLAIN QUERY PLAN
SELECT id, amount FROM orders WHERE id = 42;
```

Then retain the real execution's query ID and read its terminal history. Compare duration, read rows, returned rows and peak accounted memory. Active `elapsed` includes the request's lifetime through response delivery, so it answers a different question from a plan measurement.

Check whether the query projects unnecessary columns, joins duplicate keys or requests rows that the caller never uses. A targeted index can help a repeated lookup, but verify its chosen access path and write overhead with the actual workload.

Finally, inspect effective settings if a request fails at a resource limit. Raising a ceiling is a deliberate operational choice, not evidence that the query became more efficient.

See [query measurements](https://coordinatordb.com/docs/guides/clickhouse/performance-and-monitoring/isolate-query-bottlenecks), [indexes](https://coordinatordb.com/docs/reference/statements/create/create-index) and [effective settings](https://coordinatordb.com/docs/reference/system-tables/settings).