# Inspect query measurements

Measurements describe a concrete execution, not an abstract SQL spelling. Keep its SQL, parameters, data and query ID together when investigating a request.

## Find the execution

Read the query ID from an HTTP response header or query history. Use system.query_log for finished requests and system.processes for active requests.

Compare elapsed time with read_rows, read_bytes, written_rows and written_bytes. Terminal memory_usage and peak_memory_usage both report the query's peak accounted memory, rather than a post-completion live allocation.

## Inspect the plan

EXPLAIN QUERY PLAN shows access choices without executing the statement. EXPLAIN ANALYZE executes once and includes runtime measurements:

```text
EXPLAIN ANALYZE
SELECT generate_series
FROM generate_series(1, 3);
```

Analyzed output replaces the underlying result rows. EXPLAIN ANALYZE also applies DML changes once; use a transaction and rollback when those changes should not remain.

## Compare runs

Durations vary between executions. Keep result limits and data fixed, verify that both queries perform the intended work, and inspect the plan alongside timings.

See [`EXPLAIN`](https://coordinatordb.com/docs/reference/statements/explain) and [query history](https://coordinatordb.com/docs/guides/clickhouse/performance-and-monitoring/diagnose-slow-queries).