EXPLAIN query analysis in MySQL - Step-by-Step Execution

Concept Flow - EXPLAIN query analysis

Write SQL Query

↓

Run EXPLAIN on Query

↓

MySQL Analyzes Query

↓

Output Query Plan

↓

Review Execution Details

↓

Optimize Query Based on Plan

You write a SQL query, run EXPLAIN on it, MySQL shows how it plans to run it, then you use that info to improve your query.

Execution Sample

MySQL

EXPLAIN SELECT * FROM employees WHERE department_id = 5;

This command shows how MySQL plans to execute the SELECT query filtering employees by department.

Execution Table

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	employees	ref	department_id	department_id	4	const	10	Using where
-	-	-	-	-	-	-	-	-	Query plan shows MySQL uses index on department_id to find 10 rows matching condition

💡 EXPLAIN output ends after showing the query plan details for the given query.

Variable Tracker

Variable	Start	After EXPLAIN
id	N/A	1
select_type	N/A	SIMPLE
table	N/A	employees
type	N/A	ref
possible_keys	N/A	department_id
key	N/A	department_id
key_len	N/A	4
ref	N/A	const
rows	N/A	10
Extra	N/A	Using where

Key Moments - 3 Insights

Why does the 'type' column say 'ref' instead of 'ALL'?

Because the execution_table shows MySQL uses an index (key 'department_id') to find matching rows, so it scans only relevant rows, not the whole table ('ALL').

What does 'Using where' in the Extra column mean?

'Using where' means MySQL applies the WHERE condition to filter rows after using the index, as shown in the last row of execution_table.

Why is 'rows' estimated as 10?

The 'rows' column estimates how many rows MySQL expects to examine, here 10, based on index statistics, as seen in the execution_table row.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'key' used by MySQL?

A PRIMARY

B department_id

C NULL

D employees

💡 Hint

Check the 'key' column in the first row of the execution_table.

At which step does MySQL apply the WHERE condition according to the EXPLAIN output?

A Before using the index

B After scanning all rows

C After using the index (Using where)

D It does not apply WHERE

💡 Hint

Look at the 'Extra' column in the execution_table for the phrase 'Using where'.

If the 'type' was 'ALL' instead of 'ref', what would that mean?

A MySQL scans the entire table

B MySQL uses an index to find rows

C MySQL uses a temporary table

D MySQL uses a join

💡 Hint

Refer to the 'type' column meaning in the execution_table and key_moments explanations.

Concept Snapshot

EXPLAIN shows how MySQL runs a query.
It outputs a table with columns like id, type, key, rows.
'key' shows index used; 'type' shows scan method.
'Extra' gives extra info like 'Using where'.
Use EXPLAIN to find slow parts and optimize queries.

Full Transcript

The EXPLAIN command in MySQL helps you see how the database plans to run your SQL query. When you write a query and run EXPLAIN before it, MySQL returns a table describing each step it will take. This includes which table it reads, what type of scan it uses (like index or full scan), which index it uses, how many rows it expects to check, and extra notes like if it applies a WHERE filter. For example, if the 'type' column says 'ref', it means MySQL uses an index to find rows efficiently. If it says 'ALL', it scans the whole table, which is slower. The 'Extra' column can say 'Using where' meaning it filters rows after using the index. By reading this output, you can understand if your query is efficient or if it needs optimization. This visual trace shows the step-by-step output of EXPLAIN for a simple SELECT query filtering by department_id, helping beginners see how MySQL executes queries internally.

Practice

1. What is the main purpose of using EXPLAIN before a SELECT query in MySQL?

easy

A. To create a backup of the database

B. To run the query faster by optimizing it automatically

C. To delete rows from the table before selecting

D. To see how MySQL plans to execute the query and find performance issues

Solution

1. 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.

2. 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.

3. Final Answer:

   To see how MySQL plans to execute the query and find performance issues -> Option D

4. Quick Check:

   EXPLAIN shows query plan = D [OK]

Hint: EXPLAIN shows query plan, not actual data changes [OK]

Common Mistakes:

• Thinking EXPLAIN runs the query faster
• Confusing EXPLAIN with data modification commands
• Assuming EXPLAIN creates backups

2. Which of the following is the correct syntax to use EXPLAIN with a SELECT query in MySQL?

easy

A. EXPLAIN * SELECT FROM users;

B. EXPLAIN SELECT * FROM users;

C. SELECT EXPLAIN * FROM users;

D. SELECT * FROM users EXPLAIN;

Solution

1. Step 1: Recall the correct EXPLAIN syntax

   The correct syntax is to write EXPLAIN before the SELECT statement: EXPLAIN SELECT ....

2. 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.

3. Final Answer:

   EXPLAIN SELECT * FROM users; -> Option B

4. Quick Check:

   EXPLAIN before SELECT = C [OK]

Hint: Put EXPLAIN right before SELECT to check query plan [OK]

Common Mistakes:

• Placing EXPLAIN after SELECT or at the end
• Using EXPLAIN as a function inside SELECT
• Writing EXPLAIN in the wrong order

3. Given the table 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?

medium

A. ALL

B. index

C. ref

D. const

Solution

1. 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.

2. 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.

3. Final Answer:

   ref -> Option C

4. Quick Check:

   Index lookup by reference = ref = B [OK]

Hint: 'ref' means index used for matching rows, not full scan [OK]

Common Mistakes:

• Confusing 'ALL' with index usage
• Thinking 'index' means index lookup by key
• Assuming 'const' applies to indexed foreign keys

4. You run EXPLAIN SELECT * FROM orders WHERE customer_id = 5; but notice the type column shows ALL. What is the most likely reason?

medium

A. There is no index on customer_id

B. The query syntax is incorrect

C. The table is empty

D. MySQL automatically ignores indexes

Solution

1. 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.

2. 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.

3. Final Answer:

   There is no index on customer_id -> Option A

4. Quick Check:

   Full scan means missing index = A [OK]

Hint: 'ALL' means full scan, usually missing index on filter column [OK]

Common Mistakes:

• Assuming syntax error causes 'ALL'
• Thinking empty table causes 'ALL'
• Believing MySQL ignores indexes by default

5. You have a query joining 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?

hard

A. Add an index on products.category_id

B. Rewrite the query without JOIN

C. Add an index on categories.category_id

D. Use SELECT * instead of specific columns

Solution

1. Step 1: Analyze EXPLAIN output for join

   'ALL' on products means full scan; 'ref' on categories means index used there.

2. Step 2: Identify missing index

   Since products is scanned fully, adding an index on products.category_id helps MySQL find matching rows faster.

3. 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.

4. Final Answer:

   Add an index on products.category_id -> Option A

5. Quick Check:

   Full scan means missing index on join column = A [OK]

Hint: Add index on table with 'ALL' type to speed up joins [OK]

Common Mistakes:

• Adding index on already indexed table
• Removing JOIN instead of indexing
• Ignoring EXPLAIN 'type' column meaning