Joining Tables Using WHERE Instead of JOIN
Yes, you can perform a JOIN in MySQL without using the JOIN keyword. This older syntax uses multiple tables in the FROM clause and specifies the join condition in the WHERE clause. It works, but it behaves differently for INNER and OUTER joins.
• Before ANSI JOIN syntax became standard, INNER JOINs were commonly written using WHERE.
• This behaves exactly like an INNER JOIN.
Example:
SELECT *
FROM users u, orders o
WHERE u.id = o.user_id;
• Returns only rows where both tables have matching values.
• LEFT JOIN or RIGHT JOIN cannot be expressed correctly with WHERE conditions.
• The WHERE clause filters out NULLs, turning the join into an INNER JOIN.
• Therefore, outer joins must use explicit JOIN ... ON syntax.
• JOIN ... ON keeps join logic separate from filtering logic.
• Clearer and more readable.
• Prevents accidental conversion of OUTER JOIN → INNER JOIN.
• ANSI-standard and recommended for modern SQL.
In summary: JOINs can be written using WHERE, but this is safe only for INNER JOINs. For LEFT/RIGHT OUTER JOINs, the explicit JOIN keyword must be used.
You have tables users and orders. Write a query that returns each user's name and the number of orders they placed, but you must not use the JOIN keyword. How would you do it?
If you write SELECT * FROM users, orders WHERE users.id = orders.user_id, what result do you expect compared to using INNER JOIN?
What happens if you forget the join condition in the WHERE clause when using this comma‑separated style?
Our reporting feature uses three tables joined via commas and WHERE conditions. After a recent schema change the query started returning duplicate rows. Walk me through how you'd debug it.
Explain the trade‑offs of keeping implicit joins in a codebase that many developers maintain versus switching to explicit JOIN syntax.
A teammate replaced an explicit LEFT JOIN with a WHERE‑based join and now the query returns fewer rows. Why might that happen?
We process billions of rows daily and some legacy queries use implicit joins. How would you assess the performance impact and decide whether to rewrite them to explicit JOINs?
Design a migration plan to refactor all implicit joins in a large monolithic service to explicit JOINs while minimizing downtime and regression risk.
What edge cases (e.g., outer joins, self‑joins) become problematic with WHERE‑based joins, and how would you ensure correctness at scale?
At the organization level we're standardizing SQL style guidelines. How would you argue for or against mandating explicit JOIN syntax across all teams, considering tooling, onboarding, and optimizer behavior?
If we must continue supporting a legacy application that only generates implicit join queries, what architectural decisions would you make to abstract the SQL generation while allowing a future migration to modern syntax?