Хорошая, подробная статья по sql_mode, по крайне мере для себя наконец-то понял: почему у некоторых валит ошибки на одни и те же действия когда у других валит лишь предупреждения.
Мне вот интересно, а теперь при получении сертификата по MySQL разработчик тоже будет гордо называться Oracle Certified Professional?
Согласно багу bugs.mysql.com/bug.php?id=23714 данный плагин был разработан 6 лет назад 14 летним подростком, но забыт ввиду того что у парня пропал интерес. Переписка доставляет :)
К тому же хэш-таблица таблиц формируется гораздо быстрее, что позволяет не перелопачивать весь кэш останавливая все селекты, а быстро узнать есть ли там что-то ненужное. А уже потом сделать более оптимизированный запрос по кэшу. Если конечно дописать проталкивание предикатов доступа.
Вдохновлялся этим же автором, о чем написал как в исходниках так и в статье. Но в блоге Боумена к сожалению нет уже ни плагина ни его описания. Рискну предположить что уже несколько лет как. Две таблицы в плагине сделано для того чтобы сразу отловить те таблицы которые в принципе не должны кешироваться из-за своей природы. Можно еще и третью вывести с указанием связей между двумя первыми но считаю это уже лишним.
Про github — понял, чуть позже разберусь и залью. Исходники на хабре действительно совсем не камильфо, да и работать с ними через github будет удобнее.
P.S. Разработчик БД — разрабатывает базы данных на тех инструментах, которые предоставляют разработчики СУБД — систем управления базами данных, которые в свою очередь уже пишут на сях :) я — Database developer.
С временными таблицами в tmpfs такая же солянка. На бумаге все выглядит красиво, все хвалаят у всех работает, а на практике внезапно при выполнении очередного запроска на третий день тестирования оказывается, что таблица не существует, не понимаю как так получается. Думал это у меня одного такой баг.
Э… Там как бы и про лимит не написано, и про остальные сотню комманд которые там можно впихнуть тоже не слова.
Подумайте: почему при любых значениях кроме NULL и 0 этот запрос работает верно? Вот вы упрямы. Вы свои ошибки в сужениях никогда не признаете?
Заметьте, чуть выше один комментатор написал про bigint, и после длительных баталий в личке, я наконец-то понял что он имеет ввиду, и что это действительно может запутять неопытного читателя, и убрал указанный им пунк. Вы же упрямо не хоите верить ни одному запросу, который я привожу вам в качестве аргументации.
Вы даже не знали про cинтаксис комманды group by! И упорно настаиваете на том, что вы правы, делая это самым хамским образом у всех за спиной… Не надо путать и оскорблять ни меня ни читателя, пожалуйста.
При чем тут автокаст? Автокаст — это workaround для этого бага. сортировка все сортирует по индексам и верно, почему максимальных по индексу элемент '1' а не '0'?
1. запрос не кривой, он успешно работает, и даже всегда за исключением одного случая, возвращает корректные данные.
2. интерпретация запросов неверна в каждом из моих комментариев, но SQL не врет ибо в данном конкретном случае NULL действительно неотличим от 0
3. см 2 пункт выше и пример с 0 и 1, чем они кривой?
4. во всей стаье выводы совершенно бредовые, неужели вы этого не заметили?
5. все это является багами MySQL если вы захотите вы даже сможете найти их номера. Когда я получал данные ошибки я сознательно не заводил баги, ибо пробежавшись по bugs.mysql.com находил очень похожие. Все эти баги не решены до сих пор. Если хотите можете поискать, вон выше сам разработчик MySQL как раз завел новый баг на основании нашего обсуждения этих фич. Вот он bugs.mysql.com/bug.php?id=67978. И поверьте каждый описанный случай основан именно на баге. Конечно сами запросы в которых они возникли гораздо сложнее, но для статьи я переделал их, для того чтобы максимально упростить.
Давайте я на всякий случай переведу, чтобы исключить разночтения.
Сортировка. ENUM значения сортируются на основании их номера индекса
Соотвественно было бы разумно ожидать что в перечислении данного типа:
enum('1','0')
элемент с именем '1' имеет порядковый номер 1, а элемент с именем '0' порядковый номер 2.
Тут как бы MySQL с нами полностью согласен:
select number_value, number_value 0
from two_numbers
order by number_value desc;
------ ------
| val | ord |
------ ------
| 0 | 2 |
| 1 | 1 |
------ ------
Но вот те кто писал функцию MAX(MIN) об этом видимо не знали, так как
select min(number_value) min_val from two_numbers;
---------
| min_val |
---------
| 0 |
---------
1 row in set (0.00 sec)
т.е. сравнение производится не согласно индексам, как они заданы при создании, а просто в лексикографическом порядке. При чем первая же арифметическая операция заставляет работать MySQL согласно документации.
А еще раз подумать:
Я почитал ваши статьи, ряд из них я нашел даже интересными, ибо сам раньше программировал под Oracle, так что действительно — подумайте, вроде статья старая, никто никуда не спешит.
Очень даль что вы считаете меня идотом, а мой пост "имбанутым гавном", о чем вы почему-то не постеснялись написать в твиттере, но постеснялись сказать мне лично в комментариях в этом топике, но я считаю кокретно с вашим вопросом надо разобраться. Новый год все таки. Надо быть позитивнее :)
Я такого запроса категорически не понимаю! Что за группировка по второму полю, а дистинкт без агрегата по первому?
В отличии от Oracle, в котором вы видимо привыкли работать, MySQL допускает ряд фривольностей в написании group by запросов. К примеру если выбрать поля, по которым не произведена группировка, то MySQL возьмет для значения этого поля — первое попавшееся ему значение в таблице. Т.е. тот результат примера, который вы привели далее немного подумав — вполне ожидаем. Вы произвели группировку по полю с единственным значением, а выбрали поле, по которому группировка не производилась. Собственно MySQL взял первое что ему попалось и вывел в результируещем resultset'е. Я же делаю немного другое. Я провожу группировку по полу в котором 4 значения. Так что у меня получается 4 кортежа. Далее я просто выбираю уникальные поля из всего того что у меня получилось, опуская собственно поля группировки. Воспроизведем эти шаги на значения отличных от NULL.
получим 0 и 1
drop table if exists null_equals_zero;
create table null_equals_zero(int_value int,
group_value int
)
engine = innodb;
insert into null_equals_zero
values (1, 1), (0, 2), (1, 3), (0, 4);
select int_value
from null_equals_zero
group by group_value;
+-----------+
| int_value |
+-----------+
| 1 |
| 0 |
| 1 |
| 0 |
+-----------+
4 rows in set (0.00 sec)
select distinct int_value
from null_equals_zero
group by group_value;
+-----------+
| int_value |
+-----------+
| 1 |
| 0 |
+-----------+
2 rows in set (0.00 sec)
теперь же попробуем пример из статьи
получим только одно значение
drop table if exists null_equals_zero;
create table null_equals_zero(int_value int,
group_value int
)
engine = innodb;
insert into null_equals_zero
values (null, 1), (0, 2), (null, 3), (0, 4);
select int_value
from null_equals_zero
group by group_value;
+-----------+
| int_value |
+-----------+
| NULL |
| 0 |
| NULL |
| 0 |
+-----------+
4 rows in set (0.00 sec)
select distinct int_value
from null_equals_zero
group by group_value;
+-----------+
| int_value |
+-----------+
| NULL |
+-----------+
1 row in set (0.00 sec)
то, что лежит в БД первее 0 или NULL, но не оба значения сразу, что доказывает предыдущий мой пример из комментария.
Я рискну предположить, что тут дело в оптимизаторе, который умеет оптимизировать конструкции типа group by если так же в условии встречается distinct или же limit (с ним тоже есть немало интересных багов, но они сложнее в понимании по этому я их тут не стал приводить, а привел только те, что можно быстро понять).
Если вам непонятет синтаксис, не стоит говорить что это идиотский запрос, ибо парсер отлично этот запрос отработал и даже вернул результат, что уже говорит о том, что запрос написан верно. Стоит все таки действительно немного подумать.
З.Ы. а по поводу неверной оценки статей я с вами частично согласен, ибо на хабре действительно есть множество интересных, по моему мнению технических статей, которые были недостаточно оценены сообществом, но только в этом…
Вы используете исключительно кривой запрос с багом.
Странно я вроде так и писал в своей статье, очень жаль что вы приняли все за чистую монету. Конечно баги на то и баги, что не везде встречаются. Я просто сделал подборку из тех багов с которыми пришлось столкнуться на протяжении последних трех лет работы…
Ваше нежелание почитать как конкретно реализован group by в mysql не позволяет мне продолжать с вами дискуссию. По сему во избежание холиваров предлагаю каждому из нас остаться при своем мнении.
Странно но официальная документация с вами не согласна Sorting
ENUM values are sorted based on their index numbers, which depend on the order in which the enumeration members were listed in the column specification. For example, 'b' sorts before 'a' for ENUM('b', 'a'). The empty string sorts before nonempty strings, and NULL values sort before all other enumeration values.
To prevent unexpected results when using the ORDER BY clause on an ENUM column, use one of these techniques:
Specify the ENUM list in alphabetic order.
Make sure that the column is sorted lexically rather than by index number by coding ORDER BY CAST(col AS CHAR) or ORDER BY CONCAT(col).
Т. е. Я так понимаю вас не смущает что максимальный элемент имеет индекс 2 хотя я четко вижу что согласно декларации индекс 2 имеет элемент '0' а никак не '1'? Вы глубже смотрите а не на то как называются поля и таблицы.
Мне вот интересно, а теперь при получении сертификата по MySQL разработчик тоже будет гордо называться Oracle Certified Professional?
P.S. Разработчик БД — разрабатывает базы данных на тех инструментах, которые предоставляют разработчики СУБД — систем управления базами данных, которые в свою очередь уже пишут на сях :) я — Database developer.
Подумайте: почему при любых значениях кроме NULL и 0 этот запрос работает верно? Вот вы упрямы. Вы свои ошибки в сужениях никогда не признаете?
Заметьте, чуть выше один комментатор написал про bigint, и после длительных баталий в личке, я наконец-то понял что он имеет ввиду, и что это действительно может запутять неопытного читателя, и убрал указанный им пунк. Вы же упрямо не хоите верить ни одному запросу, который я привожу вам в качестве аргументации.
Вы даже не знали про cинтаксис комманды group by! И упорно настаиваете на том, что вы правы, делая это самым хамским образом у всех за спиной… Не надо путать и оскорблять ни меня ни читателя, пожалуйста.
2. интерпретация запросов неверна в каждом из моих комментариев, но SQL не врет ибо в данном конкретном случае NULL действительно неотличим от 0
3. см 2 пункт выше и пример с 0 и 1, чем они кривой?
4. во всей стаье выводы совершенно бредовые, неужели вы этого не заметили?
5. все это является багами MySQL если вы захотите вы даже сможете найти их номера. Когда я получал данные ошибки я сознательно не заводил баги, ибо пробежавшись по bugs.mysql.com находил очень похожие. Все эти баги не решены до сих пор. Если хотите можете поискать, вон выше сам разработчик MySQL как раз завел новый баг на основании нашего обсуждения этих фич. Вот он bugs.mysql.com/bug.php?id=67978. И поверьте каждый описанный случай основан именно на баге. Конечно сами запросы в которых они возникли гораздо сложнее, но для статьи я переделал их, для того чтобы максимально упростить.
Соотвественно было бы разумно ожидать что в перечислении данного типа:
элемент с именем '1' имеет порядковый номер 1, а элемент с именем '0' порядковый номер 2.
Тут как бы MySQL с нами полностью согласен:
Но вот те кто писал функцию MAX(MIN) об этом видимо не знали, так как
т.е. сравнение производится не согласно индексам, как они заданы при создании, а просто в лексикографическом порядке. При чем первая же арифметическая операция заставляет работать MySQL согласно документации.
Я почитал ваши статьи, ряд из них я нашел даже интересными, ибо сам раньше программировал под Oracle, так что действительно — подумайте, вроде статья старая, никто никуда не спешит.
В отличии от Oracle, в котором вы видимо привыкли работать, MySQL допускает ряд фривольностей в написании group by запросов. К примеру если выбрать поля, по которым не произведена группировка, то MySQL возьмет для значения этого поля — первое попавшееся ему значение в таблице. Т.е. тот результат примера, который вы привели далее немного подумав — вполне ожидаем. Вы произвели группировку по полю с единственным значением, а выбрали поле, по которому группировка не производилась. Собственно MySQL взял первое что ему попалось и вывел в результируещем resultset'е. Я же делаю немного другое. Я провожу группировку по полу в котором 4 значения. Так что у меня получается 4 кортежа. Далее я просто выбираю уникальные поля из всего того что у меня получилось, опуская собственно поля группировки. Воспроизведем эти шаги на значения отличных от NULL.
теперь же попробуем пример из статьи
то, что лежит в БД первее 0 или NULL, но не оба значения сразу, что доказывает предыдущий мой пример из комментария.
Я рискну предположить, что тут дело в оптимизаторе, который умеет оптимизировать конструкции типа group by если так же в условии встречается distinct или же limit (с ним тоже есть немало интересных багов, но они сложнее в понимании по этому я их тут не стал приводить, а привел только те, что можно быстро понять).
Если вам непонятет синтаксис, не стоит говорить что это идиотский запрос, ибо парсер отлично этот запрос отработал и даже вернул результат, что уже говорит о том, что запрос написан верно. Стоит все таки действительно немного подумать.
З.Ы. а по поводу неверной оценки статей я с вами частично согласен, ибо на хабре действительно есть множество интересных, по моему мнению технических статей, которые были недостаточно оценены сообществом, но только в этом…
Странно я вроде так и писал в своей статье, очень жаль что вы приняли все за чистую монету. Конечно баги на то и баги, что не везде встречаются. Я просто сделал подборку из тех багов с которыми пришлось столкнуться на протяжении последних трех лет работы…
Sorting ENUM values are sorted based on their index numbers, which depend on the order in which the enumeration members were listed in the column specification. For example, 'b' sorts before 'a' for ENUM('b', 'a'). The empty string sorts before nonempty strings, and NULL values sort before all other enumeration values. To prevent unexpected results when using the ORDER BY clause on an ENUM column, use one of these techniques: Specify the ENUM list in alphabetic order. Make sure that the column is sorted lexically rather than by index number by coding ORDER BY CAST(col AS CHAR) or ORDER BY CONCAT(col).Т. е. Я так понимаю вас не смущает что максимальный элемент имеет индекс 2 хотя я четко вижу что согласно декларации индекс 2 имеет элемент '0' а никак не '1'? Вы глубже смотрите а не на то как называются поля и таблицы.
и именно из-за этого я не люблю ENUM, но вроде это тоже документировано