By juan


2008-09-23 15:13:28 8 Comments

Is there a difference in performance (in oracle) between

Select * from Table1 T1 
Inner Join Table2 T2 On T1.ID = T2.ID

And

Select * from Table1 T1, Table2 T2 
Where T1.ID = T2.ID

?

18 comments

@ROQUEFORT François 2017-08-08 12:45:33

As kiewik said, the execution plan is the same.

The JOIN statement is only more easy to read, making it easier not to forget the ON condition and getting a cartesian product. These errors can be quite hard to detect in long queries using multiple joins of type : SELECT * FROM t1, t2 WHERE t1.id=t2.some_field.

If you forget only one join condition, you get a very long to execute query returning too many records... really too many. Some poeple use a DISTINCT to patch the query, but it's still very long to execute.

That's accurately why, using JOIN statement is surely the best practice : a better maintainability, and a better readability.

Further more, if I well remember, JOIN is optimized concerning memory usage.

@rxpande 2017-03-03 05:56:49

They're both joins and where that do the same thing.

Give a look at In MySQL queries, why use join instead of where?

@jackattack 2016-07-01 02:12:28

In a scenario where tables are in 3rd normal form, joins between tables shouldn't change. I.e. join CUSTOMERS and PAYMENTS should always remain the same.

However we must distinguish joins from filters. Joins are about relationships and filters are about partitioning a whole.

SQL-92 syntax encourages us to separate both concepts and it's preferred over old syntax that put both, joins and filters, on WHERE clause which is more cumbersome.

@trbullet81 2014-10-28 14:15:47

i had this conundrum today when inspecting one of our sp's timing out in production, changed an inner join on a table built from an xml feed to a 'where' clause instead....average exec time is now 80ms over 1000 executions, whereas before average exec was 2.2 seconds...major difference in the execution plan is the dissapearance of a key lookup... The message being you wont know until youve tested using both methods.

cheers.

@greatvovan 2014-06-27 08:59:07

Although the identity of two queries seems obvious sometimes some strange things happens. I have come accros the query wich has different execution plans when moving join predicate from JOIN to WHERE in Oracle 10g (for WHERE plan is better), but I can't reproduce this issue in simplified tables and data. I think it depends on my data and statistics. Optimizer is quite complex module and sometimes it behaves magically.

Thats why we can't answer to this question in general because it depends on DB internals. But we should know that answer has to be 'no differences'.

@David Aldridge 2008-09-23 15:40:24

They're logically identical, but in the earlier versions of Oracle that adopted ANSI syntax there were often bugs with it in more complex cases, so you'll sometimes encounter resistance from Oracle developers when using it.

@ScottCher 2008-10-27 18:53:47

Earlier versions of Oracle had bugs with this? How early? What version(s)?

@David Aldridge 2008-10-28 18:32:22

Metalink has details ... they pop-up all over the place.

@user21241 2008-09-23 17:18:56

Using JOIN makes the code easier to read, since it's self-explanatory.

There's no difference in speed(I have just tested it) and the execution plan is the same.

@Farhad ArcxX 2016-12-06 18:21:43

Thank you. i was looking for speed compression between this two methods.

@Chris Gill 2009-08-27 12:01:36

[For a bonus point...]

Using the JOIN syntax allows you to more easily comment out the join as its all included on one line. This can be useful if you are debugging a complex query

As everyone else says, they are functionally the same, however the JOIN is more clear of a statement of intent. It therefore may help the query optimiser either in current oracle versions in certain cases (I have no idea if it does), it may help the query optimiser in future versions of Oracle (no-one has any idea), or it may help if you change database supplier.

@Matthew McPeak 2015-08-27 12:44:25

Or... easily change the INNER JOINS to LEFT JOINS, so you get see which join is causing you to miss expected rows. I do this because I do the whole query at once. If you comment out INNER JOINS, you sort of have to do a process of elimination. It takes longer. But +1 for you because this is one of my favorite reasons for INNER JOINS aside from readability!

@cheduardo 2009-06-03 21:55:51

Don’t forget that in Oracle, provided the join key attributes are named the same in both tables, you can also write this as:

select *
from Table1 inner join Table2 using (ID);

This also has the same query plan, of course.

@juan 2009-06-03 23:37:22

I rollbacked the edition because the previous revision changed the meaning of the answer

@kiewic 2008-12-10 01:25:58

No! The same execution plan, look at these two tables:

CREATE TABLE table1 (
  id INT,
  name VARCHAR(20)
);

CREATE TABLE table2 (
  id INT,
  name VARCHAR(20)
);

The execution plan for the query using the inner join:

-- with inner join

EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

And the execution plan for the query using a WHERE clause.

-- with where clause

EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;

SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);

-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2

@4 Leave Cover 2016-09-06 11:31:51

I really do wish to see if there are any official documentation from Oracle saying about this

@stili 2008-12-04 20:04:48

The performance should be identical, but I would suggest using the join-version due to improved clarity when it comes to outer joins.

Also unintentional cartesian products can be avoided using the join-version.

A third effect is an easier to read SQL with a simpler WHERE-condition.

