Глава 1. Общая информация

Программное обеспечение MySQL поставляет очень быстрый, мультипоточный и многопользовательский сервер базы данных SQL. Сервер MySQL предназначен для решения ответственных задач, производственных систем тяжелой нагрузки, так же как для того, чтобы встроить в массово развернутое программное обеспечение. Oracle зарегистрированная торговая марка Oracle Corporation и/или ее филиалов. MySQL торговая марка Oracle Corporation и/или ее филиалов, и не должна использоваться клиентом без явно записанного разрешения Oracle. Другие имена могут быть торговыми марками соответствующих владельцев.

Программное обеспечение MySQL имеет двойную лицензию. Пользователи могут использовать программное обеспечение MySQL в качестве общедоступного продукта в соответствии с GNU General Public License ( http://www.fsf.org/licenses/) или могут купить стандартную коммерческую лицензию от Oracle. См. http://www.mysql.com/company/legal/licensing/.

Следующий список описывает некоторые особенно интересные разделы в этом руководстве:

Чтобы сообщить о проблемах или ошибках, пожалуйста, используйте инструкции в разделе 1.7. Если Вы находите чувствительную ошибку безопасности в сервере MySQL, пожалуйста, сообщите нам немедленно, посылая электронное письмо на <secalert_us@oracle.com >. Исключение: клиенты поддержки должны сообщить обо всех проблемах, включая ошибки безопасности, в Oracle Support.

1.1. Об этом руководстве

Это руководство для системы базы данных MySQL версии 8.0. Различия между незначительными версиями MySQL 8.0 отмечены в существующем тексте в отношении номеров выпуска (8.0.x). Для информации о лицензии см. Legal Notices.

Это руководство не предназначено для использования с более старыми версиями программного обеспечения MySQL из-за многих функциональных и других различий между MySQL 8.0 и предыдущими версиями. Если Вы используете более ранний выпуск программного обеспечения MySQL, пожалуйста, используйте соответствующее руководство. Например, MySQL 5.7 Reference Manual покрывает ряд 5.7 программного обеспечения MySQL.

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

MySQL Database Software находится в процессе постоянного развития, и это руководство также обновлено часто. Новая версия руководства доступна онлайн в доступной для поиска форме на http://dev.mysql.com/doc/. Другие форматы также доступны там, включая HTML, PDF и EPUB.

Исходные файлы Руководства написаны в формате DocBook XML. Версия HTML и другие форматы произведены автоматически, прежде всего используя таблицы стилей DocBook XSL. См. http://docbook.org/.

Исходный код для самого MySQL содержит внутреннюю документацию, созданную с прменением Doxygen. Произведенный контент Doxygen доступен га at http://dev.mysql.com/doc/dev/mysql-server/latest/. Также возможно произвести этот контент в местном масштабе от исходного дистрибутива MySQL, используя инструкции в разделе 2.8.7.

Если у Вас есть вопросы об использовании MySQL, Вы можете задать их, используя наши списки рассылки или форумы. См. разделы 1.6.1 и раздел 1.6.2. Если у Вас есть предложения относительно дополнений или исправлений к руководству непосредственно, пожалуйста, пошлите их в http://www.mysql.com/company/contact/.

1.2. Соглашения о синтаксисе в руководстве

Это руководство использует определенные типографские соглашения:

Когда показывают команды, которые предназначаются, чтобы выполнить изнутри особой программы, подсказка, показанная перед командой, указывает, которую программу использовать. Например, shell> указывает на команду, которую Вы выполняете от своей командной оболочки, root-shell> подобна, но должна быть выполнена как root, mysql> указывает на запрос, что Вы выполняете из клиента mysql :

shell> type a shell command here
root-shell> type a shell command as root here
mysql> type a mysql statement here
В некоторых областях различные системы можно отличить друг от друга, чтобы показать, что команды должны быть выполнены в двух различных средах. Например, работая с репликацией команды могли бы быть предварительно установлены с master и slave:
master> type a mysql command on the replication master here
slave> type a mysql command on the replication slave here
shell является Вашим командным интерпретатором. В Unix это обычно sh, csh или bash. В Windows command.com или cmd.exe в окне консоли.

Когда Вы вводите команду или запрос, не вводите подсказку, показанную в примере.

Имена баз данных, таблиц и столбцов нужно часто заменять. Чтобы указать, что такая замена необходима, это руководство использует db_name, tbl_name и col_name. Например, Вы могли бы видеть такой запрос:

mysql> SELECT col_name FROM db_name.tbl_name;
Это означает, что, если бы Вы должны были ввести подобный запрос, Вы подставляли бы свою собственную базу данных, таблицу и имена столбцов, возможно, как это:
mysql> SELECT author_name FROM biblio_db.author_list;
Ключевые слова SQL не являются чувствительными к регистру и могут быть написаны в любом регистре. Это руководство использует верхний регистр.

В описаниях синтаксиса квадратные скобки ([ и ]) указывают на дополнительные слова или пункты. Например, в следующем запросе IF EXISTS является дополнительным:

DROP TABLE [IF EXISTS] tbl_name
Когда элемент синтаксиса состоит из многих альтернатив, альтернативы отделены вертикальными линиями (|). Когда один участник ряда может быть выбран, альтернативы перечислены в пределах квадратных скобок ([ и ]):
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)
Когда один участник из ряда выбора должен быть выбран, альтернативы перечислены в пределах фигурных скобок ({ и }):
{DESCRIBE | DESC} tbl_name [col_name | wild]
Многоточие (...) указывает на упущение раздела запроса, как правило, чтобы обеспечить более короткую версию более сложного синтаксиса. Например, SELECT ... INTO OUTFILE сокращение для формы SELECT, который имеет INTO OUTFILE после других частей запроса.

