What exactly does "No Join Predicate" mean in SQL Server?

Question

MSDN "Missing Join Predicate Event Class" says it "indicates that a query is being executed that has no join predicate".

But unfortunately it does not seem to be as easy as that.

For example, very simple situation:

create table #temp1(i int);
create table #temp2(i int);
Select * from #temp1, #temp2 option (recompile);

There is no data in the tables, there is no warning either, although it obviously has no join predicate.

If I take a look at documentation for SQL Server 2005 (the same link, just other server version), there is an extra sentence: "This event is produced only if both sides of the join return more than one row." This would make perfect sense in the previous situation. There is no data, so both sides returns 0 rows and no warning. Insert rows, get warning. Ok, cool.

But for the next confusing situation, I insert the same values in both tables:

Insert into #temp1 (i) values (1)
Insert into #temp1 (i) values (1)
Insert into #temp2 (i) values (1)
Insert into #temp2 (i) values (1)

And I get:

-- no warning:
Select * from #temp1 t1 
    inner join #temp2 t2 on t1.i = t2.i 
option (recompile)
-- has warning:
Select * from #temp1 t1 
    inner join (select 1 i union all select 1) t2 on t1.i = t2.i 
option (recompile)

Why is this so?

Note: some scripts I used to detect these bad queries on my server.

1. of course, execution plan of procedures

2. used default server trace to find warnings

   Declare @trace nvarchar(500);
   Select @trace = cast(value as nvarchar(500))
   From sys.fn_trace_getinfo(Null)
   Where traceid = 1 and property = 2;
   
   Select t.StartTime, te.name, *
   From sys.fn_trace_gettable(@trace, 1) t
       Inner join sys.trace_events te on t.EventClass = te.trace_event_id
       where EventClass = 80
   order by t.StartTime desc
   

3. execution plan cache, to find those plans with warnings (like this one)

   WITH XMLNAMESPACES (default 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
   SELECT
       Cast('<?SQL ' + st.text + ' ?>' as xml) sql_text,
       pl.query_plan,
       ps.execution_count,
       ps.last_execution_time,
       ps.last_elapsed_time,
       ps.last_logical_reads,
       ps.last_logical_writes
   FROM sys.dm_exec_query_stats ps with (NOLOCK)
       Cross Apply sys.dm_exec_sql_text(ps.sql_handle) st
       Cross Apply sys.dm_exec_query_plan(ps.plan_handle) pl
   WHERE pl.query_plan.value('(//Warnings/@NoJoinPredicate)[1]', 'bit') = 1
   Order By last_execution_time desc
   OPTION (RECOMPILE);
   

Answer 1

Your question is similar to this one. Sometimes SQL Server can remove a join predicate from the original query.

In the case where you see a join predicate warning SQL Server detects at compile time that the table of constants only has one distinct value and that value is 1 so rewrites the query as

SELECT *
FROM   (SELECT *
        FROM   #temp1 t1
        WHERE  t1.i = 1) t1
       CROSS JOIN (SELECT 1 i
                   UNION ALL
                   SELECT 1) t2 

There is a predicate on the table scan of #temp as follows [tempdb].[dbo].[#temp1].[i] =(1)

The join predicate of on t1.i = t2.i can't be removed in this way at compile time when using two tables or if the table of constants contains more than one distinct value.

---

More info about this can be found in Paul White's Query Optimizer Deep Dive series.