I love learning and sharing interesting things as I continue to forge SQL database developer skills.
Both the ON and USING clauses are similar when ployed with JOIN‘s.
But I think they are far from identical.
Note: All data, names or naming found within the database presented in this post, are strictly used for practice, learning, instruction, and testing purposes. It by no means depicts actual data belonging to or being used by any party or organization.
OS and Database:
- Xubuntu Linux 16.04.3 LTS (Xenial Xerus)
- MySQL 5.7.22
Photo by Jacek Dylag on Unsplash
Let’s quickly review two tables’ structure we are targeting:
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| pipe_id | smallint(6) | NO | PRI | NULL | auto_increment |
| pipe_name | varchar(25) | NO | UNI | NULL | |
| joint_num | varchar(25) | NO | | NULL | |
| heat | varchar(25) | NO | | NULL | |
| pipe_length | decimal(4,2) | YES | | NULL | |
| has_degree | tinyint(1) | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)
+---------------+-----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-----------------------+------+-----+---------+-------+
| pipe_id | smallint(6) | YES | MUL | NULL | |
| degree_amount | decimal(4,2) unsigned | YES | | NULL | |
+---------------+-----------------------+------+-----+---------+-------+
2 rows in set (0.01 sec)
In a previous blog post covering LEFT JOIN's I used these same tables for determining matched and non-matched rows.
While studying and practicing the LEFT JOIN queries, for that linked blog post, I learned some interesting behavior between the ON and USING clauses.
All stemming from the columns in the SELECT clause that are also named in either ON or USING.
Have a look at the next several queries for comprehension (Or confusion if you’re me LOL!) and I’ll do my best to communicate this behavior.
-> FROM pipe AS p
-> LEFT JOIN degree_value AS dv
-> USING(pipe_id);
+---------+-------------+---------+
| pipe_id | pipe_name | pipe_id |
+---------+-------------+---------+
| 191 | Joint-1224C | 191 |
| 193 | Joint-122B | 193 |
| 188 | Joint-171C | 188 |
| 192 | Joint-2138 | 192 |
| 184 | Joint-2528 | 184 |
| 181 | Joint-278 | 181 |
| 190 | Joint-4841R | 190 |
| 189 | Joint-68444 | 189 |
| 187 | Joint-78344 | 187 |
| 182 | Joint-8819 | 182 |
| 185 | Joint-889 | 185 |
| 186 | Joint-98434 | 186 |
| 183 | Joint-9844 | 183 |
+---------+-------------+---------+
13 rows in set (0.00 sec)
This result set returned matching rows for both tables, despite the LEFT JOIN operation.
Which are incorrect results!!
If you were only interested in capturing the pipe_id column value, this result set will bite ya!!
Ouch!!
Be careful with ON and USING.
Let’s look at the exact same query, but this time with the ON clause instead of USING:
-> FROM pipe AS p
-> LEFT JOIN degree_value AS dv
-> ON pipe_id = pipe_id;
ERROR 1052 (23000): Column 'pipe_id' in field list is ambiguous
That error is pretty self-explanatory. (I discuss ambiguity in this blog post with INNER JOIN examples so visit that post if you would like).
So what if we use the qualified name for the joining columns in the ONclause?
Let’s try it:
-> FROM pipe AS p
-> LEFT JOIN degree_value AS dv
-> ON p.pipe_id = dv.pipe_id;
ERROR 1052 (23000): Column 'pipe_id' in field list is ambiguous
Nope.
Same error.
It all stems from the field list of the SELECT statement.
Let’s try this:
-> FROM pipe AS p
-> LEFT JOIN degree_value AS dv
-> USING(pipe_id);
+---------+-------------+---------+
| pipe_id | pipe_name | pipe_id |
+---------+-------------+---------+
| 191 | Joint-1224C | 191 |
| 193 | Joint-122B | 193 |
| 188 | Joint-171C | 188 |
| 192 | Joint-2138 | 192 |
| 184 | Joint-2528 | 184 |
| 181 | Joint-278 | 181 |
| 190 | Joint-4841R | NULL |
| 189 | Joint-68444 | NULL |
| 187 | Joint-78344 | 187 |
| 182 | Joint-8819 | NULL |
| 185 | Joint-889 | NULL |
| 186 | Joint-98434 | NULL |
| 183 | Joint-9844 | NULL |
+---------+-------------+---------+
13 rows in set (0.00 sec)
There are the correct results.
Seems like qualifying the exact columns in the SELECT list, cleared up any confusion.
One more test here:
-> FROM pipe AS p
-> LEFT JOIN degree_value AS dv
-> ON pipe_id = pipe_id;
ERROR 1052 (23000): Column 'pipe_id' in on clause is ambiguous
Let’s note in these two queries, USING accepted and returned the results set.
The ON clause did not due to ambiguity.
And for both queries, the columns in the SELECT list were prefixed (qualified) with their respective table ALIAS.
Again, more behavior to be aware of.
Perhaps this is of little to no concern.
Or a very small chance of presenting a real-world use case.
However, I personally found it highly interesting and educational to see this difference between these clauses when used in this context with a LEFT JOIN.
What are your thoughts?
What have you experienced or witnessed along the same pattern as those examples presented in this blog post?
Better yet, what behavior different from that presented here have you noticed?
Feel free to leave comments and feedback below.
Explore the official MySQL 5.7 Online Manual for more information.
A Call To Action!
Thank you for taking the time to read this post. I truly hope you discovered something interesting and enlightening. Please share your findings here, with someone else you know who would get the same value out of it as well.
Visit the Portfolio-Projects page to see blog post/technical writing I have completed for clients.
Have I mentioned how much I love a cup of coffee?!?!
To receive email notifications (Never spam) from this blog (“Digital Owl’s Prose”) for the latest blog posts as they are published, please subscribe (of your own volition) by clicking the ‘Click To Subscribe!’ button in the sidebar on the homepage! (Feel free at any time to review the Digital Owl’s Prose Privacy Policy Page for any questions you may have about: email updates, opt-in, opt-out, contact forms, etc…)
Be sure and visit the “Best Of” page for a collection of my best blog posts.
Josh Otwell has a passion to study and grow as a SQL Developer and blogger. Other favorite activities find him with his nose buried in a good book, article, or the Linux command line. Among those, he shares a love of tabletop RPG games, reading fantasy novels, and spending time with his wife and two daughters.
Disclaimer: The examples presented in this post are hypothetical ideas of how to achieve similar types of results. They are not the utmost best solution(s). The majority, if not all, of the examples provided are performed on a personal development/learning workstation-environment and should not be considered production quality or ready. Your particular goals and needs may vary. Use those practices that best benefit your needs and goals. Opinions are my own.