Multiple LEFT JOINs in one query in SQL - Time & Space Complexity

Time Complexity: Multiple LEFT JOINs in one query

O(n)

Understanding Time Complexity

When we use multiple LEFT JOINs in a SQL query, the database combines rows from several tables. We want to understand how the time to run this query grows as the tables get bigger.

How does adding more tables or more rows affect the work the database does?

Scenario Under Consideration

Analyze the time complexity of the following SQL query with multiple LEFT JOINs.

SELECT a.id, b.info, c.details
FROM tableA a
LEFT JOIN tableB b ON a.id = b.a_id
LEFT JOIN tableC c ON a.id = c.a_id;
    

This query selects data from tableA and adds matching rows from tableB and tableC if they exist.

Identify Repeating Operations

Look for repeated work the database does when joining tables.

• Primary operation: For each row in tableA, the database searches for matching rows in tableB and tableC.
• How many times: This happens once per row in tableA, and for each LEFT JOIN, it looks up matches in the other tables.

How Execution Grows With Input

As the number of rows in tableA grows, the database must do more lookups in tableB and tableC.

Input Size (rows in tableA)	Approx. Operations
10	About 10 lookups in tableB and 10 in tableC
100	About 100 lookups in tableB and 100 in tableC
1000	About 1000 lookups in tableB and 1000 in tableC

Pattern observation: The work grows roughly in direct proportion to the number of rows in the main table.

Final Time Complexity

Time Complexity: O(n)

This means the time to run the query grows roughly in a straight line as the main table gets bigger.

Common Mistake

[X] Wrong: "Adding more LEFT JOINs multiplies the time by the size of all tables combined, making it exponential."

[OK] Correct: The database usually uses indexes to find matches quickly, so the time grows mostly with the size of the main table, not the product of all tables.

Interview Connect

Understanding how multiple LEFT JOINs affect query time helps you write efficient queries and explain your reasoning clearly in interviews. It shows you know how databases handle combining data from many tables.

Self-Check

What if we changed the LEFT JOINs to INNER JOINs? How would the time complexity change?

Practice

1. What is the main purpose of using multiple LEFT JOIN clauses in a single SQL query?

easy

A. To delete rows from multiple tables at once

B. To combine rows from several tables while keeping all rows from the first table

C. To return only rows that have matching values in all joined tables

D. To update multiple tables simultaneously

Solution

1. Step 1: Understand LEFT JOIN behavior

   A LEFT JOIN returns all rows from the left (first) table and matching rows from the right table. If no match, NULLs appear.

2. Step 2: Apply to multiple LEFT JOINs

   Using multiple LEFT JOINs keeps all rows from the main table and adds data from each joined table if available.

3. Final Answer:

   To combine rows from several tables while keeping all rows from the first table -> Option B

4. Quick Check:

   Multiple LEFT JOINs keep all main table rows [OK]

Hint: LEFT JOIN keeps all main table rows even if others miss data [OK]

Common Mistakes:

• Confusing LEFT JOIN with INNER JOIN which filters rows
• Thinking LEFT JOIN deletes or updates data
• Assuming NULLs mean errors instead of missing matches

2. Which of the following SQL queries correctly uses multiple LEFT JOINs to combine tables orders, customers, and payments?

easy

A. SELECT o.id, c.name, p.amount FROM orders o LEFT JOIN customers c ON o.customer_id = c.id LEFT JOIN payments p ON o.id = p.order_id;

B. SELECT o.id, c.name, p.amount FROM orders o JOIN customers c ON o.customer_id = c.id JOIN payments p ON o.id = p.order_id;

C. SELECT o.id, c.name, p.amount FROM orders o LEFT JOIN customers c ON c.id = o.customer_id RIGHT JOIN payments p ON p.order_id = o.id;

D. SELECT o.id, c.name, p.amount FROM orders o INNER JOIN customers c ON o.customer_id = c.id LEFT JOIN payments p ON o.id = p.order_id;

Solution

1. Step 1: Check JOIN types

   SELECT o.id, c.name, p.amount FROM orders o LEFT JOIN customers c ON o.customer_id = c.id LEFT JOIN payments p ON o.id = p.order_id; uses LEFT JOIN twice, correctly keeping all orders and adding customer and payment info if available.

2. Step 2: Identify errors in other options

   SELECT o.id, c.name, p.amount FROM orders o JOIN customers c ON o.customer_id = c.id JOIN payments p ON o.id = p.order_id; uses INNER JOINs, which exclude orders without customers or payments. SELECT o.id, c.name, p.amount FROM orders o LEFT JOIN customers c ON c.id = o.customer_id RIGHT JOIN payments p ON p.order_id = o.id; mixes LEFT and RIGHT JOIN incorrectly. SELECT o.id, c.name, p.amount FROM orders o INNER JOIN customers c ON o.customer_id = c.id LEFT JOIN payments p ON o.id = p.order_id; uses INNER JOIN first, losing unmatched orders.

3. Final Answer:

   SELECT o.id, c.name, p.amount FROM orders o LEFT JOIN customers c ON o.customer_id = c.id LEFT JOIN payments p ON o.id = p.order_id; -> Option A

4. Quick Check:

   Multiple LEFT JOINs keep all orders [OK]

Hint: Use LEFT JOIN for all tables to keep main table rows [OK]

Common Mistakes:

