разный результат в MySQL4 и MySQL5

[Romantik]

разный результат в MySQL4 и MySQL5

Приветствую.

Вот проводил анализ работы одного модуля и заметил не корректные данные.
Глубже копнул и вот что получилось
tableA
id
--
1
2
3
4

tableB
attr
----
1
4

запрос был следующий:

SELECT tableA.id AS attr FROM tableA
LEFT JOIN tableB ON tableA.id = tableB.attr
GROUP BY attr

Результат (MySQL 4.1.18):
attr
----
1
2
3
4
Результат (MySQL 5.0.20):
attr
----
2
1
3

при исправлении запроса на GROUP BY 'attr' (в кавычках)
все заработало правильно, но остались сомнения:
1. Почему так происходит?
2. В GROUP BY берется tableB.attr или все же tableA.id AS attr ?

Заранее благодарен.

 

[vovik]

Для 4-й версии группировка делается по tableA.id AS attr, что нетрудно увидеть по результату запроса. Что делает 5-я версия - я затрудняюсь сказать.

Если бы группировка была по tableB.attr, то запрос вообще неверен - в селекте должны быть либо поля из GROUP BY, либо агрегаты.

И, в любом случае, 5-я версия возвращает откровенный бред

 

[Wicked]

да, действительно похоже на бред Я бы еще понял, если бы пятая версия возвращала резалт сет 1, 2, 4 или 1, 3, 4. Т.е до группировки сет выглядел бы так:

id attr
1 1
2 null
3 null
4 4

А дальше при группировке образовались бы 2 группы из одного элемента (1, 4), и одна группа (null) из двух элементов, из представителей которой _одному_mysqlю_известным_ образом выбралось бы значение 2 или 3.

Если бы группировка была по tableB.attr, то запрос вообще неверен - в селекте должны быть либо поля из GROUP BY, либо агрегаты.

Ну муся чересчур вольно к этому относится.

-~{}~ 27.06.06 21:20:

у меня на 5.0.18 выдает ожидаемый мной результат 1, 2, 4, причем вроде стабильно (1, 3, 4 не попадался ни разу).

 

[Sad Spirit]

Автор оригинала: Romantik
2. В GROUP BY берется tableB.attr или все же tableA.id AS attr ?

Ковыряться в документации на мыскль лениво, в документации на постгрес написано следующее:

GROUP BY will condense into a single row all selected rows that share the same values for the grouped expressions. expression can be an input column name, or the name or ordinal number of an output column (SELECT list item), or an arbitrary expression formed from input-column values. In case of ambiguity, a GROUP BY name will be interpreted as an input-column name rather than an output column name.

В связи с этим приведённый запрос заканчивается следующим живописным образом

test=# SELECT tableA.id AS attr FROM tableA
test-# LEFT JOIN tableB ON tableA.id = tableB.attr
test-# GROUP BY attr;
ERROR: column "tablea.id" must appear in the GROUP BY clause or be used in an a
ggregate function

А мыскль как обычно пытается из любого говна, которое ему в качестве запроса подсунули, конфетку вылепить. У конфетки, впрочем, получается достаточно предсказуемый запах.

-~{}~ 28.06.06 00:32:

Гы, заглянул в документацию на мыскль:

When MySQL resolves an unqualified column or alias reference in an ORDER BY, GROUP BY, or HAVING clause, it first searches for the name in the select_expr values. If the name is not found, it looks in the columns of the tables named in the FROM clause.

То есть: по документации, группировать он должен по tableA.id AS attr, а на самом деле делает какую-то х-ню.

 

[Raziel[SD]]

Romantik
Работает правильно, просто MySQL4 группирует по аллиасу, а пятый мускуль по полю attr, поэтому и получается в результате, до группировки:
+--------+--------+
| id | attr |
+--------+--------+
| 1 | 1 |
| 2 | [NULL] |
| 3 | [NULL] |
| 4 | 4 |
+-------+--------+
после группировки:
+--------+--------+
| id | attr |
+--------+--------+
| 2 | [NULL] |
| 1 | 1 |
| 4 | 4 |
+--------+--------+

 

[Wicked]

Raziel[SD]
И как же у Romantik'а получился такой резалт сет?

attr
----
2
1
3

 

[Raziel[SD]]

Wicked
Ох, действительно, еще не проснулся, не заметил, видимо утро . У меня на MySQL 5.0.21 и 5.0.22 все работает нормально.

 

[vovik]

А где-нибудь в документации MySQL написано, почему оно позволяет указывать в SELECT поля, которых нет в группировке и по какому принципу их выбирает (в данном случае, 2 а не 3) ?

Я к тому, что не считаю это нормальным. Sad Spirit правильно сказал Мускул пытается, видимо, облегчить жизнь новичкам, но в итоге получается печальная картина.

 

[svetasmirnova]

vovik
Кажется на той же странице, куда Sad Spirit дал ссылку.
>То есть: по документации, группировать он должен по tableA.id AS attr, а на самом деле делает какую-то х-ню.
Похоже на баг

 

[vovik]

Автор оригинала: svetasmirnova
Кажется на той же странице, куда Sad Spirit дал ссылку.

Нашел, спасибо.

Do not use this feature if the columns you omit from the GROUP BY part are not constant in the group. The server is free to return any value from the group, so the results are indeterminate unless all values are the same.

 

[Wicked]

Именно это я и имел в виду под "_одному_mysqlю_известным_ образом"