|
|
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
Arhat109, насколько я понял Ваше возражение, оптимизатор в процессе построения оптимального плана выполнения может просто проигнорировать сортировку итогов вложенного запроса? Не уверен, что он вправе проводить такую "оптимизацию"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 12:58:38 |
|
||
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
Хотя, с другой стороны... Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Чтобы предотвратить материализацию итогов вложенного запроса во временную таблицу, возможно, оптимизатор и проигнорирует внутреннюю сортировку... И тогда действительно будут получены неверные данные... Только неясно тогда, почему MySQL допускает ее (внутреннюю сортировку) синтаксически... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 13:05:57 |
|
||
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
Cygapb-007Не уверен, что он вправе проводить такую "оптимизацию"...Тут подходить надо с другой стороны. Ему не запрещено её проводить, т.к. порядок внутренней сортировки никак не должен влиять на порядок сортировки итога. Cygapb-007Только неясно тогда, почему MySQL допускает ее (внутреннюю сортировку) синтаксически...Ну он и check constraints допускает при создании таблицы, а на самом деле ими там и не пахло ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 13:56:38 |
|
||
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
Cygapb-007оптимизатор в процессе построения оптимального плана выполнения может просто проигнорировать сортировку итогов вложенного запроса? Не уверен, что он вправе проводить такую "оптимизацию"...Смутно припоминаю, что видел в доке упоминание, что вправе. К сожалению, найти сейчас не могу. Однако, нашел вот это: MySQL 5.6 subquery ORDER BY behaviour changed from 5.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 14:21:37 |
|
||
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
В общем, ONLY_FULL_GROUP_BY должно быть всегда включено , потому что никакой оптимизацией тут и не пахнет, зато прямо-таки воняет причиной неявных ошибок в коде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 14:24:16 |
|
||
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
Cygapb-007, Проблема в том, что внутренним подзапросом вы получаете некий промежуточный набор, даже отсортированный "как надо". Но, на внешнем уровне у вас стоит только группировка без агрегирования. И, как раз, в случае отсутствия выкладки во временную табличку, при сборке выхода, остальные части неагрегированной выдачи, Мускуль вправе взять "первые попавшиеся"... не из внутренней таблички подзапроса, а ваще первые попавшиеся. Вы ему ЭТО РАЗРЕШИЛИ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 14:25:33 |
|
||
|
Нужен совет от гуру
|
|||
|---|---|---|---|
|
#18+
miksoftCygapb-007оптимизатор в процессе построения оптимального плана выполнения может просто проигнорировать сортировку итогов вложенного запроса? Не уверен, что он вправе проводить такую "оптимизацию"...Смутно припоминаю, что видел в доке упоминание, что вправе. К сожалению, найти сейчас не могу. Однако, нашел вот это: MySQL 5.6 subquery ORDER BY behaviour changed from 5.5 Спасибо, ссылка "в жилу". Повторимость результата, к сожалению, не гарантирует, но зато прекрасно демонстрирует своеволие сервера (как и было обещано в документации) по выбору включаемой в итог строки из группы . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2013, 14:32:15 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38363004&tid=1836264]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 320ms |

| 0 / 0 |
