JOIN performance considerations in MySQL - Step-by-Step Execution

Concept Flow - JOIN performance considerations

Start Query

↓

Parse JOIN Condition

↓

Check Indexes on Join Columns

↓

Use Index

↓

Join Rows Efficiently

↓

Return Result Set

This flow shows how a JOIN query is processed, focusing on whether indexes exist on join columns to improve performance.

Execution Sample

MySQL

SELECT * FROM orders
JOIN customers ON orders.customer_id = customers.id
WHERE customers.country = 'USA';

This query joins orders with customers on customer_id and filters customers from the USA.

Execution Table

Step	Action	Index Used?	Rows Scanned	Result
1	Parse JOIN condition orders.customer_id = customers.id	N/A	N/A	Ready to join
2	Check index on orders.customer_id	Yes	1000 (using index)	Efficient lookup
3	Check index on customers.id	Yes	100 (using index)	Efficient lookup
4	Filter customers by country = 'USA'	Yes (index on country)	20	Filtered customers
5	Join filtered customers with orders using indexes	Yes	200	Joined rows
6	Return final result set	N/A	200	Result with joined rows
7	Exit	N/A	N/A	Query complete

💡 Indexes on join columns and filter column reduce scanned rows, improving performance.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
Rows Scanned on orders	N/A	1000	1000	200	200
Rows Scanned on customers	N/A	100	20	20	20
Result Rows	N/A	N/A	N/A	200	200

Key Moments - 3 Insights

Why does having an index on the join columns matter?

Indexes allow the database to quickly find matching rows instead of scanning the entire table, as shown in steps 2 and 3 where indexes reduce rows scanned.

What happens if there is no index on the filter column (customers.country)?

Without an index, the database scans all customer rows to filter, increasing rows scanned and slowing the join, unlike step 4 where an index reduces rows to 20.

Why does the number of rows scanned decrease after filtering customers?

Filtering customers by country reduces the dataset before joining, so fewer rows need to be matched in step 5, improving performance.

Visual Quiz - 3 Questions

Look at the execution table, how many rows are scanned on the customers table after filtering by country?

A 100

B 200

C 20

D 1000

💡 Hint

Check the 'Rows Scanned' column at step 4 in the execution table.

At which step does the query use indexes on both join columns?

A Step 1

B Step 3

C Step 5

D Step 7

💡 Hint

Look for 'Check index on customers.id' in the execution table.

If there was no index on orders.customer_id, what would likely happen to rows scanned at step 2?

A Rows scanned would increase to full table scan

B Rows scanned would stay the same

C Rows scanned would decrease

D Query would fail

💡 Hint

Refer to the decision branch in the concept flow about index presence.

Concept Snapshot

JOIN performance depends on indexes on join columns.
Indexes reduce rows scanned by enabling fast lookups.
Filtering before joining reduces data to process.
Without indexes, full table scans slow queries.
Always check indexes on join and filter columns.

Full Transcript

This visual execution shows how a JOIN query runs in MySQL focusing on performance. The query joins orders and customers on customer_id and filters customers by country. The database first parses the join condition, then checks for indexes on join columns. If indexes exist, it uses them to scan fewer rows. Filtering customers by country uses an index to reduce rows from 100 to 20 before joining. The join then matches 200 rows efficiently using indexes. The final result set contains 200 joined rows. Key points are that indexes on join and filter columns reduce scanned rows and improve speed. Without indexes, the database would scan entire tables, slowing the query. This step-by-step trace helps beginners see how indexes affect join performance.

Practice

1. Which factor most improves the performance of a JOIN operation in MySQL?

easy

A. Having indexes on the columns used in the JOIN condition

B. Using SELECT * to retrieve all columns

C. Joining tables without any WHERE clause

D. Using subqueries instead of JOINs

Solution

1. Step 1: Understand JOIN performance basics

   JOINs work faster when MySQL can quickly find matching rows using indexes on the join columns.

2. Step 2: Evaluate options for performance impact

   Using SELECT * or no WHERE clause does not improve speed; subqueries often perform worse than JOINs.

3. Final Answer:

   Having indexes on the columns used in the JOIN condition -> Option A

4. Quick Check:

   Indexes speed up JOINs = B [OK]

Hint: Indexes on join columns speed up JOINs [OK]

Common Mistakes:

• Thinking SELECT * is faster
• Ignoring the need for indexes
• Assuming subqueries are always faster

2. Which of the following is the correct syntax to perform an INNER JOIN between tables orders and customers on customer_id?

easy

A. SELECT * FROM orders JOIN customers ON orders.customer_id = customers.customer_id;