@Steve Kallestad 2014-01-15 06:28:58

I really think the key is unintentional effects where the criteria is ambiguous. If you specify the type of join you know exactly what you are getting. I have found that different databases and even different versions of the same database platform will handle null values differently in an implied join. When you specify left/right inner/outer you spend the time to think about which is correct. When you use the ambiguous method, you assume that it works the way you hope/intend it to.

@JoshL 2008-09-27 02:10:58

It is true that, functionally, both queries should be processed the same way. However, experience has shown that if you are selecting from views that use the new join syntax, it is important to structure your queries using it as well. Oracle's optimizer can get confused if a view uses a "join" statement, but a query accessing the view uses the traditional method of joining in the "where" clause.

@unexist 2008-09-29 15:04:19

That's more a problem with views than with joins at all.

@HLGEM 2008-09-23 17:16:48

I don't know about Oracle but I know that the old syntax is being deprecated in SQL Server and will disappear eventually. Before I used that old syntax in a new query I would check what Oracle plans to do with it.

I prefer the newer syntax rather than the mixing of the join criteria with other needed where conditions. In the newer syntax it is much clearer what creates the join and what other conditions are being applied. Not really a big problem in a short query like this, but it gets much more confusing when you have a more complex query. Since people learn on the basic queries, I would tend to prefer people learn to use the join syntax before they need it in a complex query.

And again I don't know Oracle specifically, but I know the SQL Server version of the old style left join is flawed even in SQL Server 2000 and gives inconsistent results (sometimes a left join sometimes a cross join), so it should never be used. Hopefully Oracle doesn't suffer the same issue, but certainly left and right joins can be mcuh harder to properly express in the old syntax.

Plus it has been my experience (and of course this is strictly a personal opinion, you may have differnt experience) that developers who use the ANSII standard joins tend to have a better understanding of what a join is and what it means in terms of getting data out of the database. I belive that is becasue most of the people with good database understanding tend to write more complex queries and those seem to me to be far easier to maintain using the ANSII Standard than the old style.

@ScottCher 2008-10-27 18:55:07

Amen brother. Down with the JOINERS!!

@MattC 2008-09-23 15:29:07

Functionally they are the same as has been said. I agree though that doing the join is better for describing exactly what you want to do. Plenty of times I've thought I knew how I wanted to query something until I started doing the joins and realized I wanted to do a different query than the original one in my head.

@Bob Gettys 2008-09-23 15:26:05

They're both inner joins that do the same thing, one simply uses the newer ANSI syntax.

@Nescio 2008-09-23 15:23:41

They should be exactly the same. However, as a coding practice, I would rather see the Join. It clearly articulates your intent,

@Paul Morie 2009-05-19 16:34:13

I agree. Especially if you're joining to multiple tables, it's a lot easier to parse a select statement if you're doing explicit joins.

@Stimul8d 2011-07-19 09:03:10

Indeed. Joins represent a semantic relationship between two sets of data but a where suggests a filtered set. +1

@Nick Johnson 2008-09-23 15:22:59

In PostgreSQL, there's definitely no difference - they both equate to the same query plan. I'm 99% sure that's also the case for Oracle.

@Craig Trader 2008-09-23 15:15:36

If the query optimizer is doing its job right, there should be no difference between those queries. They are just two ways to specify the same desired result.

@Joel Coehoorn 2008-09-23 15:31:47

Yeah, performance should be the same. But the SELECT * FROM Table1, Table2 WHERE ... syntax is EVIL!

@Craig Trader 2008-09-23 17:39:50

I find it much easier to comprehend FOR INNER JOINS than the SQL-92 syntax. Your mileage may vary.

@ScottCher 2008-10-27 18:53:01

I find the WHERE syntax easier to read than INNER JION - I guess its like Vegemite. Most people in the world probably find it disgusting but kids brought up eating it love it.

@StingyJack 2009-08-27 12:05:05

Vegemite is nasty indeed, but then again I love scrapple. Go figure.

@Thomas Ahle 2014-09-15 10:38:04

I learned JOINs first, but after I discovered multi-froms, I find them much easier to remember, read and use. What does that make me?

@Darryl 2016-04-06 21:15:57

Just curious why people prefer the JOIN syntax. Easier to read? More explicit distinction between joining and filtering? Personally I find JOINs harder to read, not easier.

Related Questions

Sponsored Content

28 Answered Questions

[SOLVED] What is the difference between "INNER JOIN" and "OUTER JOIN"?

10 Answered Questions

[SOLVED] Improve INSERT-per-second performance of SQLite?

3 Answered Questions

13 Answered Questions

[SOLVED] When should I use cross apply over inner join?

17 Answered Questions

[SOLVED] Python string formatting: % vs. .format

20 Answered Questions

[SOLVED] What is the difference between call and apply?

8 Answered Questions

[SOLVED] Difference between JOIN and INNER JOIN

8 Answered Questions

[SOLVED] Skip certain tables with mysqldump

10 Answered Questions

[SOLVED] Difference between left join and right join in SQL Server

10 Answered Questions

[SOLVED] INNER JOIN ON vs WHERE clause

Sponsored Content