0
Way1:
Select * from tableA inner join tableB 
on tableA.aid = tableB.aid
where a.condA = xx
AND a.condB = xx
AND a.condC = xx

Way2:
Select * from tableA inner join tableB 
on tableA.aid = tableB.aid
AND a.condA = xx
AND a.condB = xx
AND a.condC = xx

Judging from above syntax, is there any significant differences in terms or performances?

SuicideSheep
  • 5,260
  • 19
  • 64
  • 117
  • 3
    Check execution plans, it is so simple. Also query optimizer can generate the same plan for both, but as always it depends. – Lukasz Szozda Sep 15 '15 at 14:34
  • 1
    And notice the result for both queries would be different if you use a `left join` instead. – juergen d Sep 15 '15 at 14:36
  • You can enable Execution Plans in the Query dropdown list. After running your query, it will show you the computational cost of every operation done, and more detailed information when you hover over an icon. – jjjjjjjjjjj Sep 15 '15 at 14:38
  • https://www.simple-talk.com/sql/performance/execution-plan-basics/ – wiretext Sep 15 '15 at 14:38
  • @juergend: a left join is something different then an inner join. (you can achieve an outer (left) join using where syntax as well, albeit different per SQL dialect. (WHERE *= ) – Frederik Gheysels Sep 15 '15 at 14:40

4 Answers4

1

Normally, the DBMS should generate the same execution plan.

I find the former one (the JOIN syntax) more obvious then the latter one since it is clearer what you're doing.

Frederik Gheysels
  • 56,135
  • 11
  • 101
  • 154
0

No. No difference.

It doesn't make any difference in case of INNER JOIN, both performance wise and result wise.

In case of OUTER JOIN, the placement of condition makes the difference.

Sateesh Pagolu
  • 9,282
  • 2
  • 30
  • 48
0

They should generate the same execution plan with the same results, the advantage of using example 1 is the readability. In small queries it's okay to use either but as queries get more complex it's nice to have something readable plus be nice to your peers if they ever read your code. It's like formatting, everyone likes neat code, easy to read.

viejoEngineer
  • 364
  • 3
  • 11
-1

In terms of the queries being equivalent, the only time it really matters is for outer joins. In those cases whether you put the criteria in the join or the where matters. One is applied before/during the outer join and the other after the join. Thus conditions in the where need to handle nulls as the outer join could result in no actual join. So the two queries for an outer join are not equivalent.

Sometimes in inner joins it will matter if the condition will cause a field to be converted into another type. If that is the case there may be a type conversion issues which prevents it from working properly. In other words if your comparing an integer column to a string column and the string column contains 'TEST', well you're going to have a bad time. Unless you exclude those rows via the join condition.

In terms of performance, you want to put the conditions in the join which will hit the index you want to use. Beyond that they should go in the where clause unless they are needed in the join.

But your example may not be the best. It looks like all checks against specific fields for specific values. If you have conditions that just check a value from one table against a constant or variable these are typically not used as join conditions.

Will Rickards
  • 2,776
  • 2
  • 19
  • 25