# Investigate repeated-query performance

A repeated query can have a different duration even when its SQL is unchanged. Use measurements to determine what work the request performed; Coordinator DB does not document a result-cache setting or cache-hit counter that an application can rely on.

```sql
SELECT query_id, query_duration_ms, read_rows, read_bytes, result_rows
FROM system.query_log
WHERE type = 'QueryFinish'
ORDER BY event_time DESC
LIMIT 10;
```

Match the executions by query ID and verify that they read the same database and input values. Keep `LIMIT`, output format and result-row caps identical. A client that retrieves fewer bytes can appear faster even when SQL work is similar.

Inspect `EXPLAIN QUERY PLAN` if a change in the access path could explain the result. Use `EXPLAIN ANALYZE` for a measured execution when appropriate, remembering that it returns a plan instead of the usual rows and executes writes once.

Do not base correctness or freshness on a presumed cache lifetime. An ordinary view evaluates its SELECT when queried; if a stored result is required, maintain an explicit table with an application-defined update procedure.

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