Что такое разрешающий порядок операторов в условиях условий в MySQL (пример: SELF join)

Question

Я изучал некоторые учебники по SQL и нашел пример, который заставляет меня почесывать голову. Я не хочу копировать все приведенные здесь примеры подключения SELF, поэтому отправлю ссылку на соответствующую страницу here.
В этом примере соединение SELF производится в таблице «клиент», содержащей зарплату. Состояние WHERE - a.SALARY < b.SALARY. Я предположил, что «меньший» -оператор будет лево-ассоциативным. Смысл, я ожидал, что двигатель будет брать каждую строку table a и присоединить его к соответствующим строкам table b, которые соответствуют состоянию WHERE.
Так что я хотел бы получить следующий результат:

+----+----------+---------+ 
| 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 | 
+----+----------+---------+ 

Моя проблема заключается в том, что автор говорит MySQL-вывода (см: "the authors statement about using MySQL for testing example-code") будет следующее:

+----+----------+---------+ 
| 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 | 
+----+----------+---------+ 

, который указывает на то, что двигатель сначала берет строки от table b и сравнивает их с table a.
Я не знаю, если это ошибка авторов, потому что он забыл упомянуть любые аргументы ORDER BY или GROUP BY. (В этом случае, учебник просто S * CKS.)

Но если выход заявил он на самом деле правильно на MySQL-сервере, я хотел бы знать, от людей, которые знают гораздо больше о SQL, чем у меня,
а) почему этот оператор разрешает с правой стороны налево и
b) какие причины для этого. Это проблема производительности? Или я ошибался в отношении «меньше» -оператора прямо из bginning: он никогда не берет левый операнд первым?
c) Я хотел бы знать, является ли это всего лишь результатом MySQL или проблемы, связанной с SQL в целом.

К сожалению, я не могу проверить этот вывод самостоятельно, потому что в настоящее время у меня нет собственного компьютера, на который мне разрешено устанавливать MySQL. Поэтому ваша помощь будет очень признательна:)
Надеюсь, этот вопрос звучит не слишком глупо, но я не мог найти полезные источники в Интернете, которые конкретно объясняют это поведение. Когда я учился, у меня было два модуля о РСУБД, и во всех примерах операторы всегда решались так, как я это делал в первом примере вывода выше. Вот почему я в настоящее время запутался в этом ^^

Заранее благодарим за то, что вы тратили свое время на меня: D с наилучшими пожеланиями.

Answer 1

Обычно у вас есть умный процесс, который определяет, в каком направлении должен обрабатываться конкретный запрос, чтобы сделать его наиболее эффективным. И тогда это просто зависит от этого процесса, и каждый отдельный запрос, если тот или другой сравнивается в первую очередь.

Если ни один из них не является лучшим, то другой это решение, которое зависит от базы данных и базы данных, и я думаю, как вы здесь пишете, что MySQL является правильным ассоциативным.

Answer 2

Это распространенное заблуждение, чтобы ожидать результатов в том порядке, в который он вставлен. Даже если используется кластеризованный индекс, набор результатов может быть не таким, как ожидалось. Единственный способ заставить заказ - использовать предложение order by. Запрос может выполняться параллельно, и результирующий набор может быть объединен, или это может быть связано с планом оптимизации запросов при попытке вернуть набор результатов как можно быстрее. Вот почему такая проблема может возникнуть.