B. SELECT * FROM orders INNER JOIN customers WHERE orders.customer_id = customers.customer_id;

C. SELECT * FROM orders JOIN customers USING (customer_id);

D. SELECT * FROM orders, customers ON orders.customer_id = customers.customer_id;

Solution

1. Step 1: Review INNER JOIN syntax

   The correct INNER JOIN syntax uses JOIN ... ON condition, like in SELECT * FROM orders JOIN customers ON orders.customer_id = customers.customer_id;.

2. Step 2: Check other options for syntax errors

   SELECT * FROM orders INNER JOIN customers WHERE orders.customer_id = customers.customer_id; uses WHERE instead of ON, which is invalid for JOIN syntax. SELECT * FROM orders JOIN customers USING (customer_id); requires parentheses around the column name. SELECT * FROM orders, customers ON orders.customer_id = customers.customer_id; mixes comma join with ON, which is invalid.

3. Final Answer:

   SELECT * FROM orders JOIN customers ON orders.customer_id = customers.customer_id; -> Option A

4. Quick Check:

   JOIN ... ON is correct syntax = A [OK]

Hint: Use JOIN ... ON for correct INNER JOIN syntax [OK]

Common Mistakes:

• Using WHERE instead of ON for JOIN condition
• Mixing comma joins with ON clause
• Incorrect use of USING without parentheses

3. Given the tables:
employees(id, name, dept_id)
departments(id, dept_name)
and the query:

SELECT e.name, d.dept_name FROM employees e JOIN departments d ON e.dept_id = d.id WHERE d.dept_name = 'Sales';

What will be the result if there are 3 employees in 'Sales' department?

medium

A. Empty result because of missing GROUP BY

B. All employees regardless of department

C. Only department names without employee names

D. 3 rows with employee names and 'Sales' as dept_name

Solution

1. Step 1: Analyze the JOIN and WHERE clause

   The JOIN matches employees to departments by dept_id. The WHERE filters to only 'Sales' department.

2. Step 2: Determine output rows

   Since 3 employees belong to 'Sales', the query returns 3 rows with their names and 'Sales' as dept_name.

3. Final Answer:

   3 rows with employee names and 'Sales' as dept_name -> Option D

4. Quick Check:

   JOIN + WHERE filters = 3 matching rows [OK]

Hint: WHERE filters rows after JOIN, so only matching rows show [OK]

Common Mistakes:

• Assuming all employees are returned
• Expecting aggregation without GROUP BY
• Thinking only department names are returned

4. You wrote this query but it runs very slowly:

SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.country = 'USA';

What is the most likely cause of poor performance?

medium

A. JOIN condition uses wrong columns

B. Using SELECT * instead of specific columns

C. Missing index on customers.country column

D. WHERE clause should be in the JOIN condition

Solution

1. Step 1: Identify performance bottleneck

   The WHERE clause filters by c.country = 'USA'. Without an index on country, MySQL scans all customers.

2. Step 2: Evaluate other options

   SELECT * does not cause slow JOINs. JOIN condition is correct. WHERE clause placement is valid.

3. Final Answer:

   Missing index on customers.country column -> Option C

4. Quick Check:

   Index missing on filter column = C [OK]

Hint: Index columns used in WHERE filters for faster JOINs [OK]

Common Mistakes:

• Blaming SELECT * for slow performance
• Misplacing WHERE clause inside JOIN
• Assuming JOIN condition is incorrect

5. You have two large tables: products (1 million rows) and sales (10 million rows). You want to find total sales per product. Which approach improves JOIN performance the most?

hard

A. Use a subquery to get sales totals, then join with products without indexes

B. Create indexes on sales.product_id and products.id, then use INNER JOIN with GROUP BY

C. Join without indexes and filter results in application code

D. Use CROSS JOIN and filter with WHERE clause

Solution

1. Step 1: Understand data size and join keys

   Large tables require indexes on join keys to avoid full scans and speed up matching.

2. Step 2: Evaluate join strategies

   INNER JOIN with proper indexes and GROUP BY efficiently aggregates sales per product. Subqueries without indexes or CROSS JOIN cause slow performance.

3. Final Answer:

   Create indexes on sales.product_id and products.id, then use INNER JOIN with GROUP BY -> Option B

4. Quick Check:

   Indexes + JOIN + GROUP BY = best performance [OK]

Hint: Index join keys and aggregate in SQL, not app [OK]

Common Mistakes:

• Skipping indexes on join columns
• Using CROSS JOIN causing huge intermediate results
• Filtering in application instead of SQL