How to Write INNER JOIN Which is Actually CROSS JOIN? – Interview Question of the Week #250

Question: Can an INNER JOIN produce a Cartesian product? Yes. An always-true join condition such as ON 1 = 1 pairs every row from the first input with every row from the second.

Two kinds of cups paired with three kinds of saucers form every combination

During a health check I found client queries written as INNER JOINs whose conditions didn’t relate the two tables. The keyword looked reassuring; the row multiplication was the clue. Here is the original idea with tiny table variables so you can run it without creating permanent tables.

DECLARE @Table1 table (ID int NOT NULL);
DECLARE @Table2 table (Code char(1) NOT NULL);
INSERT @Table1 VALUES (1), (2);
INSERT @Table2 VALUES ('A'), ('B'), ('C');

SELECT t1.ID, t2.Code
FROM @Table1 AS t1 INNER JOIN @Table2 AS t2 ON 1 = 1
ORDER BY t1.ID, t2.Code;

SELECT t1.ID, t2.Code
FROM @Table1 AS t1 CROSS JOIN @Table2 AS t2
ORDER BY t1.ID, t2.Code;

-- The original comma syntax, also a Cartesian product:
SELECT t1.*
FROM @Table1 AS t1, @Table2 AS t2
ORDER BY t1.ID;
Native SSMS result: two IDs and three codes produce six ordered pairs.
Native SSMS result: two IDs and three codes produce six ordered pairs.

The first two queries both return six pairs: (1,A), (1,B), (1,C), (2,A), (2,B), (2,C). Two rows times three rows equals six. CROSS JOIN states that intention plainly; INNER JOIN ON 1 = 1 expresses the same pairing through a true predicate.

The last query preserves the original comma syntax and its t1.* projection. It still generates six joined rows, but hides the second input’s columns. Each ID appears three times. Selecting only one table’s columns does not undo the Cartesian product.

A WHERE clause can filter any of these joined results, so “always a Cartesian product” applies to the unfiltered examples here. If the requirement is to match related keys, write that relationship explicitly in ON instead of relying on a predicate that is true for every pair.

Comma-separated table syntax itself isn’t proof of non-standard SQL; the original description was too broad. I prefer explicit JOIN syntax because a missing relationship is easier to see and review.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.


Discover more from SQL Authority with Pinal Dave

Subscribe to get the latest posts sent to your email.

SQL Joins, SQL Scripts, SQL Server
Previous Post
How to Use GOTO command in SQL Server? – Interview Question of the Week #249
Next Post
How to Determine Read Intensive and Write Intensive Tables in SQL Server? – Interview Question of the Week #251

Related Posts

3 Comments. Leave new

  • What is the difference between INNER JOIN and JOIN?

    They are functionally identical. I would say just writing JOIN is somewhat lazy coding pattern, but I admit that it might also be a style preference. I would opt to be explicit as much as possible and typing 5 more keystrokes is worth it IMO.

    Reply
  • Hi Pinal,

    Has this question out of curiosity. In both the cases, doesn’t the Execution Plan show you the warning on Join operator indicating that there is no join predicate. Do you think that might be a first hint as a best practice to recheck the query written or are there any scenarios where warning doesn’t appear.

    Regards,

    Sravan Pappu

    Reply
  • I agree both are same and writing just JOIN is a lazy coding style.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.