Yes you can, and you can get the optimizer to recognize it too.
Paul White has this little ditty:
WHERE NOT EXISTS (
SELECT d.[Data]
INTERSECT
SELECT i.[Data])
This works because of the semantics of INTERSECT
which deal with nulls. What this says is "are there no rows in the subquery made up of value B and value B", this will only be satisfied if they are different values or one is null and the other not. If both are nulls, there will be a row with a null.
If you check the XML query plan (not the graphical one in SSMS), you will see that it compiles all the way down to d.[Data] <> i.[Data]
, but the operator it uses will have CompareOp="IS"
and not EQ
.
See the full plan here.
The relevant part of the plan is:
<Predicate>
<ScalarOperator ScalarString="@t1.[i] as [t1].[i] = @t2.[i] as [t2].[i]">
<Compare CompareOp="IS">
<ScalarOperator>
<Identifier>
<ColumnReference Table="@t1" Alias="[t1]" Column="i" />
</Identifier>
</ScalarOperator>
<ScalarOperator>
<Identifier>
<ColumnReference Table="@t2" Alias="[t2]" Column="i" />
</Identifier>
</ScalarOperator>
</Compare>
</ScalarOperator>
</Predicate>
I find the optimizer works very well this way round, rather than doing EXISTS / EXCEPT
.
I urge you to vote for the Azure Feedback to implement a proper operator
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…