• Using INNER JOIN instead of LEFT JOIN loses unmatched rows
• Mixing JOIN types without clear logic
• Incorrect ON conditions causing wrong matches

3. Given tables:
users(id, name),
posts(id, user_id, title),
comments(id, post_id, content)
What will this query return?

SELECT u.name, p.title, c.content FROM users u LEFT JOIN posts p ON u.id = p.user_id LEFT JOIN comments c ON p.id = c.post_id ORDER BY u.id, p.id, c.id;

medium

A. All posts with their users and comments; excludes users without posts

B. Only users who have posts and comments

C. All users with their posts and comments; NULLs if no posts or comments

D. Only comments with matching posts and users

Solution

1. Step 1: Analyze first LEFT JOIN

   The first LEFT JOIN keeps all users, adding posts if they exist; users without posts get NULLs for post columns.

2. Step 2: Analyze second LEFT JOIN

   The second LEFT JOIN adds comments for each post; if no comments, comment columns are NULL. Users without posts have NULL posts, so comments also NULL.

3. Final Answer:

   All users with their posts and comments; NULLs if no posts or comments -> Option C

4. Quick Check:

   LEFT JOINs keep all users, add posts and comments if present [OK]

Hint: LEFT JOIN keeps all left table rows, fills NULLs if no matches [OK]

Common Mistakes:

• Assuming INNER JOIN behavior filters rows
• Thinking NULLs mean errors instead of missing data
• Ignoring order of JOINs affecting results

4. Identify the error in this SQL query using multiple LEFT JOINs:

SELECT a.id, b.name, c.status FROM tableA a LEFT JOIN tableB b ON a.id = b.a_id LEFT JOIN tableC c ON b.id = c.b_id WHERE c.status = 'active';

medium

A. The SELECT clause must include all columns from joined tables

B. The JOIN conditions are missing ON clauses

C. Using LEFT JOIN twice is not allowed

D. The WHERE clause filters out rows where c.status is NULL, negating LEFT JOIN effect

Solution

1. Step 1: Understand WHERE with LEFT JOIN

   The WHERE clause filters rows after JOINs. Filtering on c.status excludes rows where c is NULL, removing unmatched rows.

2. Step 2: Effect on LEFT JOIN

   This makes the LEFT JOIN behave like INNER JOIN, losing rows from tableA without matching tableC rows.

3. Final Answer:

   The WHERE clause filters out rows where c.status is NULL, negating LEFT JOIN effect -> Option D

4. Quick Check:

   Filtering on joined table in WHERE breaks LEFT JOIN [OK]

Hint: Use WHERE on main table only; filter joined tables in ON [OK]

Common Mistakes:

• Filtering joined table columns in WHERE instead of ON
• Assuming multiple LEFT JOINs are invalid
• Missing ON conditions causing cross joins

5. You have tables:
employees(id, name, department_id),
departments(id, dept_name),
projects(id, dept_id, project_name),
tasks(id, project_id, task_name).
Write a query to list all employees with their department, projects, and tasks. Include employees even if they have no department, projects, or tasks. Which query achieves this?

hard

A. SELECT e.name, d.dept_name, p.project_name, t.task_name FROM employees e LEFT JOIN departments d ON e.department_id = d.id LEFT JOIN projects p ON d.id = p.dept_id LEFT JOIN tasks t ON p.id = t.project_id;

B. SELECT e.name, d.dept_name, p.project_name, t.task_name FROM employees e LEFT JOIN departments d ON e.id = d.id LEFT JOIN projects p ON d.id = p.dept_id LEFT JOIN tasks t ON p.id = t.project_id;

C. SELECT e.name, d.dept_name, p.project_name, t.task_name FROM employees e INNER JOIN departments d ON e.id = d.id INNER JOIN projects p ON d.id = p.dept_id INNER JOIN tasks t ON p.id = t.project_id;

D. SELECT e.name, d.dept_name, p.project_name, t.task_name FROM employees e LEFT JOIN departments d ON e.id = d.id LEFT JOIN projects p ON e.id = p.dept_id LEFT JOIN tasks t ON p.id = t.project_id;

Solution

1. Step 1: Identify correct JOIN keys

   Employees link to departments by e.department_id = d.id, not e.id = d.id. Projects link to departments by dept_id, tasks to projects by project_id.

2. Step 2: Use LEFT JOINs to keep all employees

   LEFT JOINs keep all employees even if no department, projects, or tasks exist.

3. Step 3: Check each option

   SELECT e.name, d.dept_name, p.project_name, t.task_name FROM employees e LEFT JOIN departments d ON e.department_id = d.id LEFT JOIN projects p ON d.id = p.dept_id LEFT JOIN tasks t ON p.id = t.project_id; uses correct keys and LEFT JOINs. Other queries use wrong keys (joining on e.id = d.id or e.id = p.dept_id) or INNER JOINs, excluding employees without matches.

4. Final Answer:

   SELECT e.name, d.dept_name, p.project_name, t.task_name FROM employees e LEFT JOIN departments d ON e.department_id = d.id LEFT JOIN projects p ON d.id = p.dept_id LEFT JOIN tasks t ON p.id = t.project_id; -> Option A

5. Quick Check:

   Correct keys + LEFT JOINs keep all employees [OK]

Hint: Match keys correctly and use LEFT JOINs to keep all main rows [OK]

Common Mistakes:

• Joining on wrong columns causing missing data
• Using INNER JOINs losing employees without projects
• Confusing employee ID with department ID