Why is disk I/O the thing index structures are actually optimizing for?
Reading from disk (or even from a cold page cache) costs orders of magnitude more time than an in-memory comparison. An index structure's real job is minimizing the number of disk page reads needed to find a value, not minimizing the number of comparisons — which is why B-trees are shaped around fitting many keys per disk page, not around minimizing tree depth for its own sake.
Answered in
What Actually Happens Inside a Database Index: The Data StructuresAn index trades disk I/O for lookup speed. Here's how B-trees, hash tables, and bitmap indexes each make that trade differently.
Read the full analysisOther questions this article answers
More system design questions
- Why does a database need an index at all — why can't it just scan the table?
- When is a hash index better than a B-tree index?
- What is a composite index and why does column order matter?
- What's a covering index and why is it faster than a normal index?
- What's the real cost of adding an index, beyond disk space?
- What does ACID actually stand for, and why do all four properties matter together?
- What's the practical difference between pessimistic and optimistic concurrency control?
- What is a race condition in a database transaction, and how does isolation prevent it?
Every answer on Crashtech is written by the editor of the article it comes from — never auto-summarised. Browse all answers or the System Design beat.