Query Planning
On this page
Query Planning Explains Why a Query Is Slow
In production, you do not optimize by guessing. You optimize by understanding how the database executes the query: which index it uses, how many rows it scans, and where it sorts. Query planning is the difference between “it feels slow” and “it scans 8M rows”.
What to Look For in a Plan
- Which index is selected (or why none is)
- Estimated rows scanned vs returned
- Filesort or temporary table usage
- Join order and join type
Common Root Causes
- Missing composite index matching the WHERE + ORDER BY shape
- Low selectivity predicates (status, is_active) used alone
- Implicit conversions (string vs int) preventing index use
- Large OFFSET pagination forcing scans
Stability Matters More Than Best-Case Speed
Query plans can change as data grows or distribution changes. A query that was fine at 100k rows can collapse at 10M rows. Production-first optimization targets stable plans under growth, not only fastest today.
Red flags in practice: - Rows examined is orders of magnitude higher than rows returned - Sorting happens after filtering (filesort) on a large set - Join explodes row counts before filtering (bad join order)
Production-First Takeaway
Use query plans to explain latency. Optimize for low scanned rows, index-aligned sorting, and plan stability as data distribution evolves.