Read the plan in context
Check whether the plan uses scans, indexes, joins, sorts, or temporary operations and how many rows each step estimates. A scan is not automatically wrong; it may be efficient for a small table or a query that returns much of the data.
Compare estimated and actual row counts when the engine provides runtime analysis. Large differences can point to stale statistics, correlated data, or parameter-sensitive behavior; refresh or investigate statistics before forcing a specific access path.
Change one factor and measure
Use representative parameters and data volume, and capture latency, rows processed, and resource use before and after a change. Indexes can reduce reads but increase write cost and storage, so assess the whole workload.
Confirm behavior under concurrency and across important parameter values. Preserve a way to compare plans after schema, statistics, or engine changes, since a plan that was efficient yesterday may not remain so.