Databases5 min read
The Database Indexing Mistakes I See in Almost Every Audit
Most slow-query problems aren't missing indexes — they're indexes that exist but don't match how the application actually queries.
Tanjil Ahmed
Lead Software Engineer · Notionhive
'We have indexes on the important columns' is the most common thing I hear right before finding the query that's doing a full table scan anyway. Indexing mistakes are rarely about having none — they're about indexes that don't match the actual shape of the query.
- Composite index column order matters — an index on `(status, created_at)` doesn't help a query filtering only on `created_at`.
- A leading wildcard LIKE query (`%term`) can't use a standard index at all, no matter how many you add.
- Indexes on low-cardinality columns (a boolean flag) rarely help and add write overhead for little read benefit.
- `EXPLAIN` the actual production query, not a simplified version — the real query with real joins is what needs the index.
The fix is almost never 'add more indexes.' It's reading the query plan for the exact query the application runs, understanding what the planner is actually doing, and indexing for that specific access pattern instead of guessing at what 'the important columns' are.
An index you added by guessing is a write penalty with no read benefit. Read the query plan before adding one.
