# Profile SQL with analyzed execution plans

Use the documented SQL measurement interfaces before requiring a special executable or an external instrumentation format. `EXPLAIN QUERY PLAN` shows the selected access path without executing the statement; `EXPLAIN ANALYZE` executes it once and includes runtime measurements.

```sql
EXPLAIN ANALYZE
SELECT sum(generate_series)
FROM generate_series(1, 10000);
```

The output is an analyzed plan, not the sum the original query would return. Run the ordinary SELECT separately when you also need to verify its result. Keep generated ranges small enough for the question you are investigating and compare representative application queries before making a performance claim.

For a server request, retain its query ID and inspect the terminal event in `system.query_log` for duration, read work and peak accounted memory. The active-request snapshot is useful only while work is still present.

Analyzing a data-changing statement applies its changes once. Use a transaction and rollback when measurement must leave no committed change. Compiler-specific tracing commands and external profiler file formats are outside the documented Coordinator DB query interface.

See [`EXPLAIN`](https://coordinatordb.com/docs/reference/statements/explain) and [query measurements](https://coordinatordb.com/docs/guides/clickhouse/performance-and-monitoring/isolate-query-bottlenecks).