EXPLAIN query analysis in MySQL - Time & Space Complexity
When we use EXPLAIN in MySQL, we want to see how the database plans to run a query.
We ask: How does the work grow as the data grows?
Analyze the time complexity of the following query plan.
EXPLAIN SELECT * FROM orders WHERE customer_id = 123;
This query fetches all orders for one customer by filtering on customer_id.
Look at what repeats when the query runs.
- Primary operation: Scanning rows in the orders table.
- How many times: Once for each row until matching rows are found.
As the number of orders grows, the work to find matching rows changes.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 rows checked |
| 100 | 100 rows checked |
| 1000 | 1000 rows checked |
Pattern observation: The work grows directly with the number of rows if no index is used.
Time Complexity: O(n)
This means the time to run the query grows linearly with the number of rows in the table.
[X] Wrong: "EXPLAIN always shows the exact time the query will take."
[OK] Correct: EXPLAIN shows the plan and estimated steps, not the exact time, which depends on data and indexes.
Understanding EXPLAIN helps you see how databases handle queries, a useful skill for writing fast queries and solving problems.
"What if we added an index on customer_id? How would the time complexity change?"
Practice
EXPLAIN before a SELECT query in MySQL?Solution
Step 1: Understand the role of EXPLAIN
EXPLAIN shows the execution plan MySQL uses for a query, helping to understand how tables and indexes are accessed.Step 2: Identify what EXPLAIN does not do
EXPLAIN does not run the query faster, delete data, or create backups; it only provides information about query execution.Final Answer:
To see how MySQL plans to execute the query and find performance issues -> Option DQuick Check:
EXPLAIN shows query plan = D [OK]
- Thinking EXPLAIN runs the query faster
- Confusing EXPLAIN with data modification commands
- Assuming EXPLAIN creates backups
Solution
Step 1: Recall the correct EXPLAIN syntax
The correct syntax is to write EXPLAIN before the SELECT statement:EXPLAIN SELECT ....Step 2: Check each option
EXPLAIN SELECT * FROM users; uses the correct syntax. Options A, B, and D place EXPLAIN incorrectly and will cause syntax errors.Final Answer:
EXPLAIN SELECT * FROM users; -> Option BQuick Check:
EXPLAIN before SELECT = C [OK]
- Placing EXPLAIN after SELECT or at the end
- Using EXPLAIN as a function inside SELECT
- Writing EXPLAIN in the wrong order
employees(id, name, department_id) with an index on department_id, what does the type column in EXPLAIN output usually show when the index is used?Solution
Step 1: Understand EXPLAIN 'type' values
The 'type' column shows how MySQL accesses rows. 'ALL' means full table scan, 'ref' means index lookup by reference, 'index' means full index scan, and 'const' means constant lookup.Step 2: Identify index usage for a foreign key
When searching by an indexed column like department_id, MySQL uses 'ref' to find matching rows efficiently.Final Answer:
ref -> Option CQuick Check:
Index lookup by reference = ref = B [OK]
- Confusing 'ALL' with index usage
- Thinking 'index' means index lookup by key
- Assuming 'const' applies to indexed foreign keys
EXPLAIN SELECT * FROM orders WHERE customer_id = 5; but notice the type column shows ALL. What is the most likely reason?Solution
Step 1: Interpret 'ALL' in EXPLAIN output
'ALL' means MySQL is scanning the entire table, which is slow and usually means no index is used.Step 2: Identify cause of full table scan
If the query filters by customer_id but no index exists on that column, MySQL must scan all rows.Final Answer:
There is no index oncustomer_id-> Option AQuick Check:
Full scan means missing index = A [OK]
- Assuming syntax error causes 'ALL'
- Thinking empty table causes 'ALL'
- Believing MySQL ignores indexes by default
products and categories tables on category_id. EXPLAIN shows type as ALL for products and ref for categories. What is the best way to improve performance?Solution
Step 1: Analyze EXPLAIN output for join
'ALL' on products means full scan; 'ref' on categories means index used there.Step 2: Identify missing index
Since products is scanned fully, adding an index on products.category_id helps MySQL find matching rows faster.Step 3: Evaluate other options
Rewriting query or adding index on categories.category_id won't help if products lacks index. SELECT * vs specific columns affects data size, not join efficiency.Final Answer:
Add an index onproducts.category_id-> Option AQuick Check:
Full scan means missing index on join column = A [OK]
- Adding index on already indexed table
- Removing JOIN instead of indexing
- Ignoring EXPLAIN 'type' column meaning
Ready to prove it?
Pass the test and this pattern moves unknown
