Why Your SQL Queries Are Slow

Welcome to **Phase 7: Performance Optimization**! Today is **Day 86**, and we're looking under the hood of the database engine.

The Physical Reality

When you run `SELECT * FROM users WHERE email = 'bob@example.com'`, the database doesn't just "Know" where Bob is.

If there is no index, it has to:

1. Open the file on the hard drive.

2. Read the first row.

3. Compare the email.

4. Read the second row...

5. ...and so on for every single row in the table.

This is called a **Full Table Scan**, and it's the biggest performance killer in SQL.

**1,000 rows**: A table scan takes 0.001 seconds. (You don't care).

**1,000,000 rows**: A table scan takes 2 seconds. (Your users start to complain).

**100,000,000 rows**: A table scan takes 5 minutes. (Your server crashes).

Over the next 10 days, we'll learn:

**Indexes**: The "Table of Contents" for your data.

**EXPLAIN ANALYZE**: Reading the database's mind.

**Query Refactoring**: Making the same logic run 100x faster.

**Joins and Loops**: Avoiding the "N+1" performance trap.

Think about your most used table. How many rows does it have? If it's over 10,000, it's time to start thinking about performance.

*Day 87: Introduction to Indexes (B-Trees).*