Your interviewer has just heard your data model, and asks the obvious follow-up: that query runs against fifty million rows, so how does it come back in under a second? The answer is almost always an index. An index is a second copy of a few columns from your table, kept in sorted order, with a pointer from each entry back to the full row. Because it is sorted, the database can jump to the entries it wants instead of looking at every row in the table. Because it is a separate copy, the database has to keep it up to date every time the table changes.

Indexing shows up in nearly every backend and system design interview. It usually comes up after you name the tables and access patterns, and takes five to ten minutes in a general round or much longer in a database-focused one.

Level determines how deeply you need to cover the topic. At mid-level, recognizing what an index is and that it is not free is usually enough. A senior answer also diagnoses an index the database refuses to use.

This tutorial covers indexing as the database's access path inside a single engine, because that is where the interview question usually lives. Secondary indexes in a sharded store and dedicated search systems apply similar ideas at another layer. You should be able to explain what a scan costs and what an index changes, choose a structure for a stated access pattern, write a specific index for a specific query, price it against writes and memory, and work out why an existing index is not being used.