What's the resolving order of operators in where-conditions in MySQL (example: SELF join)

Question

I was looking into some SQL-tutorials and found an example that makes me scratch my head. I don't wanna copy all of the SELF join example, given there, so I will post the link to the relevant page here.
In that example a SELF join is made on a "customer" table that contains the salary. The WHERE-condition is a.SALARY < b.SALARY. I assumed that the "lesser than"-operator would be left-associative. Meaning, I expected that the engine would take each row of table a and join it with the respective rows of table b, that match the WHERE-condition.
So I would get the following result:

+----+----------+---------+
| ID | NAME     | SALARY  |
+----+----------+---------+
|  1 | Chaitali | 2000.00 |
|  1 | Hardik   | 2000.00 |
|  1 | Komal    | 2000.00 |
|  1 | Muffy    | 2000.00 |
|  2 | Ramesh   | 1500.00 |
|  2 | kaushik  | 1500.00 |
|  2 | Chaitali | 1500.00 |
|  2 | Hardik   | 1500.00 |
|  2 | Komal    | 1500.00 |
|  2 | Muffy    | 1500.00 |
|  3 | Chaitali | 2000.00 |
|  3 | Hardik   | 2000.00 |
|  3 | Komal    | 2000.00 |
|  3 | Muffy    | 2000.00 |
|  4 | Hardik   | 6500.00 |
|  4 | Muffy    | 6500.00 |
|  5 | Muffy    | 8500.00 |
|  6 | Chaitali | 4500.00 |
|  6 | Hardik   | 4500.00 |
|  6 | Muffy    | 4500.00 |
+----+----------+---------+

My problem is that the author says the MySQL-output (see: "the authors statement about using MySQL for testing example-code") would be the following:

+----+----------+---------+
| ID | NAME     | SALARY  |
+----+----------+---------+
|  2 | Ramesh   | 1500.00 |
|  2 | kaushik  | 1500.00 |
|  1 | Chaitali | 2000.00 |
|  2 | Chaitali | 1500.00 |
|  3 | Chaitali | 2000.00 |
|  6 | Chaitali | 4500.00 |
|  1 | Hardik   | 2000.00 |
|  2 | Hardik   | 1500.00 |
|  3 | Hardik   | 2000.00 |
|  4 | Hardik   | 6500.00 |
|  6 | Hardik   | 4500.00 |
|  1 | Komal    | 2000.00 |
|  2 | Komal    | 1500.00 |
|  3 | Komal    | 2000.00 |
|  1 | Muffy    | 2000.00 |
|  2 | Muffy    | 1500.00 |
|  3 | Muffy    | 2000.00 |
|  4 | Muffy    | 6500.00 |
|  5 | Muffy    | 8500.00 |
|  6 | Muffy    | 4500.00 |
+----+----------+---------+

which indicates that the engine takes rows from table b first and compares them to table a.
I don't know now if this is the authors fault, because he forgot to mention any ORDER BY or GROUP BY arguments. (In that case that tutorial just s*cks.)

But if the output he stated is actually correct on MySQL-Server, I would like to know from people who know much more about SQL than me,
a) why this operator resolves from right to left and
b) what reasons there are to do so. Is it a performance issue? Or was I wrong about the "lesser than"-operator right from the bginning: that it never takes the left operand first?
c) I would like to know if this is just the result of MySQL or an issue related to SQL in general.

Unfortunately, I can't test this output by myself because I currently don't own any computer I'm allowed to install MySQL on. So your help would be much appreciated : )
I hope this question doesn't sound too stupid but I couldn't find helpful sources on the internet that specifically explain this behaviour. When I studied I had two modules about RDBMS and in all the examples operators were always resolved the way I did it in the first output-example above. That's why I'm currently confused about this ^^

Thanks in advance for wasting your time for me :D best regards.

possible duplicate of [Why do results from a SQL query not come back in the order I expect?](http://stackoverflow.com/questions/10999913/why-do-results-from-a-sql-query-not-come-back-in-the-order-i-expect) — Rocketq, Apr 21 '15 at 09:47
SQL tables and (generally) result sets represent *unordered* sets. The only exception is when `order by` is used in the outermost `select`. The ordering of results does not matter for *unordered* sets. — Gordon Linoff, Apr 21 '15 at 10:55

score 0 · Accepted Answer · answered Apr 21 '15 at 09:30

Usually you have a clever process that figures out in which direction a specific query should be processed to make it most efficient. And then it just depends on that process, and every single query, if one or the other is compared first.

If neither is better then the other it's just an implementation decision that varies from database to database, and I think as you write here that MySQL is right associative.

score 0 · Answer 2 · answered Apr 21 '15 at 09:34

It is a common misconception to expect results in the order that is inserted. Even when a clustered index is used, the result set may not be as expected. Only way to force an order is to use an order by clause. The query may be executed in parallel and the result set may be merged or it may be due to the query optimization plan while trying to return the result set as fast as possible. This is why such problem may appear.

What's the resolving order of operators in where-conditions in MySQL (example: SELF join)

2 Answers2