Not checking execution plan before optimizing

Always run EXPLAIN ANALYZE before making changes

Optimizing without seeing the execution plan is like fixing a car without looking under the hood. The plan reveals the actual bottleneck - maybe it's not what you think. Always measure first, then optimize based on evidence.

Run EXPLAIN ANALYZE first, identify the bottleneck, then optimize

Critical

Blind optimization without understanding the problem

Ignoring row estimate discrepancies (Estimated: 100, Actual: 100,000)

Run ANALYZE/UPDATE STATISTICS when estimates are off by 10x+

When estimated rows differ significantly from actual rows, the optimizer makes poor decisions about join methods and order. This happens when table statistics are outdated. Running ANALYZE updates statistics and often fixes the problem immediately.

Update statistics regularly, especially after bulk data changes

High

Outdated statistics cause optimizer to choose wrong plan

Accepting sequential scans on large tables without investigation

Investigate every sequential scan on tables with >10K rows

Sequential scans read every row in the table. On a 10M row table, this means 10M rows examined even if you only need 100. This is the #1 cause of slow queries. Add an index on the WHERE/JOIN columns to enable index seeks instead.

Add indexes on columns used in WHERE, JOIN, and ORDER BY clauses

Critical

Missing indexes causing full table scans

Using EXPLAIN without ANALYZE (not seeing actual execution)

Use EXPLAIN ANALYZE to see actual execution times and row counts

EXPLAIN shows the plan and estimates, but ANALYZE actually executes the query and shows real metrics. Estimates can be wrong due to outdated statistics or data skew. Always use ANALYZE to see the truth.

EXPLAIN ANALYZE shows reality, EXPLAIN shows predictions

High

Only seeing estimates, not actual performance

Not understanding that execution plans read bottom-to-top or inside-out

Read plans from innermost/bottom operation first

Execution plans show operations in a tree structure. The innermost or bottom-most operation executes first, and results flow upward. Misreading the order leads to wrong conclusions about what's slow.

Start reading from the most indented or bottom operation

Medium

Misinterpreting execution order

Focusing only on cost, ignoring actual time

Look at actual time in EXPLAIN ANALYZE, cost is just an estimate

Cost is a relative estimate used by the optimizer for comparison. Actual execution time is what matters for performance. A high-cost operation might be fast if it's in memory, while a low-cost operation might be slow if it hits disk.

Actual time > Cost estimates for real-world optimization

Medium

Cost is relative and can be misleading