Subqueries vs JOINs comparison in MySQL - Performance Comparison
When we use subqueries or JOINs in SQL, the way the database processes data can change how long it takes to get results.
We want to understand how the time to run these queries grows as the data gets bigger.
Analyze the time complexity of these two queries that find orders with customer details.
-- Using a subquery
SELECT order_id, customer_name
FROM orders
WHERE customer_id IN (
SELECT customer_id FROM customers WHERE country = 'USA'
);
-- Using a JOIN
SELECT o.order_id, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE c.country = 'USA';
Both queries get orders from customers in the USA but use different methods.
Look at what repeats as data grows:
- Primary operation: Scanning and matching rows between orders and customers tables.
- How many times: For each order, the database checks matching customers (either via subquery or join).
As the number of orders (n) and customers (m) grow, the work to find matches changes:
| Input Size (orders n, customers m) | Approx. Operations |
|---|---|
| 10, 10 | About 100 checks |
| 100, 100 | About 10,000 checks |
| 1000, 1000 | About 1,000,000 checks |
Pattern observation: The number of operations grows roughly with the product of the two table sizes.
Time Complexity: O(n x m)
This means the time to run the query grows roughly with how many orders and customers there are multiplied together.
[X] Wrong: "JOINs always run faster than subqueries because they look simpler."
[OK] Correct: Both can have similar time costs depending on indexes and data size; the database engine decides the best way to run them.
Understanding how subqueries and JOINs scale helps you write efficient queries and explain your choices clearly in real projects and interviews.
What if we added an index on customer_id in both tables? How would the time complexity change?
Practice
JOIN and a subquery in MySQL?Solution
Step 1: Understand the role of JOIN
A JOIN combines rows from two or more tables side-by-side based on a related column between them.Step 2: Understand the role of subqueries
A subquery is a query nested inside another query, often used to filter or find specific values before the main query runs.Final Answer:
JOIN combines tables side-by-side; subqueries run inside another query to filter or find values. -> Option CQuick Check:
JOIN = combine tables, Subquery = nested query [OK]
- Confusing JOINs as nested queries
- Thinking subqueries combine tables side-by-side
- Believing JOINs and subqueries have identical performance always
employees and departments on the column department_id?Solution
Step 1: Identify correct JOIN syntax
The correct JOIN syntax uses the ON keyword to specify the matching columns between tables.Step 2: Check each option
SELECT * FROM employees JOIN departments ON employees.department_id = departments.department_id; uses ON correctly. SELECT * FROM employees JOIN departments WHERE employees.department_id = departments.department_id; incorrectly uses WHERE instead of ON. SELECT * FROM employees, departments ON employees.department_id = departments.department_id; uses comma join but incorrectly adds ON. SELECT * FROM employees JOIN departments USING employees.department_id; misuses USING with full column name.Final Answer:
SELECT * FROM employees JOIN departments ON employees.department_id = departments.department_id; -> Option DQuick Check:
JOIN requires ON for matching columns [OK]
- Using WHERE instead of ON for JOIN condition
- Using comma join with ON clause
- Incorrect USING syntax with full column names
orders(order_id, customer_id, amount) and customers(customer_id, name), what will the following query return?SELECT name FROM customers WHERE customer_id IN (SELECT customer_id FROM orders WHERE amount > 100);
Solution
Step 1: Analyze the subquery
The subquery selects customer_id from orders where amount is greater than 100.Step 2: Analyze the main query
The main query selects names from customers where customer_id is in the list returned by the subquery.Final Answer:
Names of customers who have orders with amount greater than 100. -> Option AQuick Check:
Subquery filters customers by order amount [OK]
- Assuming all customers are returned
- Thinking it returns customers without orders
- Believing subquery causes syntax error
SELECT e.name, d.department_name FROM employees e JOIN departments d WHERE e.department_id = d.department_id;
Solution
Step 1: Check JOIN syntax
JOIN requires the ON keyword to specify the join condition between tables.Step 2: Identify the mistake
The query uses WHERE instead of ON to specify the join condition, which is incorrect syntax.Final Answer:
Missing ON keyword before the join condition. -> Option BQuick Check:
JOIN needs ON, not WHERE, for conditions [OK]
- Using WHERE instead of ON for JOIN
- Confusing HAVING with JOIN condition
- Assuming aliases cause error
SELECT name FROM customers WHERE customer_id IN (SELECT customer_id FROM orders);
Solution
Step 1: Understand the original subquery
The subquery selects customer_ids from orders, filtering customers who placed orders.Step 2: Translate to JOIN
Using JOIN on customer_id between customers and orders returns matching customers. DISTINCT is needed to avoid duplicates.Step 3: Evaluate options
SELECT DISTINCT c.name FROM customers c JOIN orders o ON c.customer_id = o.customer_id; uses JOIN with ON and DISTINCT correctly. SELECT c.name FROM customers c JOIN orders o WHERE c.customer_id = o.customer_id; misses ON keyword. SELECT c.name FROM customers c, orders o WHERE c.customer_id = o.customer_id; uses old-style join but is valid but may return duplicates. SELECT name FROM customers LEFT JOIN orders ON customer_id = customer_id; uses LEFT JOIN but ON condition is ambiguous.Final Answer:
SELECT DISTINCT c.name FROM customers c JOIN orders o ON c.customer_id = o.customer_id; -> Option AQuick Check:
JOIN with ON and DISTINCT matches subquery result [OK]
- Omitting ON keyword in JOIN
- Not using DISTINCT causing duplicates
- Using ambiguous ON conditions
Ready to prove it?
Pass the test and this pattern moves unknown
