- This topic is empty.
-
The endpoint returned a short list, but the database CPU jumped every time it ran. The SQL looked harmless: a join, a filter, and a limit of twenty rows. The execution plan told a different story. The optimizer chose a nested loop over a large table because statistics were stale, and the index used for sorting did not cover the selected columns. We fixed it by refreshing statistics, adding a covering index, and rewriting the predicate so the filter could run before the join. Latency dropped from 1.8 seconds to 40 milliseconds. The lesson is that row count at the end does not explain work done along the way. Read the plan, check cardinality estimates, and measure I/O. What query taught you to trust the execution plan over the shape of the SQL?
- You must be logged in to reply to this topic.