Database Index Explorer | mysimulator.uk

Access Method

Table size 32 rows

Scan speed 18 rows/s

Records examined

–

Table size (N)

–

Complexity this run

–

Status

Idle

Last query time

–

How it works

A relational table's rows are stored in some physical order that has nothing to do with the value you're searching for. Without an index, the database engine has no choice but to read rows one at a time — a full table scan — until it happens to find the one you want. On average that costs about N/2 reads and in the worst case N reads, where N is the row count.

A B-tree index keeps a separate, sorted lookup structure alongside the table. Each node holds a small number of keys and pointers to the next level, so every comparison eliminates a large fraction of the remaining rows. Descending from the root to a leaf takes only a handful of steps — the tree's height — and that height grows logarithmically, not linearly, as the table grows.

full scan:  steps ≈ N        →  O(N)
with index: steps ≈ log₂(N)  →  O(log N)

Table size — number of rows N; grow it and watch the full-scan bar chase it up 1:1 while the index's step count barely moves.
Access method — toggle between reading the table sequentially and descending the B-tree index for the same query.
Run query — picks a fresh random target row and animates the search for the current access method and table size.
Scan speed — how many rows the full-scan animation reads per second (index descent is always shown one level per step).

Real-world relevance: this is exactly why CREATE INDEX on a frequently-queried column can turn a query that reads millions of rows into one that reads a dozen — the single biggest lever most applications have over database performance.

Unvisited row Scanned row Target found Index node visited

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.