Indexing improves query performance by allowing databases to locate data faster than scanning entire tables. When a database lacks an index for a column used in a query (like a WHERE clause), it must perform a full table scan, checking every row to find matches. This is slow, especially for large tables. An index acts like a sorted roadmap, storing a copy of the indexed column(s) alongside pointers to the original rows. For example, a B-tree index organizes data in a hierarchical structure, enabling the database to skip irrelevant rows and jump directly to relevant data. This reduces the number of disk reads and computational steps required.
A practical example: suppose a users table has 1 million rows, and a query searches for WHERE email = 'user@example.com'. Without an index, the database scans all 1 million rows. With a B-tree index on email, the database navigates the tree’s levels—starting at the root, comparing values to narrow down the search—until it finds the exact email. A B-tree’s logarithmic search time means even for 1 million rows, it might take just 3-4 steps (since log2(1M) ≈ 20, but B-trees have larger node fanouts). This difference between scanning 1M rows (linear time) vs. a few index steps (logarithmic time) is why indexing drastically speeds up queries.
However, indexes aren’t free. They consume storage and add overhead during writes (e.g., INSERT, UPDATE), as the database must update both the table and the index. Indexes are most effective for columns used frequently in search conditions or joins, and when the data has high selectivity (e.g., unique emails). For columns with low selectivity (e.g., a gender column with only two values), indexes may not help. Developers should analyze query patterns and balance read speed gains against write performance costs. Properly applied, indexing is a foundational tool for optimizing database performance.