Comments on: Whether to use UNION or OR in SQL Server Queries

By: Chris

Chris — Mon, 11 Jul 2011 14:12:44 +0000

Scenario 1:

“the UNION query is not performing well as the OR query though both are retuning same no of rows (3854).These results indicate that, for the above scenario UNION should be used.”

I think you mean OR should be used in this case.

By: Bret

Bret — Mon, 11 Jul 2011 12:35:39 +0000

The analysis is too simplistic to be useful in any real world scenario. Also, the missing index warning in your query plans (the green text) means the whole exercise was executed on a non-optimal design. Perhaps the speed differences between UNION and OR were entirely due to the missing index.

By: Øyvind

Øyvind — Sun, 10 Jul 2011 07:54:44 +0000

in this example, there would be no difference at all between UNION and UNION ALL, but the latter option would perform better. Choosing normal union (‘set union’) in this case, is wrong.

By: Christine

Christine — Fri, 08 Jul 2011 17:57:26 +0000

thanks. Just curious how you got the Reads and Duration numbers?

By: AGod

AGod — Fri, 08 Jul 2011 15:00:59 +0000

How did you generate the tables that compare CPU, Reads, Duration and Row Count? An article explaining how to would be extremely useful.

By: Hermes

Hermes — Thu, 07 Jul 2011 11:37:06 +0000

Hi all,
please consider that if you have many values for the same condition, you have to dinamically create a select string concatenating many UNION. this statement cannot be used with, i.e., sp_executesql or stored procedure because the command is every time generated at “runtime” (not compiled?).
sometimes performance are less important than clarity and readness specially when you need to solve problems in production. (consider the effort to analyze many selct in union vs a more simple and clear IN )

By: AG

AG — Thu, 07 Jul 2011 03:46:16 +0000

Regarding Scenario 1, you state that UNION should be used? Why is this, when it has higher CPU and Reads.

Also the screenshots for the plans in Scenario 3 & 4 look like they need to be swapped around? nonclustered vs clustered index use

By: Shash

Shash — Wed, 06 Jul 2011 20:25:47 +0000

IN is a fancier way for OR. Although it reduces the amount of code you have to write, it stills works as OR internally. With that being said, you will see no or very little difference in performance while using (IN or OR).

By: piersy

piersy — Wed, 06 Jul 2011 14:23:13 +0000

Eek. UNION is most certainly not a like for like replacement for an OR operator.

UNION (minus the ALL) is the equivalent of a SELECT DISTINCT, so could end up with unexpected results, depending on what you are doing.

If ever I see a DISTINCT in a query, alarm bells automatically start ringing.
Not because it doesn’t have its uses, but that in the vast majority of cases when people use it to eliminate duplicates they’ve done so because they didn’t fully understand what they were trying to achieve or have some misunderstanding about the data model.

So assuming this is about the UNION ALL vs OR, short of any huge gain in performance I’d say the OR is both aesthetically more pleasing (less code) and more obvious as to what the semantics of the query are about.

As others have said an IN clause will usually be optimised out identically to a simple OR clause and is even neater.

On a slight aside, in a partitioned view which is effectively a UNION ALL query against identical tables with different check constraints, the optimiser would automatically discount any values that weren’t in the OR clause.

By: mtassin

mtassin — Wed, 06 Jul 2011 12:56:43 +0000

I would have to disagree. The OR option doesn’t detect duplicates and eliminate them. Yet the UNION operator is doing this. UNION ALL would be the equivalent to the OR statement.

To make the first query the equivalent of a UNION, not a UNION ALL you would need to rewrite the first query to

SELECT DISTINCT ProductID,SalesOrderID, SalesOrderDetailID FROM Sales.SalesOrderDetail
WHERE ProductID = 714 OR ProductID =709
OR ProductID =998 OR ProductID =875
OR ProductID =976 OR ProductID =874

Your comment is awaiting moderation.