Давайте поговорим о sql_mode в MySQL?

Question

[Alex]

В русскоязычном сегменте не так много информации о выборе режимов для данного параметра. Часто это либо просто их перечисление, либо рассмотрена лишь небольшая часть, либо просто устаревшая информация.

На хабре есть несколько постов о режимах sql_mode в MySQL:
habrahabr.ru/post/166411
habrahabr.ru/post/116922

Значение параметра по умолчанию:

• До 5.6.6 - "" (пустое значение)
• Начиная с 5.6.6 - NO_ENGINE_SUBSTITUTION
• Начиная с 5.7.5 - ONLY_FULL_GROUP_BY, NO_ENGINE_SUBSTITUTION, STRICT_TRANS_TABLES

Предлагаю в этом вопросе поделиться опытом, какие плюсы/минусы вы обнаружили для себя при включении/невключении того или иного режима. Соберем, так сказать, базу знаний по данному параметру.
У кого какие значения на продакшенах? Как эти режимы повлияли на написание вами кода в используемых вами языках программирования? Может они каким-то образом сломали сторонние скрипты и приложения?
Чем больше режимов мы тут обсудим, тем, разумеется, лучше.
Возможно, мы даже прийдем к некоторой типовой конфигурации данного параметра на сегодняшний день.

Answer 1

[Сергей Протько]

оукей, давайте соберем базу знаний. Действительно полезное дело сделаем... А хотя нет. Можно просто почитать в документации к mysql что за что отвечает
dev.mysql.com/doc/refman/5.0/en/sql-mode.html
причем с примерами. По большей части это неплохие ограничения для разработчика, которые позволяют избежать потенциальных ошибок.

Начиная с 5.7.5

что?

Comments

[Alex]

Я так и знал, что ты докапаешься и тут до меня))
Я же написал: "...Часто это либо просто их перечисление...", а я предлагаю поделиться реальным опытом использования разных режимов в реальных проектах. Например, включил режим такой-то - отвалилась доктрина и т.д.

As of MySQL 5.7.5, the default SQL mode includes STRICT_TRANS_TABLES.
dev.mysql.com/doc/refman/5.7/en/server-system-vari...

[Дмитрий Энтелис]

@shoomyst: у меня есть субъективное мнение что эти чудесные истории как раз предназначены для бездумной поддержки [старого] говнокода либо решения каких то ну очень специфических историй.

[Alex]

Ну хорошо, если всё так просто в этом вопросе и всё однозначно, то какой режим надо использовать сейчас в проектах?

[Сергей Протько]

@shoomyst: тот который вам нужен. Скажем если вы специально пишите запросы вида

SELECT name, email, MAX(age) FROM users GROUP BY name;

то логично что стоит отключить ONLY_FULL_GROUP_BY. В остальных случаях лучше что бы оно было включено. Точто так же со всеми остальными директивами. С остальными директивами золотой середины нет. Под требования к проекту стоит подбирать. Скажем директивы типа HIGH_NOT_PRECEDENCE вообще для совместимости добавили, что бы легаси проекты не отвалились после обноваления mysql-server.

Что до доктрины - она не отвалится. Отвалятся ваши запросы.

[Alex]

@Fesor: зачем в остальных случаях включать ONLY_FULL_GROUP_BY, если оно только мешает делать выборку по невходящим в group полям?

[Alex]

@Fesor: ок, спрошу по-другому. Вы начинаете завтра новый проект, какое значение данного параметра для своего проекта вы установите?

[Сергей Протько]

@shoomyst: а вы часто такие выборки делаете? В них нету смысла, так как поле name и max(age) это агригированные данные, то все хорошо, а email будет выбран только для одного пользователя из группы. В подавляющем большинстве случаев подобные запросы являются местом потенциальной ошибки со стороны программиста. Потому лучше сгенерить варнинг чем потом тратить время на дебаг.

[Сергей Протько]

@shoomyst: оставлю дефолтные, так как мне по сути этого хватит. А вообще новые проекты у меня на postgresql.

Answer 2

[Alex]

Пока остановаюсь на таком режиме:

• STRICT_TRANS_TABLES
• IGNORE_SPACE
• NO_AUTO_CREATE_USER
• NO_ENGINE_SUBSTITUTION
• ONLY_FULL_GROUP_BY
• PIPES_AS_CONCAT