Every backend developer has typed ->index() in a migration at some point. Fewer have stopped to ask: what does the database engine actually do with that?
This article walks through indexes from first principles — B+Trees, how MySQL decides whether to use an index at all, why column order in a composite index matters, and how to read an EXPLAIN output like an engineer instead of guessing. Examples use MySQL/InnoDB and Laravel, but the concepts carry over to Postgres too.
Why indexes exist in the first place
A table without an index is just rows sitting on disk in pages. To find one row, the engine has no choice but to read pages one after another and check each row against your WHERE clause — a full table scan.
SELECT * FROM users WHERE email = 'ali@example.com';
