1.8.6.3. Ограничения на Недопустимые Данные

По умолчанию MySQL является прощающим из недопустимых или неподходящих значений данных и принуждает их к допустимым значениям для ввода данных. Однако, можно изменить режим SQL сервера, чтобы выбрать более традиционную обработку плохих значений так, что, сервер отклоняет их и прерывает оператор, в котором они происходят. См. Раздел 5.1.7, "Режимы SQL Сервера".

Этот раздел описывает значение по умолчанию (прощающее) поведение MySQL, так же как строгий режим SQL и как это отличается.

Если Вы не используете строгий режим, то всякий раз, когда Вы вставляете "неправильное" значение в столбец, такой как a NULL в a NOT NULL столбец или также большое числовое значение в числовой столбец, MySQL устанавливает столбец в "самое лучшее значение" вместо того, чтобы произвести ошибку: следующие правила описывают более подробно, как это работает:

Если Вы пытаетесь сохранить из значения диапазона в числовой столбец, MySQL Server вместо этого хранит нуль, самое маленькое значение, или самое большое значение, какой бы ни является самым близким к недопустимому значению.
Для строк MySQL хранит или пустую строку или так много строки, как может быть сохранен в столбце.
Если Вы пытаетесь сохранить строку, которая не запускается с числа в числовой столбец, MySQL Server хранит 0.
Недопустимые значения для ENUM и SET столбцы обрабатываются как описано в Разделе 1.8.6.4,"ENUM и SET Ограничения" .
MySQL позволяет Вам сохранить определенные неправильные значения даты в DATE и DATETIME столбцы (такой как '2000-02-31' или '2000-02-00'). Идея состоит в том, что это не задание SQL-сервера, чтобы проверить дат. Если MySQL может сохранить значение даты и получить точно то же самое значение, MySQL хранит это как дано. Если дата является полностью неправильной (вне возможности сервера сохранить это), специальное "нулевое" значение даты '0000-00-00' сохранен в столбце вместо этого.
Если Вы пытаетесь сохранить NULL в столбец, который не берет NULL значения, ошибка происходит для единственной строки INSERT операторы. Для многократной строки INSERT операторы или для INSERT INTO ... SELECT операторы, MySQL Server хранит неявное значение по умолчанию для типа данных столбца. Вообще, это 0 для числовых типов, пустая строка ('') для строковых типов, и "нулевого" значения для даты и типов времени. Неявные значения по умолчанию обсуждаются в Разделе 11.5, "Значения по умолчанию Типа данных".
Если INSERT оператор не определяет значения для столбца, MySQL вставляет свое значение по умолчанию, если определение столбца включает явное DEFAULT пункт. Если у определения есть не такой DEFAULT пункт, MySQL вставляет неявное значение по умолчанию для типа данных столбца.

Причина использования предыдущих правил в нестрогом режиме состоит в том, что мы не можем проверить эти условия, пока оператор не начал выполняться. Мы не можем просто откатывать, если мы встречаемся с проблемой после обновления нескольких строк, потому что механизм хранения, возможно, не поддерживает откат. Опция завершения оператора не то, что хороша; в этом случае обновление было бы "наполовину сделано,", который является, вероятно, худшим сценарием. В этом случае лучше "сделать лучшее, которое Вы можете" и затем продолжать, как будто ничто не произошло.

В MySQL 5.0.2 и, можно выбрать более строгую обработку входных значений при использовании STRICT_TRANS_TABLES или STRICT_ALL_TABLES Режимы SQL:

SET sql_mode = 'STRICT_TRANS_TABLES';SET sql_mode = 'STRICT_ALL_TABLES';

STRICT_TRANS_TABLES включает строгому режиму для транзакционных механизмов хранения, и также до некоторой степени для нетранзакционных механизмов. Это работает как это:

Для транзакционных механизмов хранения значения неправильных данных, происходящие где угодно в операторе, заставляют оператор прерывать и откатывать.
Для нетранзакционных механизмов хранения прерывается оператор, если ошибка происходит в первой строке, которая будет вставлена или обновлена. (Когда ошибка происходит в первой строке, оператор может быть прерван, чтобы встать из-за неизменного стола, так же, как для транзакционной таблицы.) Ошибки в строках после первого не прерывают оператор, потому что таблица была уже изменена первой строкой. Вместо этого значения неправильных данных корректируются и приводят к предупреждениям, а не ошибкам. Другими словами, с STRICT_TRANS_TABLES, неправильное значение заставляет MySQL откатывать все обновления, сделанные до сих пор, если это может быть сделано, не изменяя таблицу. Но как только таблица была изменена, дальнейший ошибочный результат в корректировках и предупреждениях.

Для еще более строгой проверки включить STRICT_ALL_TABLES. Это - то же самое как STRICT_TRANS_TABLES за исключением того, что для нетранзакционных механизмов хранения, ошибки прерывают оператор даже для неправильных данных в строках после первой строки. Это означает, что, если ошибка происходит отчасти через многократную строку, вставляют или обновляют для нетранзакционной таблицы, частичное обновление заканчивается. Более ранние строки вставляются или обновляются, но те от точки ошибки на не. Чтобы избежать этого для нетранзакционных таблиц, или используйте операторы единственной строки или иначе использование STRICT_TRANS_TABLES если предупреждения преобразования, а не ошибки являются приемлемыми. Чтобы избежать проблем во-первых, не используйте MySQL для контента контрольного столбца. Является самым безопасным (и часто быстрее) позволить приложению гарантировать, что это передает только допустимые значения к базе данных.

С любой из строгих опций режима можно заставить ошибки быть обработанными как предупреждения при использовании INSERT IGNORE или UPDATE IGNORE вместо INSERT или UPDATE без IGNORE.