DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Cloud Database Services Compared: AWS, Microsoft, Google, and Oracle
  • What Developers Need to Know About Table Partition Pruning
  • Rebuild System Databases in SQL Server
  • 10 Database Optimization Best Practices for Web Developers

Trending

  • PII Detection Before RAG Ingestion: Screening Documents in C#
  • Evaluating RAG in Production — What the Numbers Actually Revealed
  • Part 1: Building Governed MCP Tool Services With Quarkus LangChain4j and Goose
  • RAG Architecture Patterns: Proxy, Caching, and Routing

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Data Engineering
  3. Databases
  4. Performance Tip for Tuning SQL with UNION

Performance Tip for Tuning SQL with UNION

UNION statements can sometimes introduce performance penalties into your query. This post has a look at how to tune your query up!

By 
Michal Davidek
·
Jul. 27, 16 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
79.0K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

This post will be short. It's about a lesson learned by tuning the SQL used for loading items from unrelated tables using the same WHERE clause. It was performed on Oracle 11g, but I am pretty confident that it applies to most SQL databases.

Keynote

Using the "WHERE" clause after the whole "UNION" is performed is significantly slower than using the "WHERE" clause inside inner selects.

This, if you can ensure removal of duplicates by the inner WHERE clauses...

(SELECT * FROM TABLE_1 WHERE COL > 1) a
UNION ALL
(SELECT * FROM TABLE_2 WHERE COL > 1) b;

... is better than following ...

(SELECT * FROM TABLE_1 WHERE COL > 1) a
UNION
(SELECT * FROM TABLE_2 WHERE COL > 1) b;

... which is better than following ...

SELECT * FROM (
(SELECT * FROM TABLE_1) a
UNION
(SELECT * FROM TABLE_2) b)
WHERE COL > 1;

Explanations

  • UNION ALL is faster than UNION because plain UNION is expecting that within two joined datasets are duplicates which need to be removed. If you can ensure (by inner WHERE clauses) that there will be no duplicates, it's far better to use UNION ALL and let database engine optimize the inner selects.
  • Using a WHERE clause on the result of grouped results is too expensive because you are operating on more internal results than you need. Also, the database engine's optimization can’t be processed — the results don't have anything in common.
  • See this.
  • And this.

P.S. If you enjoyed this post, you can share this post anywhere as well as follow me on Twitter to stay in touch.

sql Database engine

Published at DZone with permission of Michal Davidek. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Cloud Database Services Compared: AWS, Microsoft, Google, and Oracle
  • What Developers Need to Know About Table Partition Pruning
  • Rebuild System Databases in SQL Server
  • 10 Database Optimization Best Practices for Web Developers

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook