CodeOath
← All posts
SQL65 min total · 16 parts

Understanding SQL Indexes and Query Performance

Contents — Part 16 of 16: Common Mistakes Worth Remembering
Part 16 of 16 · ~1 min

Common Mistakes Worth Remembering

  • Assuming an index automatically gets used just because it exists — the optimizer only uses it when its own cost estimate says it's cheaper than the alternative, which depends on selectivity and up-to-date statistics.
  • Wrapping an indexed column in a function or arithmetic expression in WHERE, silently forcing a full scan.
  • Building a composite index expecting it to help queries filtering on any of its columns individually, when only queries anchored on the leftmost column benefit.
  • Adding an index to fix a slow query without ever checking the execution plan to confirm the index actually got used, or that indexing was even the bottleneck.
  • Treating indexing as free — adding indexes to every column "just in case" and quietly degrading write throughput for reads that never happen.
  • Forgetting that statistics can go stale after a bulk load or mass delete, and blaming the schema for a problem that a fresh ANALYZE would fix.

Explore how joins, WHERE, and aggregates interact with this material further in SQL Fundamentals: Joins, NULL, Aggregate Functions, and Subqueries, or practice writing and profiling real queries in the code lab.