Query optimization techniques in MySQL - Time & Space Complexity
When we optimize queries, we want to know how the time to run them changes as data grows.
We ask: How does the work needed grow when the database gets bigger?
Analyze the time complexity of the following code snippet.
SELECT orders.order_id, customers.customer_name
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
WHERE orders.order_date > '2023-01-01';
This query joins two tables and filters orders after a certain date.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Scanning rows in orders and matching with customers.
- How many times: Once for each order, then matching customer for each order.
As the number of orders grows, the work to find matching customers grows too.
| Input Size (n orders) | Approx. Operations |
|---|---|
| 10 | About 10 order checks and matches |
| 100 | About 100 order checks and matches |
| 1000 | About 1000 order checks and matches |
Pattern observation: The work grows roughly in direct proportion to the number of orders.
Time Complexity: O(n)
This means the time to run the query grows linearly with the number of orders.
[X] Wrong: "Adding indexes always makes queries run instantly regardless of data size."
[OK] Correct: Indexes help but the query still needs to check matching rows, so time grows with data size, just usually slower.
Understanding how query time grows helps you explain how to keep databases fast as they get bigger.
"What if we added an index on orders.order_date? How would the time complexity change?"
Practice
Solution
Step 1: Understand what indexes do
Indexes help the database find rows faster by creating a quick lookup structure.Step 2: Relate indexes to query speed
By reducing the number of rows scanned, indexes speed up data retrieval significantly.Final Answer:
To speed up data retrieval by reducing the search area -> Option BQuick Check:
Indexes improve search speed = D [OK]
- Thinking indexes increase database size only
- Confusing indexes with backups
- Believing indexes encrypt data
Solution
Step 1: Recall the command to view query plans
MySQL uses the EXPLAIN keyword before a SELECT query to show the execution plan.Step 2: Identify the correct syntax
Only EXPLAIN SELECT * FROM users; is valid syntax to check the plan.Final Answer:
EXPLAIN SELECT * FROM users; -> Option AQuick Check:
EXPLAIN shows query plan = C [OK]
- Using SHOW PLAN which is invalid in MySQL
- Forgetting EXPLAIN keyword
- Confusing DESCRIBE with EXPLAIN
employees(id INT PRIMARY KEY, name VARCHAR(50), department_id INT) with an index on department_id, what will be the effect of this query?SELECT * FROM employees WHERE department_id = 5;Solution
Step 1: Understand index usage on department_id
Since there is an index on department_id, MySQL can use it to locate matching rows efficiently.Step 2: Analyze query behavior
The WHERE clause filters by department_id = 5, so the index helps avoid scanning all rows.Final Answer:
The query will use the index to quickly find rows with department_id = 5 -> Option DQuick Check:
Index on filter column speeds query = B [OK]
- Assuming index is ignored automatically
- Thinking query fails without index
- Believing indexes filter out rows
SELECT * FROM orders WHERE customer_id = 10 AND status = 'shipped';You notice it runs slowly. Which fix will most likely improve performance?
Solution
Step 1: Identify slow query cause
The query filters on two columns but may lack a composite index to speed filtering.Step 2: Apply composite index for optimization
Adding an index on (customer_id, status) helps MySQL quickly find matching rows using both filters.Final Answer:
Add an index on (customer_id, status) -> Option CQuick Check:
Composite index speeds multi-column filters = A [OK]
- Removing WHERE clause loses filtering
- ORDER BY does not speed filtering
- Changing SELECT * to COUNT(*) changes result, not speed
sales(date DATE, product_id INT, amount DECIMAL) without indexes. You want to find total sales for product 101 in 2023 quickly. Which optimization technique is best?Solution
Step 1: Identify query needs
The query filters by product_id and date range, so indexing these columns helps speed filtering.Step 2: Apply composite index for efficient filtering
Creating an index on (product_id, date) allows MySQL to quickly find relevant rows without scanning the whole table.Final Answer:
Create an index on (product_id, date) and use a query filtering both -> Option AQuick Check:
Composite index on filter columns = A [OK]
- Forcing full table scan slows query
- Selecting all rows wastes time
- Dropping table loses data
Ready to prove it?
Pass the test and this pattern moves unknown
