# Investigate a primary key access plan

A declared primary key does not mean every query uses a key lookup. The predicate, expressions and required rows determine which access plan is useful. Start with the actual statement and a known table definition.

```sql
EXPLAIN QUERY PLAN
SELECT name FROM customers WHERE id = 42;
```

Compare this with a predicate that wraps `id` in a conversion or searches another field. A query returning most of a table may reasonably use a scan. Inspect the reported plan rather than inferring it from a fast or slow response.

## Confirm the schema

`system.columns` exposes `is_in_primary_key` and `primary_key_position`. Filter by database, table and namespace so identically named objects are not confused. Check that the application selected the intended database and bound the intended value type before rewriting the SQL.

Keep comparisons in the column's native value domain when possible. Validate a change with the same data and record duration, read rows and returned rows. Do not add an unnecessary limit merely to make a test faster if the application still needs the full result.

See [EXPLAIN](https://coordinatordb.com/docs/reference/statements/explain), [system.columns](https://coordinatordb.com/docs/reference/system-tables/columns) and [primary key guidance](https://coordinatordb.com/docs/concepts/best-practices/choosing-a-primary-key).