Многоточие может также указать, что предыдущий элемент синтаксиса может быть повторен. В следующем примере, многократные значения reset_option могут быть даны, после каждого из них должна быть запятая:

RESET reset_option [,reset_option] ...
Команды для того, чтобы установить переменные оболочки показывают, используя синтаксис оболочки Bourne shell. Например, последовательность, чтобы установить переменную окружения CC и выполнить команду configure в Bourne shell:
shell> CC=gcc ./configure

Если Вы используете csh или tcsh, Вы должны выпустить команды несколько по-другому:

shell> setenv CC gcc
shell> ./configure

1.3. Краткий обзор СУБД MySQL

1.3.1. Что такое MySQL?

MySQL самая популярная общедоступная система управления базой данных SQL, развит, распределен и поддержан Oracle Corporation.

MySQL Web-сайт ( http://www.mysql.com/) предоставляет последнюю информацию о программном обеспечении MySQL.

Официальным способом произношения MySQL является My Ess Que Ell (не my sequel), но мы не возражаем, если Вы объявляете это как my sequel или некоторым другим ограниченным способом.

1.3.2. Основные особенности MySQL

Этот раздел описывает некоторые из важных характеристик программного обеспечения базы данных MySQL. В большинстве отношений дорожная карта относится ко всем версиям MySQL. Для информации об особенностях, поскольку они введены в MySQL на определенной для ряда основе, см. раздел In a Nutshell соответствующего руководства:

Внутренности и мобильность

Типы данных

Запросы и функции

Безопасность

Масштабируемость и пределы

Связь

Локализация

Клиенты и инструменты

1.3.3. История MySQL

Мы начали с намерения использовать систему базы данных mSQL, чтобы соединить с нашими таблицами, используя наш собственный быстрый низкий уровень (ISAM). Однако, после некоторого тестирования, мы пришли к выводу, что mSQL не был достаточно быстр или достаточно гибок для наших потребностей. Это привело к новому интерфейсу SQL к нашей базе данных, но с почти тем же самым интерфейсом API как у mSQL. Этот API был разработан, чтобы позволить имеющему отношение к третьей стороне коду, который был написан для использования с mSQL быть перенесенным легко для использования с MySQL.

MySQL называют в честь дочери соучредителя Monty Widenius's, My.

MySQL Dolphin (лого) был выбран из огромного списка имен, предложенных пользователями в нашем соревновании Name the Dolphin. Имя победы было представлено Ambrose Twebaze, как разработчиком программного обеспечения Open Source из Swaziland, Africa. Согласно Ambrose, у женского имени Sakila есть свои корни в SiSwati, местном языке. Sakila также название города в Arusha, Tanzania, около страны происхождения Ambrose's, Uganda.

1.4. Что нового в MySQL 8.0

Этот раздел суммирует то, что было добавлено и удалено из MySQL 8.0. Сопутствующий раздел перечисляет параметры сервера MySQL и переменные, которые были добавлены или удалены в MySQL 8.0. См. раздел 1.5.

Особенности, добавленные в MySQL 8.0

Следующие опции были добавлены к MySQL 8.0:

Особенности, устаревшие в MySQL 8.0

Следующие особенности устарели в MySQL 8.0 и могут быть или будут удалены в будущем ряду. Где альтернативы показаны, приложения должны быть обновлены, чтобы использовать их.

Особенности, удаленные в MySQL 8.0

Следующие элементы являются устаревшими и были удалены в MySQL 8.0. Где альтернативы показаны, приложения должны быть обновлены, чтобы использовать их.

1.5. Переменные состояния и опции, добавленные, устаревшие или удаленные в MySQL 8.0

Этот раздел перечисляет переменные сервера, переменные состояния и опции, которые были добавлены, устарели или были удалены в MySQL 8.0.

Где применимый, отдельные списки были предоставлены для переменных и опций, которые были добавлены, удалены или устарели в пределах каждого раздела.

Опции и переменные, введенные в MySQL 8.0

Следующие системные переменные, переменные состояния и опции новы в MySQL 8.0 и не были включены ни в какую предыдущую серию выпуска.

Опции и Переменные, устаревшие в MySQL 8.0

В настоящее время, никакие опции или переменные не устарели в MySQL 8.0.

Опции и переменные, удаленные в MySQL 8.0

Следующие системные переменные, переменные состояния и опции были удалены в MySQL 8.0.

1.6. Источники информации MySQL

Этот раздел перечисляет источники дополнительной информации, которую Вы можете счесть полезным, такие как списки рассылки MySQL, пользовательские форумы и Internet Relay Chat.

1.6.1. Списки рассылки MySQL

Этот раздел вводит списки рассылки MySQL и обеспечивает направления относительно того, как списки должны использоваться. Когда Вы подписываетесь на список рассылки, Вы получаете все сообщения списка как электронные письма. Вы можете также послать свои собственные вопросы и ответы в список.

Чтобы подписаться или отписаться от любого из списков рассылки, описанных в этом разделе, посетите http://lists.mysql.com/. Для большинства из них Вы можете выбрать регулярную версию списка, где Вы получаете отдельные сообщения, или версию обзора, где Вы получаете одно большое сообщение в день.

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

У Вашего местного сайта может быть много подписчиков на список рассылки MySQL. Если так, у сайта может быть местный список рассылки, чтобы сообщения с lists.mysql.com на Ваш сайт размножены к местному списку. В таких случаях, пожалуйста, свяжитесь со своим системным администратором, чтобы быть добавленными или исключенными из местного списка MySQL.

Чтобы направить трафик списка рассылки в отдельный почтовый ящик в Вашей почтовой программе, настройте фильтр, основанный на заголовках сообщения. Вы можете использовать List-ID: или Delivered-To:, чтобы идентифицировать сообщения списка.

Списки рассылки MySQL следующие:

Если Вы неспособны получить ответ на свои вопросы от списка рассылки MySQL или форума, можно купить поддержку со стороны Oracle. Это помещает Вас в прямой контакт с разработчиками MySQL.

Следующие списки рассылки MySQL на языках кроме английского языка. Этими списками не управляет Oracle.

1.6.1.1. Как использовать списки рассылки

Пожалуйста, не посылайте почтовые объявления из своего браузера с включенным режимом HTML. Много пользователей не читают почту с браузером.

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

Попытайтесь суммировать основную часть вопроса в Вашем ответе. Не чувствуйте себя обязанными заключить все исходное сообщение в кавычки.

Когда ответы посылают Вам индивидуально а не списку рассылки, считают хорошим этикетом суммировать ответы и послать резюме в список рассылки так, чтобы другие могли обладать преимуществом ответов, которые Вы получили, что помогло Вам решить свою проблему.

1.6.2. Общественная поддержка MySQL на форумах

Форумы в http://forums.mysql.com являются важным ресурсом сообщества. Много форумов доступны, сгруппированные в эти общие категории:

1.6.3. Общественная поддержка MySQL в Internet Relay Chat (IRC)

В дополнение к различным спискам рассылки MySQL и форумам, Вы можете найти опытных людей сообщества в Internet Relay Chat (IRC). Это лучшие сети/каналы, в настоящее время известные нам:

freenode (см. http://www.freenode.net/ ).

Если Вы ищете клиентское программное обеспечение IRC, чтобы соединиться с сетью IRC, попробуйте xChat (http://www.xchat.org/). X-Chat (GPL) доступен для Unix и Windows (Windows X-Chat: http://www.silverex.org/download/).

1.6.4. MySQL Enterprise

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

MySQL Enterprise доступна, давая Вам гибкость, чтобы выбрать уровень обслуживания, лучше соответствующий Вашим потребностям. Для получения дополнительной информации см. MySQL Enterprise.

1.7. Как сообщить об ошибках или проблемах

Прежде, чем отправить отчет об ошибке, пожалуйста, попытайтесь проверить, что это ошибка, и что об этом еще не сообщили:

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

Нормальный способ сообщить об ошибках состоит в том, чтобы посетить http://bugs.mysql.com/, который является адресом для нашей базы данных ошибок. Эта база данных является общественной и может быть просмотрена любым. Если Вы входите в систему, Вы можете ввести новые отчеты.

Ошибки в базе данных ошибок на http://bugs.mysql.com/, которые исправлены для данного выпуска, отмечены в информации о версии.

Если Вы находите чувствительную ошибку безопасности в MySQL Server, пожалуйста, сообщите нам немедленно, посылая электронное письмо на <secalert_us@oracle.com >. Исключение: клиенты поддержки должны сообщить обо всех проблемах, включая ошибки безопасности, в http://support.oracle.com/.

Чтобы обсудить проблемы с другими пользователями, Вы можете использовать один из списков рассылки MySQL. См. раздел 1.6.1.

Написание хорошего отчета об ошибках требует терпения, но выполнение этого экономит время для нас и для вас непосредственно. Хороший отчет об ошибках, содержащий полный прецедент для ошибки, делает очень вероятным, что мы исправим ошибку в следующем выпуске. Этот раздел помогает Вам написать свой отчёт правильно так, чтобы Вы не потратили впустую свое время. Пожалуйста, читайте этот раздел тщательно и удостоверьтесь, что вся информация, описанная здесь, включена в Ваш отчет.

Предпочтительно, Вы должны проверить проблему, используя последнюю версию MySQL Server. Любой должен быть в состоянии повторить ошибку, используя только mysql test < script_file на Вашем прецеденте или выполняя скрипт Perl, который Вы включаете в отчет об ошибках. У любой ошибки, которую мы в состоянии повторить, есть высокий шанс быть исправленной в следующем выпуске MySQL.

Является самым полезным, когда хорошее описание проблемы включено в отчет об ошибках. Таким образом, дайте хороший пример всего, что Вы сделали, который привел к проблеме, и опишите, в точных деталях, проблему. Лучшие отчеты те, которые включают полный пример, показывающий, как воспроизвести ошибку или проблему. См. раздел 26.5.

Помните, что для нас возможно ответить на отчет, содержащий слишком большую информацию, но не слишком мало. Люди часто опускают факты, потому что они думают, что знают причину проблемы и предполагают, что некоторые детали не имеют значения. Хороший принцип: если есть сомнение о чем-то, заявите это. Быстрее и проще написать пару лишних строк в Вашем отчете, чем ждать дольше ответа, если мы должны попросить, чтобы Вы предоставили информацию, которая отсутствовала в первоначальном сообщении.

Наиболее распространенные ошибки, сделанные в отчетах об ошибках, (a) не включен номер версии MySQL, которую Вы используете, и (b) не полностью описана платформа, на которой сервер MySQL установлен (включая тип платформы и номер версии). Это очень важные сведения, в 99 ситуациях из 100 отчет об ошибках бесполезен без них. Ошибки часто зависимы от платформы. В таких случаях почти невозможно установить что-либо, не зная операционную систему и номер версии платформы.

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

Если программа производит сообщение об ошибке, очень важно включать сообщение в Ваш отчет. Если мы пытаемся искать что-то из архивов, лучше, чтобы сообщение об ошибке сообщило точно, что искать. Даже регистр символов важен. Лучше копировать и вставлять все сообщение об ошибке в Ваш отчет. Вы никогда не должны пытаться воспроизвести сообщение по памяти.

Если у Вас есть проблема с Connector/ODBC (MyODBC), пожалуйста, попытайтесь произвести файл трассировки и послать его с Вашим отчетом. См. How to Report Connector/ODBC Problems or Bugs.

Если Ваш доклад включает в себя длинные выходные строки запроса от прецедентов, которые Вы выполняете с mysql, Вы можете сделать вывод более читаемым при использовании опции --vertical или \G. Пример EXPLAIN SELECT позже в этом разделе демонстрирует использование \G.

Пожалуйста, включайте следующую информацию в свой отчет:

1.8. Соответствие стандартам MySQL

Этот раздел описывает, как MySQL касается стандартов ANSI/ISO SQL. У MySQL Server есть много расширений стандарта SQL, здесь Вы можете узнать то, что они такое и как использовать их. Вы можете также найти информацию о функциональности, отсутствующей в MySQL Server, и как работать для некоторых из различий.

Стандарт SQL развивался с 1986, и несколько версий существуют. В этом руководстве SQL-92 обращается к стандарту, выпущенному в SQL:1999 в 1999, SQL:2003 в 2003, а SQL:2008 обращается к новой версии стандарта, выпущенной в 2008. Мы используем фразу "стандарт SQL", чтобы обозначить текущую версию стандарта SQL в любое время.

Одна из наших основных целей состоит в том, чтобы продолжить работать в согласии со стандартом SQL, но не жертвуя скоростью или надежностью. Мы не боимся добавить расширения к SQL или поддержку особенностей не-SQL, если это очень увеличивает удобство и простоту использования MySQL для большого сегмента нашей пользовательской базы. Интерфейс HANDLER тому пример, см. раздел 14.2.4.

Мы продолжаем поддерживать транзакционные и нетранзакционные базы данных, чтобы удовлетворить и 24/7 использование для решения ответственных задач, и тяжелые Web-нагрузки или использование журналирования.

MySQL Server был первоначально разработан, чтобы работать с базами данных среднего размера (10-100 миллионов строк или приблизительно 100 МБ на таблицу) на маленьких компьютерных системах. Сегодня MySQL Server обрабатывает базы данных размера терабайта, но код может также быть собран в уменьшенной версии, подходящей для карманных и встроенных устройств. Компактный дизайн сервера MySQL делает развитие в обоих направлениях возможным без любых конфликтов в исходном дереве.

Мы не предназначаемся для поддержки в реальном времени, хотя способности репликации MySQL предлагают существенную функциональность.

MySQL поддерживает ODBC level 0 до 3.51.

MySQL поддерживает высоконадежную кластеризацию базы данных, используя NDBCLUSTER. См. MySQL Cluster NDB 7.5.

Мы осуществляем функциональность XML, которая поддерживает большинство W3C XPath. См. раздел 13.11.

Выбор режима SQL

MySQL может работать в различных режимах SQL и применить эти режимы по-другому для различных клиентов, в зависимости от значения sql_mode. DBA может установить глобальный режим SQL, чтобы соответствовать эксплуатационным требованиям сайта, и каждое приложение может установить свой сеансовый режим SQL.

Режимы затрагивают синтаксис SQL и подтверждение правильности данных. Это облегчает использование MySQL в различных средах и использование MySQL вместе с другими серверами базы данных.

См. раздел 6.1.8.

Запуск MySQL в режиме ANSI

Для запуска MySQL Server в режиме ANSI, запустите mysqld с опцией --ansi. Выполнение сервера в режиме ANSI является тем же самым, как запуск со следующими опциями:

--transaction-isolation=SERIALIZABLE --sql-mode=ANSI
Чтобы достигнуть того же самого эффекта во время выполнения, выполните эти два запроса:
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET GLOBAL sql_mode = 'ANSI';
Вы можете видеть, что установка sql_mode в 'ANSI' включает все опции режима SQL, которые важны для режима ANSI следующим образом:
mysql> SET GLOBAL sql_mode='ANSI';
mysql> SELECT @@global.sql_mode;
    ->        'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ANSI'
Выполнение сервера в режиме ANSI с --ansi не совсем то же самое, как установка режима SQL в 'ANSI', поскольку опция --ansi также устанавливает операционный уровень изоляции.

См. раздел 6.1.4.

1.8.1. Расширения MySQL к стандартному SQL

MySQL Server поддерживает некоторые расширения, которые Вы, вероятно, не будете находить в других SQL DBMS. Будьте предупреждены, что, если Вы используете их, Ваш код не будет переносим к другим SQL-серверам. В некоторых случаях, Вы можете написать код, который включает расширения MySQL, но все еще переносим при использовании комментариев следующей формы:

/*! MySQL-specific code */
В этом случае MySQL Server разбирает и выполняет код в пределах комментария, как это был бы, любой другой запрос SQL, но другие SQL-серверы проигнорирует расширения. Например, MySQL Server признает ключевое слово STRAIGHT_JOIN в следующем запросе, но другие серверы не будут:
SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...
Если Вы добавляете номер версии после !, синтаксис в пределах комментария выполнен, только если версия MySQL больше или равна указанному номеру версии. KEY_BLOCK_SIZE в следующем комментарии выполнен только серверами MySQL 5.1.10 или выше:
CREATE TABLE t1(a INT, KEY (a)) /*!50110 KEY_BLOCK_SIZE=1024 */;
Следующие описания перечисляют расширения MySQL, организованные по категориям.

1.8.2. Отличия MySQL от стандартного SQL

Мы пытаемся заставить MySQL Server следовать стандартам ANSI SQL и ODBC SQL, но MySQL Server выполняет операции по-другому в некоторых случаях:

1.8.2.1. Различия в SELECT INTO TABLE

MySQL Server не поддерживает в SELECT ... INTO TABLE расширения Sybase SQL. MySQL Server стандартный синтаксис SQL INSERT INTO ... SELECT, который является в основном той же самой вещью. См. раздел 14.2.5.1:

INSERT INTO tbl_temp2 (fld_id)
       SELECT tbl_temp1.fld_order_id
              FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
Альтернативно, Вы можете использовать SELECT ... INTO OUTFILE или CREATE TABLE ... SELECT.

Вы можете использовать SELECT ... INTO с определяемыми пользователем переменными. Тот же самый синтаксис может также использоваться в сохраненных подпрограммах, используя курсоры и местные переменные. См. раздел 14.2.9.1.

1.8.2.2. Разница в UPDATE

Если Вы получаете доступ к столбцу от таблицы, которая будет обновлена в выражении, UPDATE использует текущее значение столбца. Второе назначение в следующих запросах установит col2 в текущее (уже обновленное) значение col1, а не к исходному значению col1. Результат: col1 и col2 имеют то же самое значение. Это поведение отличается от стандартного SQL.

UPDATE t1 SET col1 = col1 + 1, col2 = col1;

1.8.2.3. Различия во внешних ключах

Выполнение MySQL внешних ключей отличается от стандарта SQL в следующих ключевых моментах:

См. раздел 16.8.6.

1.8.2.4. '--' как комментарий

Стандартный SQL использует синтаксис C /* this is a comment */ для комментариев, и MySQL Server поддерживает этот синтаксис также. MySQL также поддерживают расширения к этому синтаксису, которые позволяют MySQL-определенному SQL быть встроенным в комментарий, как описано в разделе 10.6.

Стандартный SQL использует -- как последовательность начала комментария. MySQL Server применяет # как символ начала комментария. MySQL Server также понимает разновидность -- стиля комментария. Таким образом, последовательность -- должна сопровождаться пробелом (или символом управления, таким как новая строка). Пробел обязан предотвращать проблемы с автоматически произведенными запросами SQL, которые используют такие конструкции, где мы автоматически вставляем значение, например:

UPDATE account SET credit=credit-payment
Рассмотрите, что происходит, если payment имеет отрицательную величину, например, -1:
UPDATE account SET credit=credit--1
credit--1 допустимое выражение в SQL, но -- интерпретируется как запуск комментария, и от части выражения отказываются. Результат: запрос, у которого есть абсолютно иное значение, чем надо:
UPDATE account SET credit=credit
Запрос не вызывает изменения в значении вообще. Это иллюстрирует что, разрешая начинать комментарии с -- можно поиметь серьезные последствия.

Используя наше выполнение, нужен пробел после --, чтобы это было признано как последовательность комментария в MySQL Server. Поэтому, credit--1 безопасно использовать.

Другая безопасная особенность: mysql игнорирует строки, которые начинаются с --.

1.8.3. Соглашения MySQL с ограничениями

MySQL позволяет Вам работать и с транзакционными таблицами, которые разрешают отмену, и с нетранзакционными таблицами, которые этого не делают. Из-за этого обработка ограничения немного отличается в MySQL. Мы должны обработать случай, когда Вы вставили или обновили много строк в нетранзакционную таблицу, для которой они не могут быть отменены до прежнего уровня изменения, когда ошибка происходит.

Основная философия: MySQL Server пытается произвести ошибку для чего-либо, что он может обнаружить, разбирая запрос, который будет выполнен, и пытается оправиться от любых ошибок, которые происходят, выполняя запрос.

Опции MySQL, когда ошибка происходит, должны остановить запрос в середине или исправить как возможно проблему и продолжить. По умолчанию сервер следует последним вариантом. Это означает, например, что сервер может привести недопустимые значения к самым близким допустимым значениям.

Несколько опций режима SQL доступны, чтобы обеспечить большее управление обработкой значений неправильных данных и продолжить выполнение запроса или аварийно прекратить работы, когда ошибки происходят. Используя эти опции, Вы можете сконфигурировать MySQL Server, чтобы действовать более традиционным способом, который походит на другие DBMS, которые отклоняют неподходящий ввод. Режим SQL может быть установлен глобально при запуске сервера, чтобы затронуть всех клиентов. Отдельные клиенты могут установить режим SQL во время выполнения, что позволяет каждому клиенту выбрать поведение, самое подходящее для его требований. См. раздел 6.1.8 .

Следующие разделы описывают, как MySQL Server обрабатывает различные типы ограничений.

1.8.3.1. Ограничения PRIMARY KEY и UNIQUE Index

Обычно ошибки происходят для запросов изменения данных (например, INSERT или UPDATE), которые нарушили бы первичный ключ, уникальный ключ или ограничения внешнего ключа. Если Вы используете такой механизм хранения, как InnoDB, MySQL автоматически откатывает запрос до прежнего уровня. Если Вы используете нетранзакционный механизм хранения, MySQL прекращает обрабатывать запрос на строке, для которой ошибка произошла, и оставляет любые остающиеся строки необработанными.

MySQL понимает ключевое слово IGNORE в INSERT, UPDATE и т.д. Если Вы используете это, MySQL игнорирует первичный ключ или уникально-ключевые нарушения и продолжает обрабатывать следующую строку. См. разделы 14.2.5 и 14.2.11.

Вы можете получить информацию о числе строк, фактически вставленных или обновленных функцией C API mysql_info()function. Вы можете также использовать SHOW WARNINGS, см. разделы 25.8.7.36 и 14.7.5.40.

Только таблицы InnoDB поддерживают внешние ключи. См. раздел 16.8.6.

1.8.3.2. Ограничения FOREIGN KEY

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

MySQL понимает ссылки внешнего ключа ON UPDATE и ON DELETE в CREATE TABLE и ALTER TABLE. Доступные действия: RESTRICT (значение по умолчанию), CASCADE, SET NULL и NO ACTION.

SET DEFAULT также поддержан MySQL Server , но в настоящее время отклоняется как недопустимый InnoDB. Так как MySQL не поддерживает задержанную проверку ограничений, NO ACTION обработан как RESTRICT. Для точного синтаксиса, поддержанного MySQL для внешних ключей, см. раздел 14.1.15.3.

MATCH FULL, MATCH PARTIAL и MATCH SIMPLE позволены, но их использования нужно избежать, поскольку они заставляют MySQL Server игнорировать любой ON DELETE или ON UPDATE, который используется в том же самом запросе. MATCH не имеют никакого эффекта в MySQL, который в действительности проводит в жизнь MATCH SIMPLE.

MySQL требует, чтобы столбцы внешнего ключа были индексированы: если Вы составляете таблицу с ограничением внешнего ключа, но не индексируете на данном столбце, индекс создается.

Вы можете получить информацию о внешних ключах от таблицы INFORMATION_SCHEMA.KEY_COLUMN_USAGE. Пример запроса из этой таблицы:

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME
     >        FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
     >        WHERE REFERENCED_TABLE_SCHEMA IS NOT NULL;
+--------------+---------------+-------------+-----------------+
| TABLE_SCHEMA | TABLE_NAME    | COLUMN_NAME | CONSTRAINT_NAME |
+--------------+---------------+-------------+-----------------+
| fk1          | myuser        | myuser_id   | f               |
| fk1          | product_order | customer_id | f2              |
| fk1          | product_order | product_id  | f1              |
+--------------+---------------+-------------+-----------------+
3 rows in set (0.01 sec)
Информация о внешних ключах в InnoDB может также быть найдена в таблицах INNODB_SYS_FOREIGN и INNODB_SYS_FOREIGN_COLS в INFORMATION_SCHEMA.

Только InnoDB поддерживают внешние ключи. См. раздел 16.8.6.

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

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

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

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

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

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

SET sql_mode = 'STRICT_TRANS_TABLES';
SET sql_mode = 'STRICT_ALL_TABLES';
STRICT_TRANS_TABLES включает строгий режим для транзакционных механизмов хранения, а также до некоторой степени для нетранзакционных механизмов. Это работает так:

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

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

1.8.3.4. Ограничения ENUM и SET

ENUM и SET обеспечивают эффективный способ определить столбцы, которые могут содержать только данный набор значений. См. разделы 12.4.4 и 12.4.5.

Со строгим включенным режимом (см. раздел 6.1.8), определение ENUM или SET действует как ограничение на значения. Ошибка происходит для значений, которые не удовлетворяют этим условиям:

Ошибки для недопустимых значений могут быть подавлены в строгом режиме, если Вы используете INSERT IGNORE или UPDATE IGNORE. В этом случае предупреждение произведено, а не ошибка. Для ENUM значение вставлено как ошибочный член (0). Для SET значение вставлено как дано за исключением того, что удалены любые недопустимые подстроки. Например, 'a,x,b,y' станет 'a,b'.

1.9. Благодарности

Следующие разделы перечисляют разработчиков, спонсоров и сторонников, которые помогли сделать MySQL.

1.9.1. Спонсоры MySQL

Хотя Oracle Corporation и/или ее филиалам принадлежат все авторские права в MySQL server и MySQL manual, мы хотим признать тех, кто сделал вклады в MySQL distribution. Спонсоры перечислены здесь, в несколько случайном порядке:

Другие помощники, оталдчики и тестеры: James H. Thompson, Maurizio Menghini, Wojciech Tryc, Luca Berra, Zarko Mocnik, Wim Bonis, Elmar Haneke, < jehamby@lightside>, <psmith@BayNetworks.com >, <duane@connect.com.au> , Ted Deppner <ted@psyber.com>, Mike Simons, Jaakko Hyvatti.

Много отчетов об ошибках/исправлений от людей в списке рассылки.

Большая благодарность тем, кто помогает нам ответить на вопросы в списках рассылки MySQL:

1.9.2. Documenters и переводчики

Следующие люди помогли нам с написанием документации MySQL и преобразованием документации или сообщений об ошибках в MySQL.

1.9.3. Пакеты и поддержка MySQL

The following is a list of creators/maintainers of some of the most important API/packages/applications that a lot of people use with MySQL.

We cannot list every possible package here because the list would then be way to hard to maintain. For other packages, please refer to the software portal at http://solutions.mysql.com/software/.

1.9.4. Утилиты, которыми создавался MySQL

The following is a list of some of the tools we have used to create MySQL. We use this to express our thanks to those that has created them as without these we could not have made MySQL what it is today.

1.9.5. Поддержка MySQL

Хотя Oracle Corporation и/или ее филиалам принадлежат все авторские права в MySQL server и MySQL manual, мы хотим признать следующие компании, которые помогли нам финансировать развитие MySQL server, платя нам за то, что мы развили новую особенность или дали нам аппаратные средства для развития MySQL server .