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.

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, system.columns and primary key guidance.