Why indexes speed up queries in MySQL - Performance Analysis
When we use indexes in databases, queries can find data faster. We want to understand how using an index changes the work the database does as the data grows.
How does the time to find data change when we have an index versus when we don't?
Analyze the time complexity of the following code snippet.
SELECT * FROM employees WHERE employee_id = 12345;
-- Assume employee_id is indexed in the second case
This query looks for one employee by their ID. We compare how it runs with and without an index on employee_id.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Scanning rows to find the matching employee_id.
- How many times: Without an index, it checks each row one by one. With an index, it uses a tree search to jump directly to the right row.
Explain the growth pattern intuitively.
| Input Size (n) | Approx. Operations Without Index | Approx. Operations With Index |
|---|---|---|
| 10 | 10 checks | About 4 steps |
| 100 | 100 checks | About 7 steps |
| 1000 | 1000 checks | About 10 steps |
Pattern observation: Without an index, the work grows directly with the number of rows. With an index, the work grows slowly, adding just a few steps even as data grows a lot.
Time Complexity: O(n) without index, O(log n) with index
This means without an index, the database checks every row, but with an index, it quickly narrows down to the right row using fewer steps.
[X] Wrong: "Adding an index makes the query instantly fast no matter what."
[OK] Correct: Indexes help a lot, but the speed still depends on data size and query type. Some queries don't benefit from indexes.
Understanding how indexes change query speed shows you know how databases handle data efficiently. This skill helps you write faster queries and explain your choices clearly.
"What if the query searched for a range of employee IDs instead of one? How would the time complexity change with and without an index?"
Practice
Solution
Step 1: Understand what an index does
An index works like a shortcut or a map to find data quickly instead of checking every row.Step 2: Compare with full table scan
Without an index, MySQL must look at every row, which is slow for big tables.Final Answer:
They create shortcuts to quickly find data without scanning the whole table. -> Option BQuick Check:
Indexes = shortcuts to data [OK]
- Confusing indexes with data compression
- Thinking indexes store all data in memory
- Believing indexes backup data automatically
email in a table users?Solution
Step 1: Recall the correct CREATE INDEX syntax
The correct syntax is: CREATE INDEX index_name ON table_name(column_name);Step 2: Match syntax with options
CREATE INDEX email_index ON users(email); matches the correct syntax exactly.Final Answer:
CREATE INDEX email_index ON users(email); -> Option DQuick Check:
CREATE INDEX index_name ON table(column) [OK]
- Swapping keywords order
- Missing ON keyword
- Placing index name after table name incorrectly
products(id INT, name VARCHAR(50), price DECIMAL) with an index on price, what will be the effect of this query?EXPLAIN SELECT * FROM products WHERE price = 100;Solution
Step 1: Understand EXPLAIN output with index
When a column has an index and the query filters on that column, MySQL uses the index to speed up search.Step 2: Analyze query behavior
The query filters by price = 100, so the index on price helps find rows without scanning all.Final Answer:
The query will use the index on price to find matching rows quickly. -> Option AQuick Check:
Index on filtered column = faster search [OK]
- Assuming index is ignored without hints
- Thinking syntax error occurs without hints
- Believing table locks always happen on SELECT
username but your query SELECT * FROM users WHERE username = 'alice'; is still slow. What could be the problem?Solution
Step 1: Check if index exists and is valid
If the index was not created correctly or got corrupted, MySQL won't use it, causing slow queries.Step 2: Verify query and column usage
The query syntax is correct and uses the indexed column, so syntax or column usage is not the issue.Final Answer:
The index was not created properly or is corrupted. -> Option CQuick Check:
Index missing or broken = slow query [OK]
- Blaming query syntax when it's correct
- Thinking indexes always slow queries
- Ignoring that column is used in WHERE clause
orders with columns order_id, customer_id, and order_date. You often run this query:SELECT * FROM orders WHERE customer_id = 123 AND order_date > '2023-01-01';Which indexing strategy will speed up this query best?
Solution
Step 1: Understand composite index benefits
A composite index on (customer_id, order_date) helps MySQL filter rows by both columns efficiently in one index.Step 2: Compare with separate indexes
Separate indexes may be used but are less efficient than a composite index for combined conditions.Final Answer:
Create a composite index on (customer_id, order_date). -> Option AQuick Check:
Composite index matches multi-column WHERE best [OK]
- Creating only single-column indexes for multi-column queries
- Assuming full table scan is faster on large tables
- Ignoring order of columns in composite index
Ready to prove it?
Pass the test and this pattern moves unknown
