tezvyn:

Database Index: The Phonebook for Your Data

AI-drafted, machine-checkedSource: Wikipedia: Database indexintermediate

An index is like a book's index, letting you jump to the right row without scanning the whole table. It's essential for columns used in WHERE clauses, but over-indexing slows writes since every index must be updated on data changes.

WHY IT EXISTS: Databases need to find data quickly. Without an index, finding a single row in a billion-row table means checking every single row, which is incredibly slow and inefficient. This is called a full table scan. An index provides a shortcut to avoid this brute-force work.

THE MENTAL MODEL: An index is a separate, sorted data structure that acts like the index at the back of a textbook. The book's index lists keywords (the indexed column values) and the page numbers where they appear (pointers to the actual data rows). Instead of reading the whole book, you go to the index, find your keyword, and jump directly to the right page.

HOW IT WORKS: When you create an index on a column, the database builds a special data structure, often a B-Tree. This structure contains a copy of the indexed column's data, sorted for quick searching. Each entry in the index also contains a pointer to the full row in the main table. When you run a query with a WHERE clause on an indexed column, the database uses the index's fast search capability to locate the pointers and then retrieves only the necessary rows from the table.

WHEN TO USE IT: Use indexes on columns that are frequently used in WHERE clauses, JOIN conditions, or ORDER BY clauses. Primary keys are almost always indexed automatically. Foreign key columns are also excellent candidates for indexing to speed up joins. Any column that you use to look up a small number of rows is a good candidate.

WHEN NOT TO USE IT: Be cautious with write-heavy tables. Each index adds overhead to every INSERT, UPDATE, and DELETE operation because the index structure itself must also be modified. Avoid indexing columns with very low cardinality (few unique values, like a boolean 'is_active' column), as the database might decide a full table scan is faster anyway.

ONE CANONICAL EXAMPLE: Imagine a users table with millions of rows. A query like SELECT * FROM users WHERE email = 'test@example.com' would be very slow without an index on the email column, forcing a full table scan. With an index on email, the database can use its internal structure to find 'test@example.com' in logarithmic time, get the pointer to the row, and fetch it directly. This can change an operation from minutes to milliseconds.

Read the original → en.wikipedia.org

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.