Why developers read query plans

WHAT THIS TESTS The interviewer checks baseline competence: do you know what a plan is, how to get it, and one useful thing it tells you.

A GOOD ANSWER COVERS A query execution plan is the step-by-step strategy the database optimizer chose to satisfy a query, expressed as a tree of operators such as table scans, index scans, joins, filters, sorts, and aggregations, usually annotated with estimated cost and the estimated number of rows at each step. You obtain it by prefixing the query with EXPLAIN, or EXPLAIN ANALYZE to actually run the query and see real timings and row counts. It is useful because it reveals how the database will actually fetch data rather than how you wrote the SQL, so when a query is slow you can see the cause instead of guessing. A common thing to look for is a sequential or full table scan on a large table where you expected an index to be used, which often points to a missing index, a non-sargable predicate, or stale statistics. You also check that joins use sensible algorithms and that row estimates look believable.

COMMON WRONG ANSWERS Not knowing how to obtain a plan. Confusing the plan with the SQL text itself. Reading cost as milliseconds. Assuming every scan is a problem when a scan can be optimal for small tables.

LIKELY FOLLOW-UPS What is the difference between EXPLAIN and EXPLAIN ANALYZE; what does a sequential scan imply; how do you fix one; what are estimated versus actual rows.

ONE CONCRETE EXAMPLE A developer notices a user-lookup endpoint is slow, runs EXPLAIN ANALYZE on its query, and sees a sequential scan over a million-row users table for WHERE email equals a value. That tells them no usable index exists on email; adding one changes the plan to a fast index scan and resolves the latency.