RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
YandexMoney: 
41001198119846 
E-gold:
5128052

Глава 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/.

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

  • Для обсуждения способностей сервера базы данных MySQL см. раздел 1.3.2.

  • Для краткого обзора новых особенностей MySQL см. раздел 1.4.
  • Для инструкций по установке см. главу 2. Для информации об обновлении MySQL см. раздел 2.10.1.
  • Для учебного введения в сервер базы данных MySQL, см. главу 4.
  • Для информации о конфигурировании и управлении сервером MySQL см. главу 6.
  • Для информации о безопасности в MySQL см. главу 7.
  • Для информации об установке серверов репликации см. главу 19.
  • Для информации о MySQL Enterprise, коммерческом выпуске MySQL с расширенными функциями и инструментами управления см. главу 27.
  • Для ответов на многие вопросы, которые часто задают относительно сервера базы данных MySQL и его способностей см. приложение A .
  • Для истории новых особенностей и исправлений ошибок см. Release Notes.

Чтобы сообщить о проблемах или ошибках, пожалуйста, используйте инструкции в разделе 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. Соглашения о синтаксисе в руководстве

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

  • Текст в стиле используется для запросов SQL, имен баз данных, таблиц и столбцов, программ, исходных кодов и переменных окружения. Пример: Чтобы перезагрузить таблицы привилегий, используйте FLUSH PRIVILEGES.

  • Текст в этом стиле указывает на ввод, который Вы вводите в примерах.
  • Текст в этом стиле указывает на названия выполнимых программ и скриптов, примеры применения mysql (клиента MySQL) и сервера mysqld .
  • Текст в этом стиле используется для переменного ввода, который Вы должны заменить значением своего собственного выбора.
  • Текст в этом стиле используется для акцента.
  • Текст в этом стиле используется в табличных заголовках и чтобы передать особенно сильный акцент.
  • Текст в этом стиле используется, чтобы указать на опцию программы, которая затрагивает, как программа выполнена, или предоставляет информацию, которая необходима для программы, чтобы функционировать определенным способом. Пример: Опция --host (краткая форма -h) говорит, чтобы mysql использовал имя узла или IP-адрес сервера MySQL, с которым соединяться .
  • Имена файла и имена каталогов написаны так: глобальный файл my.cnf расположен в каталоге /etc.
  • Символьные последовательности написаны так: чтобы определить подстановочный знак, используйте символ % .

Когда показывают команды, которые предназначаются, чтобы выполнить изнутри особой программы, подсказка, показанная перед командой, указывает, которую программу использовать. Например, 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 система управления базами данных.

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

  • Базы данных MySQL реляционны.

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

    SQL-часть MySQL выдерживает Structured Query Language. SQL наиболее распространенный стандартизированный язык, используемый, чтобы получить доступ к базам данных. В зависимости от Вашей программной среды, Вы могли бы ввести SQL непосредственно (например, чтобы произвести отчеты), встроить запросы SQL в код, написанный на другом языке, или использовать определенный для языка API, который скрывает синтаксис SQL.

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

  • MySQL Open Source.

    Open Source подразумевает, что для любого возможно использовать и изменить программное обеспечение. Любой может загрузить программное обеспечение MySQL из Интернета и использовать это, не платя ничего. Если Вы желаете, Вы можете изучить исходный код и изменить его, чтобы удовлетворить Вашим потребностям. Программное обеспечение MySQL использует GPL (GNU General Public License), http://www.fsf.org/licenses/, чтобы определить то, что Вы можете и не можете сделать с программным обеспечением в различных ситуациях. Если Вы чувствуете себя неловко из-за GPL или должны встроить код MySQL в коммерческое применение, Вы можете купить коммерчески имеющую лицензию версию. См. http://www.mysql.com/company/legal/licensing/.

  • MySQL очень быстр, надежен, масштабируем и удобен .

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

    MySQL Server был первоначально развит, чтобы обработать большие базы данных намного быстрее, чем существующие решения и успешно использовался в очень требовательных производственных средах в течение нескольких лет. Хотя и пребывает в постоянной разработке, MySQL сегодня предлагает богатый и полезный набор функций. Связь, скорость и безопасность делают MySQL чрезвычайно подходящим для того, чтобы получить доступ к базам данных в Интернете.

  • MySQL Server работает в системах клиент-сервер или во встроенных системах.

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

    Мы также обеспечиваем MySQL Server как встроенную мультипоточную библиотеку, которую Вы можете встроить в свое приложение, чтобы получить быстрый автономный продукт.

  • Большое количество внесенного программного обеспечения MySQL доступно.

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

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

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

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

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

  • Написан на C и C++.

  • Проверен с широким диапазоном различных компиляторов.
  • Работает под многими различными платформами. См. http://www.mysql.com/support/supportedplatforms/database.html .
  • Для мобильности использован CMake в MySQL 5.5 и выше. Предыдущие серии используют GNU Automake, Autoconf и Libtool.
  • Проверен с Purify (коммерческий датчик утечки памяти) и с Valgrind, GPL инструмент ( http://developer.kde.org/~sewardj/).
  • Использует многослойный проект сервера с независимыми модулями.
  • Разработан, чтобы быть полностью мультипоточным, используя ядерные потоки, легко использовать многократные центральные процессоры, если они доступны.
  • Обеспечивает транзакционные и нетранзакционные механизмы хранения.
  • Использует очень быстрые дисковые таблицы B-дерева (MyISAM) со сжатием индексов.
  • Разработан, чтобы сделать относительно легким добавление других механизмов хранения. Это полезно, если Вы хотите обеспечить интерфейс SQL для внутренней базы данных.
  • Использует очень быструю основанную на потоке систему распределения памяти.
  • Выполняет очень быстрые соединения, используя оптимизированное соединение.
  • Хэш-таблицы в памяти, которые используются в качестве временных таблиц.
  • Функции SQL используют чрезвычайно оптимизированную библиотеку классов, которая должна работать с такой скоростью, как возможно. Обычно нет никакого распределения памяти вообще после инициализации запроса.
  • Обеспечивает сервер как отдельную программу для использования в сетевой окружающей среде клиент-сервер и как библиотеку, которая может быть встроена в автономные приложения. Такие приложения могут быть использованы в изоляции или в окружающей среде, где никакая сеть недоступна.

Типы данных

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

  • Полная поддержка операторов и функций в SELECT и WHERE:

    mysql> SELECT CONCAT(first_name, ' ', last_name)
        ->        FROM citizen
        ->        WHERE income/dependents > 10000 AND age > 30;
    
  • Полная поддержка SQL GROUP BY и ORDER BY. Поддержка групповых функций ( COUNT(), AVG(), STD(), SUM(), MAX(), MIN() и GROUP_CONCAT()).
  • Поддержка LEFT OUTER JOIN и RIGHT OUTER JOIN со стандартным SQL и с синтаксисом ODBC.
  • Поддержка псевдонимов на таблицах и столбцах как требуется стандартным SQL.
  • Поддержка DELETE, INSERT, REPLACE и UPDATE, чтобы возвратить число строк, которые были изменены (затронуты) или возвратить вместо этого число соответствующих строк, устанавливая флаг, соединяясь с сервером.
  • Поддержка MySQL-определенноых команд SHOW, которые получают информацию о базах данных, механизмах хранения, таблицах и индексах. Поддержка INFORMATION_SCHEMA, осуществленная согласно стандартному SQL.
  • Команда EXPLAIN, чтобы показать, как оптимизатор решает запрос.
  • Независимость имен функций от имен таблиц или имен столбцов. Например, ABS допустимое имя столбца. Единственное ограничение: для вызова функции никакие пробелы не разрешены между именем функции и (. См. раздел 10.3.
  • Вы можете обратиться к таблицам от различных баз данных в том же самом запросе.

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

  • Система привилегии и паролей, которая очень гибка и безопасна.

  • Безопасность пароля с шифрованием всего трафика, когда Вы соединяетесь с сервером.

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

  • Поддержка больших баз данных. Мы используем MySQL Server с базами данных, которые содержат 50 миллионов записей. Мы также знаем о пользователях, которые используют MySQL Server с 200000 таблиц и около 5000000000 строк.

  • Поддержка 64 индексов на таблицу. Каждый индекс может состоять из 1-16 столбцов или части столбцов. Максимальный размер индекса 767 для InnoDB или 1000 для MyISAM. Индексирование может использовать приставку столбца для типов CHAR, VARCHAR, BLOB или TEXT.

Связь

  • Клиенты могут соединиться с MySQL Server, используя несколько протоколов:

    • Клиенты могут соединиться с использованием TCP/IP на любой платформе.

    • В Windows клиенты могут соединиться с использованием именованных каналов, если сервер запущен с --enable-named-pipe. Серверы Windows также поддерживают соединения совместно используемой памяти, если запущены с опцией --shared-memory. Клиенты могут соединиться через совместно используемую память при использовании опции --protocol=memory.
    • В Unix клиенты могут соединиться через файлы сокета Unix.

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

  • API для C, C++, Eiffel, Java, Perl, PHP, Python, Ruby и Tcl доступны, позволяя клиентам MySQL быть написанными на многих языках. См. главу 25.
  • Connector/ODBC (MyODBC) интерфейс оказывает поддержку MySQL для программ клиента, которые используют ODBC (Open Database Connectivity). Например, Вы можете использовать MS Access, чтобы соединиться с Вашим сервером MySQL. Клиенты могут быть выполнены в Windows или Unix. Источник Connector/ODBC доступен. Все функции ODBC 2.5 поддержаны, как многие другие. См. MySQL Connector/ODBC Developer Guide.
  • Connector/J оказывает поддержку MySQL для программ Java, которые используют соединения JDBC. Клиенты могут быть выполнены в Windows или Unix. Источник Connector/J доступен. См. MySQL Connector/J 5.1 Developer Guide.
  • MySQL Connector/Net позволяет разработчикам легко создать .NET-приложения, которые требуют безопасной, высокоэффективной связи данных с MySQL. Это осуществляет необходимое взаимодействие ADO.NET через интерфейс и объединяется в ADO.NET aware tools. Разработчики могут создать приложения, используя их выбор .NET языков. MySQL Connector/Net полностью управляется драйвером ADO.NET, написанным 100% на C#. См. MySQL Connector/Net Developer Guide.

Локализация

  • Сервер может предоставить сообщения об ошибках клиентам на многих языках. См. раздел 11.2.

  • Полная поддержка нескольких различных наборов символов, включая latin1 (cp1252), german, big5, ujis, несколько наборов символов Unicode. Например, скандинавские символы ц╔, ц╓ и ц╤ разрешены в именах таблиц и именах столбцов.
  • Все данные сохранены в выбранном наборе символов.
  • Сортировка и сравнения сделаны согласно выбранному набору символов и сопоставлению (latin1 и шведское сопоставление использованы по умолчанию). Возможно изменить это, когда сервер MySQL запущен. Чтобы видеть пример очень усовершенствованной сортировки, посмотрите на чешский код сортировки. Сервер MySQL поддерживает много различных наборов символов, которые могут быть определены во время компиляции и выполнения.
  • Часовой пояс сервера может быть изменен динамически, и отдельные клиенты могут определить свой собственный часовой пояс. См. раздел 11.6.

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

  • MySQL включает несколько клиентов и утилит. Они включают программы командной строки, такие как mysqldump и mysqladmin, и графические программы, такие как MySQL Workbench.

  • У MySQL Server есть встроенная поддержка проверки запросов SQL, оптимизации и ремонта таблиц. Эти запросы доступны из командной строки через mysqlcheck . MySQL также включает очень быструю утилиту командной строки myisamchk, для того, чтобы выполнить эти операции на MyISAM, см. главу 5.
  • Программы MySQL могут быть вызваны с опцией --help или -?, чтобы получить помощь онлайн.

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 Server теперь включает словарь данных, который хранит информацию об объектах базы данных. В предыдущих выпусках MySQL данные словаря хранились в метафайлах с данными и нетранзакционных таблицах.

      InnoDB продолжает использовать его собственный словарь данных в MySQL 8.0.0.

      См. главу 15.

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

  • Улучшения InnoDB. Эти улучшения были добавлены:

    • Текущее максимальное значение счетчика автоинкремента написано в журнал redo каждый раз при изменении значения, и это сохранено в частной для механизма системной таблице на каждой контрольной точке. Эти изменения делают текущее максимальное значение счетчика автоинкремента постоянным при перезапусках сервера. Дополнительно:

      • Перезапуск сервера больше не отменяет эффект опции AUTO_INCREMENT = N. Если Вы инициализируете автоинкремент с определенным значением или если Вы изменяете счетчик автоинкремента к большему значению, новое значение сохранено через перезапуски сервера.

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

      См. раздел 16.8.5 и InnoDB AUTO_INCREMENT Counter Initialization.

    • Когда индексное дерево повреждено, InnoDB пишет флаг повреждения в журнал redo, который делает флаг повреждения безопасным от катастрофического отказа. InnoDB также пишет данные о флаге повреждения в памяти частной для механизма системной таблице на каждой контрольной точке. Во время восстановления InnoDB читает флаги повреждения от местоположений и результатов слияний прежде, чем отметить таблицу в памяти и индексированные объекты как поврежденные.
    • Плагин InnoDB memcached поддерживает многократные вызовы get (получение многократных пар ключа/значения в единственном запросе memcached) и запросах диапазона. См. раздел 16.19.4 .
    • Новый динамический параметр конфигурации innodb_deadlock_detect используется, чтобы отключить обнаружение тупика. На системах высокой степени параллелизма обнаружение тупика может вызвать замедление, когда многочисленные потоки ждут той же самой блокировки. Время от времени, может быть более эффективно отключить обнаружение тупика и положиться на innodb_lock_wait_timeout для операционной отмены, когда тупик происходит.
    • Новая таблица INNODB_CACHED_INDEXES в INFORMATION_SCHEMA сообщает число индексных страниц, кэшируемых в буферном пуле InnoDB для каждого индекса.
    • Все временные таблицы InnoDB теперь составлены в совместно используемом временном табличном пространстве ibtmp1.

  • Улучшения JSON. Следующие улучшения или дополнения были сделаны к функциональности MySQL JSON:

    • Добавлен ->> оператор, который эквивалентен запросу JSON_UNQUOTE() на результате JSON_EXTRACT() .

      Это обработка оператора пути столбца ->, введенныого в MySQL 5.7, col->>"$.path" аналогично JSON_UNQUOTE(col->"$.path"). Действующий оператор пути может использоваться везде, где Вы можете использовать JSON_UNQUOTE(JSON_EXTRACT()), например, в списках столбцов SELECT, WHERE и HAVING, ORDER BY и GROUP BY, см. раздел 13.16.6.

      Этот оператор осуществлен в MySQL 8.0.0.

    • Добавлены две агрегатные функции JSON_ARRAYAGG() и JSON_OBJECTAGG() . JSON_ARRAYAGG() берет столбец или выражение как параметр и соединяет результат как один массив JSON . Выражение может быть приведено к любому типу данных MySQL, это не должно быть значением JSON. JSON_OBJECTAGG() берет два столбца или выражения, которые это интерпретирует как ключ и значение, это возвращает результат как объект JSON. См. раздел 13.19.

      Эти функции доступны с MySQL 8.0.1.

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

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

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

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

  • Словарь данных предоставляет информацию об объектах базы данных, таким образом, сервер больше не проверяет имена каталогов в каталоге данных, чтобы найти базы данных. Следовательно, переменные --ignore-db-dir и ignore_db_dirs являются посторонними и были удалены.

  • Переменная sync_frm удалена потому, что файлы .frm стали устаревшими.
  • В MySQL 5.7 несколько пространственных функций, доступных под многими именами, устарели, чтобы измениться в направлении создания пространственного функционального и последовательного пространства имен. Теперь каждое имя пространственной функции начинается с ST_, если это выполняет точную работу, или с MBR, если это выполняет работу, основанную на минимальных ограничительных прямоугольниках. В MySQL 8.0 устаревшие функции удалены, чтобы оставить только функции соответствующие ST_ и MBR:

    • Эти функции удалены в пользу MBR-имен: Contains(), Disjoint(), Equals(), Intersects(), Overlaps(), Within().

    • Эти функции удалены в пользу ST_-имен: Area(), AsBinary(), AsText(), AsWKB(), AsWKT(), Buffer(), Centroid(), ConvexHull(), Crosses(), Dimension(), Distance(), EndPoint(), Envelope(), ExteriorRing(), GeomCollFromText(), GeomCollFromWKB(), GeomFromText(), GeomFromWKB(), GeometryCollectionFromText(), GeometryCollectionFromWKB(), GeometryFromText(), GeometryFromWKB(), GeometryN(), GeometryType(), InteriorRingN(), IsClosed(), IsEmpty(), IsSimple(), LineFromText(), LineFromWKB(), LineStringFromText(), LineStringFromWKB(), MLineFromText(), MLineFromWKB(), MPointFromText(), MPointFromWKB(), MPolyFromText(), MPolyFromWKB(), MultiLineStringFromText(), MultiLineStringFromWKB(), MultiPointFromText(), MultiPointFromWKB(), MultiPolygonFromText(), MultiPolygonFromWKB(), NumGeometries(), NumInteriorRings(), NumPoints(), PointFromText(), PointFromWKB(), PointN(), PolyFromText(), PolyFromWKB(), PolygonFromText(), PolygonFromWKB(), SRID(), StartPoint(), Touches(), X(), Y().
    • GLength() заменена на ST_Length().

  • Клиентские опции --ssl и --ssl-verify-server-cert удалены, используйте --ssl-mode=REQUIRED вместо --ssl=1 или --enable-ssl. Используйте --ssl-mode=DISABLED вместо --ssl=0, --skip-ssl или --disable-ssl. Используйте --ssl-mode=VERIFY_IDENTITY вместо --ssl-verify-server-cert. Серверная опция --ssl остается неизменной.

    Для C API опции MYSQL_OPT_SSL_ENFORCE и MYSQL_OPT_SSL_VERIFY_SERVER_CERT в mysql_options() соответствуют клиентским --ssl и --ssl-verify-server-cert и удалены. Используйте MYSQL_OPT_SSL_MODE со значением опции SSL_MODE_REQUIRED или SSL_MODE_VERIFY_IDENTITY.

  • Функция C API mysql_shutdown() и соответствующая команда протокола клиент-сервер COM_SHUTDOWN была удалена. Вместо этого используйте mysql_query(), чтобы выполнять SHUTDOWN.
  • Сервер больше не выполняет преобразование имен базы данных pre-MySQL 5.1, содержащих специальные символы к формату 5.1 с добавлением префикса #mysql50#. Поскольку эти преобразования больше не выполнены, опции --fix-db-names и --fix-table-names для mysqlcheck , параметр UPGRADE DATA DIRECTORY NAME для ALTER DATABASE и переменная состояния Com_alter_db_upgrade удалены.

    Обновления поддержаны только от одной главной версии до другой (например, 5.0 к 5.1, или 5.1 к 5.5), таким образом должна быть небольшая остающаяся потребность в преобразовании более старых имен базы данных 5.0 к текущим версиям MySQL. Как обходное решение, обновите MySQL 5.0 до MySQL 5.1 прежде, чем обновить до более свежего выпуска.

  • mysql_install_db удалена. Инициализация каталога данных должна быть выполнена, вызывая mysqld с опцией --initialize или --initialize-insecure. Кроме того, опция --bootstrap для mysqld, которая управляла местоположением установки для mysql_install_db и опция INSTALL_SCRIPTDIR для CMake удалены.
  • Родовой обработчик разделения был удален из сервера MySQL. Чтобы поддержать разделение данной таблицы, механизм хранения, используемый для таблицы, должен теперь обеспечить свой собственный обработчик. Опции --partition и --skip-partition были удалены из MySQL Server, а связанные с разделением записи больше не показывают в выводе SHOW PLUGINS и в таблице INFORMATION_SCHEMA.PLUGINS .

    Два механизма хранения MySQL в настоящее время предоставляют поддержку разделов: InnoDB и NDB, из них только InnoDB поддержан в MySQL 8.0. Любая попытка составить разделенные таблицы в MySQL 8.0 с использованием любого другого механизма хранения терпит неудачу.

    Разветвления для обновлений. Прямое обновление разделенной таблицы, используя механизм хранения кроме InnoDB из MySQL 5.7 (или раньше) в MySQL 8.0 недопустимо. Есть две опции для того, чтобы обработать такую таблицу:

    По крайней мере одна из этих двух операций должна быть выполнена для каждой разделенной не-InnoDB таблицы до обновления сервера к MySQL 8.0. Иначе такая таблица не может использоваться после обновления.

    Вследствие того, что табличные запросы создания, которые привели бы к разделенной таблице, используя механизм хранения без соответствующей поддержки теперь терпят неудачу с ошибкой (ER_CHECK_NOT_IMPLEMENTED), Вы должны удостовериться, что любые запросы в файле дампа (например, созданном mysqldump) от более старой версии MySQL, что Вы хотите импортировать в MySQL 8.0 серверов, которые составляют разделенные таблицы, также не определяют такой механизм хранения, как MyISAM, у которого нет никакого родного обработчика разделения. Вы можете сделать это, выполняя любое из следующего:

    • Удалите любые ссылки на разделение из CREATE TABLE, которые используют значение для STORAGE ENGINE не InnoDB.

    • Определите механизм хранения как InnoDB или позвольте использовать InnoDB в качестве механизма хранения по умолчанию.

    См. раздел 20.6.2.

  • Утилита mysql_plugin удалена. Альтернативы включают загружающиеся плагины в запуск сервера, используя --plugin-load или --plugin-load-add, а также загрузку во время выполнения, используя INSTALL PLUGIN.
  • Следующие коды ошибки сервера не используются и были удалены. Должны быть обновлены приложения, которые проверяют на любую из этих ошибок.
    ER_BINLOG_READ_EVENT_CHECKSUM_FAILURE
    ER_BINLOG_ROW_RBR_TO_SBR
    ER_BINLOG_ROW_WRONG_TABLE_DEF
    ER_CANT_ACTIVATE_LOG
    ER_CANT_CHANGE_GTID_NEXT_IN_TRANSACTION
    ER_CANT_CREATE_FEDERATED_TABLE
    ER_CANT_CREATE_SROUTINE
    ER_CANT_DELETE_FILE
    ER_CANT_GET_WD
    ER_CANT_SET_GTID_PURGED_WHEN_GTID_MODE_IS_OFF
    ER_CANT_SET_WD
    ER_CANT_WRITE_LOCK_LOG_TABLE
    ER_CREATE_DB_WITH_READ_LOCK
    ER_CYCLIC_REFERENCE
    ER_DB_DROP_DELETE
    ER_DELAYED_NOT_SUPPORTED
    ER_DIFF_GROUPS_PROC
    ER_DISK_FULL
    ER_DROP_DB_WITH_READ_LOCK
    ER_DROP_USER
    ER_DUMP_NOT_IMPLEMENTED
    ER_ERROR_DURING_CHECKPOINT
    ER_ERROR_ON_CLOSE
    ER_EVENTS_DB_ERROR
    ER_EVENT_CANNOT_DELETE
    ER_EVENT_CANT_ALTER
    ER_EVENT_COMPILE_ERROR
    ER_EVENT_DATA_TOO_LONG
    ER_EVENT_DROP_FAILED
    ER_EVENT_MODIFY_QUEUE_ERROR
    ER_EVENT_NEITHER_M_EXPR_NOR_M_AT
    ER_EVENT_OPEN_TABLE_FAILED
    ER_EVENT_STORE_FAILED
    ER_EXEC_STMT_WITH_OPEN_CURSOR
    ER_FAILED_ROUTINE_BREAK_BINLOG
    ER_FLUSH_MASTER_BINLOG_CLOSED
    ER_FORM_NOT_FOUND
    ER_FOUND_GTID_EVENT_WHEN_GTID_MODE_IS_OFF__UNUSED
    ER_FRM_UNKNOWN_TYPE
    ER_GOT_SIGNAL
    ER_GRANT_PLUGIN_USER_EXISTS
    ER_GTID_MODE_REQUIRES_BINLOG
    ER_GTID_NEXT_IS_NOT_IN_GTID_NEXT_LIST
    ER_HASHCHK
    ER_INDEX_REBUILD
    ER_INNODB_NO_FT_USES_PARSER
    ER_LIST_OF_FIELDS_ONLY_IN_HASH_ERROR
    ER_LOAD_DATA_INVALID_COLUMN_UNUSED
    ER_LOGGING_PROHIBIT_CHANGING_OF
    ER_MALFORMED_DEFINER
    ER_MASTER_KEY_ROTATION_ERROR_BY_SE
    ER_NDB_CANT_SWITCH_BINLOG_FORMAT
    ER_NEVER_USED
    ER_NISAMCHK
    ER_NO_CONST_EXPR_IN_RANGE_OR_LIST_ERROR
    ER_NO_FILE_MAPPING
    ER_NO_GROUP_FOR_PROC
    ER_NO_RAID_COMPILED
    ER_NO_SUCH_KEY_VALUE
    ER_NO_SUCH_PARTITION__UNUSED
    ER_OBSOLETE_CANNOT_LOAD_FROM_TABLE
    ER_OBSOLETE_COL_COUNT_DOESNT_MATCH_CORRUPTED
    ER_ORDER_WITH_PROC
    ER_PARTITION_SUBPARTITION_ERROR
    ER_PARTITION_SUBPART_MIX_ERROR
    ER_PART_STATE_ERROR
    ER_PASSWD_LENGTH
    ER_QUERY_ON_MASTER
    ER_RBR_NOT_AVAILABLE
    ER_SKIPPING_LOGGED_TRANSACTION
    ER_SLAVE_CHANNEL_DELETE
    ER_SLAVE_MULTIPLE_CHANNELS_HOST_PORT
    ER_SLAVE_MUST_STOP
    ER_SLAVE_WAS_NOT_RUNNING
    ER_SLAVE_WAS_RUNNING
    ER_SP_GOTO_IN_HNDLR
    ER_SP_PROC_TABLE_CORRUPT
    ER_SQL_MODE_NO_EFFECT
    ER_SR_INVALID_CREATION_CTX
    ER_TABLE_NEEDS_UPG_PART
    ER_TOO_MUCH_AUTO_TIMESTAMP_COLS
    ER_UNEXPECTED_EOF
    ER_UNION_TABLES_IN_DIFFERENT_DIR
    ER_UNSUPPORTED_BY_REPLICATION_THREAD
    ER_UNUSED1
    ER_UNUSED2
    ER_UNUSED3
    ER_UNUSED4
    ER_UNUSED5
    ER_UNUSED6
    ER_VIEW_SELECT_DERIVED_UNUSED
    ER_WRONG_MAGIC
    ER_WSAS_FAILED
    
  • Таблицы INNODB_LOCKS и INNODB_LOCK_WAITS в INFORMATION_SCHEMA удалены. Используйте Performance Schema data_locks и data_lock_waits.

    В MySQL 5.7 столбец LOCK_TABLE в INNODB_LOCKS и столбец locked_table в представлениях innodb_lock_waits и x$innodb_lock_waits схемы sys содержат объединенные значения схемы/имени таблицы. В MySQL 8.0 таблица data_locks и представления схемы sys содержат отдельное имя схемы и столбцов таблицы. См. раздел 24.4.3.9.

  • InnoDB больше не сжимает временные таблицы. Когда innodb_strict_mode включен (значение по умолчанию), CREATE TEMPORARY TABLE возвращает ошибку, если указано ROW_FORMAT=COMPRESSED или KEY_BLOCK_SIZE. Если innodb_strict_mode выключен, предупреждения выпущены, и временная таблица составлена, используя несжатый формат строки.

  • InnoDB больше не создает файлы .isl (InnoDB Symbolic Link), создавая файлы с данными табличного пространства за пределами каталога данных MySQL. Записи журнала Redo теперь используются, чтобы определить местонахождение удаленных табличных пространств.

    С этим изменением, переместить отдаленное табличное пространство в то время, как сервер выключен, вручную изменяя файл .isl уже не выйдет.

  • Следующие параметры конфигурации формата файла InnoDB были удалены:

    • innodb_file_format

    • innodb_file_format_check
    • innodb_file_format_max
    • innodb_large_prefix

    Параметры конфигурации формата файла были необходимы для того, чтобы составить таблицы, совместимые с более ранними версиями InnoDB в MySQL 5.1. Теперь, когда MySQL 5.1 достиг конца своего цикла разработки, параметры больше не требуются.

    Столбец FILE_FORMAT был удален из таблиц INNODB_SYS_TABLES и INNODB_SYS_TABLESPACES в Information Schema.

  • Переменная innodb_support_xa, которая включает поддержку двухфазовой передачи в транзакциях XA, удалена. InnoDB теперь всегда это поддерживает.

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

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

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

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

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

  • Acl_cache_items_count: Число кэшируемых объектов привилегии. Добавлено в MySQL 8.0.0.

  • Com_alter_user_default_role : Счетчик запросов ALTER USER ... DEFAULT ROLE. Добавлено в MySQL 8.0.0.
  • Com_create_role: Счетчик запросов CREATE ROLE. Добавлено в MySQL 8.0.0.
  • Com_drop_role: Счетчик запросов DROP ROLE. Добавлено в MySQL 8.0.0.
  • Com_grant_roles: Счетчик запросов GRANT ROLE. Добавлено в MySQL 8.0.0.
  • Com_install_component : Счетчик запросов INSTALL COMPONENT. Добавлено в MySQL 8.0.0.
  • Com_revoke_roles: Счетчик запросов REVOKE ROLES. Добавлено в MySQL 8.0.0.
  • Com_set_role: Счетчик запросов SET ROLE. Добавлено в MySQL 8.0.0.
  • Com_uninstall_component : Счетчик запросов UINSTALL COMPONENT. Добавлено в MySQL 8.0.0.
  • information_schema_stats: Какой табличный источник статистики использовать. Добавлено в MySQL 8.0.0.
  • innodb_buffer_pool_debug: Многократные буферные экземпляры разрешены, когда буферный пул меньше, чем 1GB. Добавлено в MySQL 8.0.0.
  • performance_schema_error_size: Число инструментованных ошибок. Добавлено в MySQL 8.0.0.
  • Performance_schema_session_connect_attrs_longest_seen: Размер самого длинного допустимого атрибута соединения в буфере. Добавлено в MySQL 8.0.0.
  • persisted_globals_load: Загрузить ли сохраненные настройки конфигурации. Добавлено в MySQL 8.0.0.
  • schema_definition_cache: Определяет число объектов определения схемы, которые могут быть сохранены в кэше объекта словаря. Добавлено в MySQL 8.0.0.
  • stored_program_definition_cache: Определяет число сохраненных программ и объектов определения событий, которые могут быть сохранены в кэше объекта словаря. Добавлено в MySQL 8.0.0.
  • tablespace_definition_cache: Определяет число объектов определения табличного пространства, которые могут быть сохранены в кэше объекта словаря. Добавлено в MySQL 8.0.0.

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

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

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

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

  • bootstrap: Используется скриптами установки. Удалено в MySQL 8.0.0.

  • Com_alter_db_upgrade : Счетчик запросов ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME. Удалено в MySQL 8.0.0.
  • ignore-db-dir: Каталог обработки как каталог не базы данных. Удалено в MySQL 8.0.0.
  • ignore_db_dirs: Каталоги, обработанные как каталоги не базы данных. Удалено в MySQL 8.0.0.
  • innodb_checksums: Включить проверку допустимости контрольных сумм InnoDB. Удалено в MySQL 8.0.0.
  • innodb_disable_resize_buffer_pool_debug: Отключает изменение размеров буферного пула InnoDB. Удалено в MySQL 8.0.0.
  • innodb_file_format: Формат для новых таблиц InnoDB. Удалено в MySQL 8.0.0.
  • innodb_file_format_check: Выполняет ли InnoDB проверку совместимости формата файла. Удалено в MySQL 8.0.0.
  • innodb_file_format_max: Тег формата файла в совместно используемом табличном пространстве. Удалено в MySQL 8.0.0.
  • innodb_large_prefix: Включает ключи большей длины для приставки столбца в индексе. Удалено в MySQL 8.0.0.
  • innodb_locks_unsafe_for_binlog: Вынудить InnoDB не использовать следующую ключевую блокировку. Вместо этого используйте только блокировку на уровне строки. Удалено в MySQL 8.0.0.
  • innodb_stats_sample_pages: Число индексных страниц в образце для статистики распределения индекса. Удалено в MySQL 8.0.0.
  • innodb_support_xa: Включите поддержку двухфазовой передачи XA InnoDB. Удалено в MySQL 8.0.0.
  • partition: Включить (или отключить) поддержку разделов. Удалено в MySQL 8.0.0.
  • skip-partition: Не включать определяемые пользователем разделы. Удалено в MySQL 8.0.0.
  • sync_frm: Синхронизировать .frm с диском при создании. Включено по умолчанию. Удалено в MySQL MySQL 8.0.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 следующие:

  • announce

    Список для объявлений о новых версиях MySQL и связанных программ. Это список низкого объема, на который должны подписаться все пользователи MySQL.

  • mysql

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

  • bugs

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

  • internals

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

  • mysqldoc

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

  • benchmarks

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

  • packagers

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

  • java

    Список для дискуссий о сервере MySQL и Java. Это главным образом используется, чтобы обсудить драйверы JDBC, такие как MySQL Connector/J.

  • win32

    Список для всех тем относительно программного обеспечения MySQL на операционных системах Microsoft, таких как Windows 9x, Me, NT, 2000, XP и 2003.

  • myodbc

    Список для всех тем относительно соединения с сервером MySQL с ODBC.

  • gui-tools

    Список для всех тем относительно инструментов графического интерфейса пользователя MySQL, таких как MySQL Workbench.

  • cluster

    Список для обсуждения MySQL Cluster.

  • dotnet

    Список для обсуждения сервера MySQL и платформы .NET. Это главным образом связано с MySQL Connector/Net.

  • plusplus

    Список для всех тем относительно программирования с C++ API для MySQL.

  • perl

    Список для всех тем относительно Perl для MySQL с DBD::mysql.

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

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

  • < mysql-france-subscribe@yahoogroups.com>

    Французский список рассылки.

  • <list@tinc.net>

    Корейский список рассылки. Чтобы подписаться, надо послать по электронной почте subscribe mysql your@email.address в список.

  • < mysql-de-request@lists.4t2.com>

    Немецкий список рассылки. Чтобы подписаться, надо послать по электронной почте subscribe mysql-de your@email.address в список. Вы можете найти информацию об этом списке рассылки на http://www.4t2.com/mysql/.

  • < mysql-br-request@listas.linkway.com.br>

    Португальский список рассылки. Чтобы подписаться, надо послать по электронной почте subscribe mysql-br your@email.address в список.

  • < mysql-alta@elistas.net>

    Испанский список рассылки. Чтобы подписаться, надо послать по электронной почте subscribe mysql your@email.address в список.

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

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

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

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

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

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

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

  • Migration

  • MySQL Usage
  • MySQL Connectors
  • Programming Languages
  • Tools
  • 3rd-Party Applications
  • Storage Engines
  • MySQL Technology
  • SQL Standards
  • Business

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

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

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

  • #mysql прежде всего для вопросов о MySQL, но другие базы данных и общие вопросы SQL приветствуются. Вопросы о PHP, Perl или C в комбинации с MySQL также распространены.

  • #workbench прежде всего для вопросов, связанных с MySQL Workbench, это также хорошее место, чтобы встретить разработчиков MySQL Workbench.

Если Вы ищете клиентское программное обеспечение 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 Server.

  • MySQL Enterprise Monitor.
  • Ежемесячные быстрые обновления и ежеквартальные пакеты обновления.
  • База знаний MySQL.
  • Техническая и консультативная поддержка 24x7.

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

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

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

  • Начните с поиска в MySQL online manual на http://dev.mysql.com/doc/ . Мы пытаемся усовершенствовать руководство, обновляя это часто с решениями недавно найденных проблем. Кроме того, информация о версии, сопровождающая руководство, может быть особенно полезной, так как возможно, что более новая версия содержит решение Вашей проблемы. Информация о версии доступна вместе с руководством.

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

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

  • Для решений некоторых типичных проблем см. раздел B.5.
  • Ищите базу данных ошибок в http://bugs.mysql.com/, чтобы видеть, сообщили ли об ошибке.
  • Ищите архивы списка рассылки MySQL в http://lists.mysql.com/. См. раздел 1.6.1.
  • Вы можете также использовать http://www.mysql.com/search/, чтобы искать все Веб-страницы (включая руководство), которые расположены на Веб-сайте MySQL.

Если Вы не можете найти ответ в руководстве, базе данных ошибок или архивах списка рассылки, согласуйте со своим местным экспертом 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.

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

  • Номер версии MySQL (например, MySQL 5.7.10). Вы можете узнать, какую версию Вы выполняете, выполняя mysqladmin version . mysqladmin может быть найдена в подкаталоге bin в соответствии с Вашим каталогом установки MySQL.

  • Изготовитель и модель машины, на которой Вы испытываете проблему.
  • Имя операционной системы и версия. Если Вы работаете с Windows, Вы можете обычно узнать имя и номер версии двойным щелчком по My Computer и меню Help/About Windows. Для большинства Unix-систем Вы можете получить эту информацию, выполняя команду uname -a.
  • Иногда объем памяти (реальный и виртуальный) релевантен. Если сомневаетесь, включайте эти значения.
  • Если Вы используете дистрибутив исходных текстов MySQL, включите имя и номер версии компилятора, который Вы использовали. Если Вы имеете двоичный дистрибутив, включите его имя.
  • Если проблема происходит во время компиляции, включайте точные сообщения об ошибках, а также несколько строк контекста вокруг незаконного кода в файле, где ошибка происходит.
  • Если mysqld падает, то Вы должны также сообщить о запросе, который разрушил mysqld. Вы можете обычно получать эту информацию, выполняя mysqld с журналированием запроса, а затем смотреть в журнале после падения mysqld, см. раздел 26.5.
  • Если таблица базы данных связана с проблемой, включайте вывод SHOW CREATE TABLE db_name.tbl_name. Это очень легкий способ получить определение любой таблицы в базе данных. Информация помогает нам создать ситуацию, соответствующую той, которую Вы испытали.
  • Режим SQL, когда проблема произошла, может быть существенным, так что, пожалуйста, сообщите о значении sql_mode. Для хранимой процедуры, сохраненной функции и триггеров, соответствующее значение sql_mode, когда объект создавался. Для хранимой процедуры или функции SHOW CREATE PROCEDURE или SHOW CREATE FUNCTION показывает соответствующий режим SQL, или Вы можете запросить INFORMATION_SCHEMA:
    SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
           FROM INFORMATION_SCHEMA.ROUTINES;
    
    Для триггеров используйте:
    SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE
           FROM INFORMATION_SCHEMA.TRIGGERS;
    
  • Для связанных с работой ошибок или проблем с SELECT Вы должны всегда включать вывод EXPLAIN SELECT ... и по крайней мере число строк, которое SELECT производит. Вы должны также включать вывод SHOW CREATE TABLE tbl_name для каждой таблицы, которая вовлечена. Чем больше информации Вы предоставляете о своей ситуации, тем более вероятно, что кто-то сможет помочь Вам.

    Следующее пример очень хорошего отчета об ошибках. Запросы выполнены, используя mysql . Отметьте использование \G для запросов, которые иначе обеспечивали бы очень длинные выходные строки, которые трудно читать.

    mysql> SHOW VARIABLES;
    mysql> SHOW COLUMNS FROM ...\G
              <output from SHOW COLUMNS>
    mysql> EXPLAIN SELECT ...\G
              <output from EXPLAIN>
    mysql> FLUSH STATUS;
    mysql> SELECT ...;
              <A short version of the output from SELECT,
              including the time taken to run the query>
    mysql> SHOW STATUS;
              <output from SHOW STATUS>
    
  • Если ошибка или проблема происходят, выполняя mysqld, попытайтесь обеспечить входной скрипт, который воспроизводит аномалию. Этот скрипт должен включать любые необходимые исходные файлы. Чем более близко скрипт сможет воспроизвести Вашу ситуацию, тем лучше. Если Вы можете сделать восстанавливаемый прецедент, Вы должны загрузить это, чтобы присоединить к отчету об ошибках.

    Если Вы не можете обеспечить скрипт, Вы должны, по крайней мере, включить вывод mysqladmin variables extended-status processlist в Ваш отчет, чтобы предоставить некоторую информацию о том, как система работает.

  • Если Вы не можете произвести прецедент только с несколькими строками, или если испытательная таблица является слишком большой, чтобы быть включенной в отчет об (больше 10 строк), Вы должны вывести свои таблицы в дамп, используя mysqldump и создать файл README, который описывает Вашу проблему. Создайте сжатый архив своих файлов, используя tar и gzip или zip. После того, как Вы начинаете отчет об ошибках для нашей базы данных ошибок в http://bugs.mysql.com/, щелкните по вкладке Files в отчете об ошибках для инструкций по загрузке архива в базу данных ошибок.
  • Если Вы полагаете, что сервер MySQL производит странное следствие запроса, включайте не только результат, но также и Ваше мнение о том, чем результат должен быть, и объяснение, описывающее основание для Вашего мнения.
  • Когда Вы обеспечиваете пример проблемы, лучше использовать имена таблиц, имена переменной и т.д., которые существуют в Вашей фактической ситуации, чем придумать новые имена. Проблема могла быть связана с названием таблицы или переменной. Эти случаи редки, но лучше их отсечь сразу. В конце концов, для Вас должно быть легче обеспечить пример, который использует Вашу фактическую ситуацию и это точно лучше для нас. Если у Вас есть данные, которые Вы не хотите показывать другим в отчете об ошибках, Вы можете загрузить это используя вкладку Files, как ранее описано. Если информация действительно совершенно секретна, и Вы не хотите показывать это даже нам, обеспечьте пример, используя другие имена, но, пожалуйста, расцените это как последний выбор.
  • Включайте все опции, данные соответствующим программам, если возможно. Например, укажите на опции, которые Вы используете, когда запускаете mysqld, так же как опции, которые Вы используете, чтобы выполнить любые программы клиента MySQL. Опции таких программ, как mysqld и mysql, а также скрипта configure являются часто ключевыми к решению проблем и являются очень релевантными. Это никогда не плохая идея включать их. Если Ваша проблема вовлекает программу, написанную на таком языке, как Perl или PHP, пожалуйста, включайте номер версии, так же как версию для любых модулей, которые использует программа. Например, если у Вас есть скрипт Perl, который использует модули DBI и DBD::mysql, включайте номера версии для Perl, DBI и DBD::mysql.
  • Если Ваш вопрос связан с системой привилегии, пожалуйста, включайте вывод mysqladmin reload и все сообщения об ошибках, которые Вы получаете, пытаясь соединиться. Когда Вы проверяете свои привилегии, Вы должны выполнить mysqladmin reload version и попытаться соединиться с программой, которая дает Вам проблему.
  • Если у Вас есть патч для ошибки, включайте это. Но не предполагайте, что патч это все, в чем мы нуждаемся, или что мы можем использовать его, если Вы не предоставляете некоторую необходимую информацию, такую как прецеденты, показывая ошибку, которую исправляет Ваш патч. Мы могли бы найти проблемы с Вашим патчем или мы можем не понять это вообще. Если так, мы не можем использовать это.

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

  • Предположения о том, какова ошибка, почему происходит, или от чего это зависит, являются обычно неправильными. Даже команда MySQL не может предположить такие вещи без первого использования отладчика, чтобы определить реальную причину ошибки.
  • Укажите в своем отчете об ошибках, что Вы проверили руководство и почтовый архив так, чтобы другие знали, что Вы попытались решить проблему самостоятельно.
  • Если Ваши данные кажутся поврежденными, или Вы получаете ошибки, когда получаете доступ к особой таблице, сначала проверьте свои таблицы с помощью CHECK TABLE. Если этот запрос сообщает о каких-либо ошибках:

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

    • Для нетранзакционных таблиц, попытайтесь восстановить их с помощью REPAIR TABLE или с myisamchk. См. главу 6.

    Если Вы запускаете Windows, пожалуйста, проверьте значение lower_case_table_names с использованием SHOW VARIABLES LIKE 'lower_case_table_names'. Эта переменная затрагивает, как сервер обрабатывает регистр символов имен базы данных и имен таблиц. Его эффект для данного значения должен быть как описано в разделе 10.2.2 .

  • Если Вы часто получаете поврежденные таблицы, Вы должны попытаться узнать, когда и почему это происходит. В этом случае, журнал ошибок в каталоге данных MySQL может содержать некоторую информацию о том, что произошло. Это файл с суффиксом .err. См. раздел 6.4.2. Пожалуйста, включайте любую релевантную информацию от этого файла в Ваш отчет об ошибках. Обычно mysqld никогда не должен разрушать таблицу, если ничто не уничтожило его в середине обновления. Если Вы можете найти причину падения mysqld, для нас намного легче предоставить Вам решение для проблемы. См. раздел B.5.1.
  • Если возможно, загрузите и установите новую версию MySQL Server и проверьте, решает ли это Вашу проблему. Все версии программного обеспечения MySQL полностью проверены и должны работать без проблем. Мы верим в создание всего настолько обратно совместимого, насколько возможно, и Вы должны быть в состоянии переключить версии MySQL без труда. См. раздел 2.1.1.

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, организованные по категориям.

  • Организация данных на диске.

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

  • Общий языковой синтаксис.

    • По умолчанию строки могут быть приложены в " или в '. Если режим SQL ANSI_QUOTES включен, строки могут быть приложены только в ', а сервер интерпретирует строки, приложенные в " как идентификаторы.

    • \ символ ESC в строках.
    • В запросах SQL Вы можете получить доступ к таблицам из различных баз данных с помощью синтаксиса db_name.tbl_name. Некоторые SQL-серверы обеспечивают ту же самую функциональность, но называют это User space. MySQL Server не поддерживает такие табличные пространства, как использующееся в запросах как это: CREATE TABLE ralph.my_table ... IN my_tablespace.

  • Синтаксис запроса SQL.

  • Типы данных.

    • MEDIUMINT, SET и ENUM, а также разные BLOB и TEXT.

    • Атрибуты типа данных AUTO_INCREMENT, BINARY, NULL, UNSIGNED и ZEROFILL.

  • Функции и операторы.

    • Чтобы облегчить переход для пользователей, которые мигрируют от другой окружающей среды SQL, MySQL Server поддерживает псевдонимы для многих функций. Например, все строковые функции поддерживают стандартный синтаксис SQL и синтаксис ODBC.

    • MySQL Server понимает операторы || и &&, чтобы означать логические OR и AND, в языке C. В MySQL Server || и OR синонимы, как && и AND. Из-за этого хорошего синтаксиса MySQL Server не поддерживает стандартный оператор SQL || для строковой связи, надо использовать CONCAT(). Поскольку CONCAT() берет любое число параметров, легко преобразовать использование || для MySQL Server.
    • Использование COUNT(DISTINCT value_list), где value_list имеет больше, чем один элемент.
    • Строковые сравнения являются нечувствительными к регистру по умолчанию с упорядочиванием, определенным сопоставлением текущего набора символов, который является latin1 (cp1252 West European) по умолчанию. Если Вам не нравится это, Вы должны объявить свои столбцы с атрибутом BINARY или используйте BINARY, который заставляет сравнения быть сделанными, используя основные символьные кодовые обозначения, а не лексическое упорядочивание.
    • % синоним для MOD(). Поэтому N % M эквивалентно MOD(N,M). % поддержан для программистов C и для совместимости с PostgreSQL.
    • Операторы =, <>, <=, <, >=, >, <<, >>, <=>, AND, OR или LIKE могут использоваться в выражениях в выходном списке столбца (слева от FROM) в SELECT:
      mysql> SELECT col1=1 AND col2=2 FROM my_table;
      
    • Функция LAST_INSERT_ID() возвращает новое значение AUTO_INCREMENT , см. раздел 13.14.
    • LIKE разрешен на числовых значениях.
    • REGEXP и NOT REGEXP расширенные регулярные выражения.
    • CONCAT() или CHAR() с одним параметром или больше, чем с двумя параметрами. В MySQL эти функции могут взять переменное число параметров.
    • Функции BIT_COUNT() , CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD(), ENCRYPT(), MD5(), ENCODE(), DECODE(), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS() WEEKDAY().
    • Использование TRIM(), чтобы обрезать подстроки. Стандартный SQL поддерживает только удаление единственного символа.
    • Функции STD(), BIT_OR(), BIT_AND(), BIT_XOR() и GROUP_CONCAT() для GROUP BY. См. раздел 13.19.

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

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

  • Есть несколько различий между MySQL и стандартными системами привилегии SQL. Например, в MySQL, привилегии для таблицы автоматически не отменяются, когда Вы удаляете таблицу. Вы должны явно скомандовать REVOKE, чтобы отменить привилегии для таблицы. Для получения дополнительной информации см. раздел 14.7.1.8.

  • Функция CAST() не поддерживает приведение к REAL или BIGINT . См. раздел 13.10.

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 в следующих ключевых моментах:

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

    InnoDB выполняет располагающиеся каскадом операции через алгоритм depth-first, основанный на записях в индексах, соответствующих ограничениям внешнего ключа.

  • Ограничение FOREIGN KEY, которое ссылается на не-UNIQUE ключ, не стандартный SQL, а скорее расширение InnoDB.
  • Если ON UPDATE CASCADE или ON UPDATE SET NULL рекукрсивно, чтобы обновить ту же самую таблицу, которую это ранее обновило во время того же самого каскада, это действует как RESTRICT. Это означает, что Вы не можете использовать ссылающийся на себя ON UPDATE CASCADE или ON UPDATE SET NULL. Это должно предотвратить бесконечные циклы, следующие из каскадных обновлений. Ссылающийся на себя ON DELETE SET NULL, с другой стороны, возможно, как ON DELETE CASCADE. Расположение каскадом операций не может быть вложено больше, чем на 15 уровней.
  • В запросе SQL, который вставляет, удаляет или обновляет много строк, ограничения внешнего ключа (как уникальные ограничения) проверены построчно. Выполняя проверки внешнего ключа, InnoDB ставит совместно используемую блокировку на уровне строки на дочерних или родительских записях, которые это должно исследовать. MySQL немедленно проверяет ограничения внешнего ключа, проверка не задержана до передачи транзакции. Согласно стандарту SQL, поведение по умолчанию это задержать проверку. Таким образом, ограничения проверены только после того, как весь запрос 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 устанавливает столбец в самое лучшее по смыслу значение вместо того, чтобы произвести ошибку, следующие правила описывают более подробно, как это работает:

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

  • Для строк MySQL сохранит пустую строку или такой большой кусок строки, какой может быть сохранен в столбце.
  • Если Вы пытаетесь сохранить строку, которая не начинается с числа в числовой столбец, MySQL Server сохранит 0.
  • Недопустимые значения для ENUM и SET обработаны как описано в разделе 1.8.3.4.
  • 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 для числовых типов, пустая строка ('') для строковых типов и нулевое для типов времени и даты. Неявные значения по умолчанию обсуждены в разделе 12.7.
  • Если INSERT не определяет значения для столбца, MySQL вставляет свое значение по умолчанию, если определение столбца включает явный DEFAULT. Если у определения нет DEFAULT, MySQL вставляет неявное значение по умолчанию для типа данных столбца.

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

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

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.

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

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

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

  • ENUM должно быть одним из перечисленных в определении столбца или внутренним числовым эквивалентом этого. Значение не может быть ошибочным значением (то есть, 0 или пустая строка). Для столбца, определенного как ENUM('a','b','c'), такие значения, как '', 'd' или 'ax' недопустимы и отклонены.

  • Значение SET должно быть пустой строкой или значением, состоящим только из значений, перечисленных в определении столбца, отделенных запятыми. Для столбца, определенного как SET('a','b','c'), такое значение, как 'd' или 'a,b,c,d' недопустимо и отклонено.

Ошибки для недопустимых значений могут быть подавлены в строгом режиме, если Вы используете 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. Спонсоры перечислены здесь, в несколько случайном порядке:

  • Gianmassimo Vigazzola < qwerg@mbox.vol.it> или <qwerg@tin.it>

    Начальный порт Win32/NT.

  • Per Eric Olsson

    Для конструктивной критики и реального тестирования динамического формата записи.

  • Irena Pancirov < irena@mail.yacc.it>

    Порт Win32 с Borland compiler. mysqlshutdown.exe и mysqlwatch.exe.

  • David J. Hughes

    За усилия сделать условно-бесплатное программное обеспечение базой данных SQL. В TcX, предшественнике MySQL AB, мы начали с mSQL, но убедились, что это не могло удовлетворить наши цели. Поэтому мы написали интерфейс SQL к Unireg. mysqladmin и mysql это программы, которые были в значительной степени под влиянием mSQL. Мы приложили много сил для создания синтаксиса MySQL как спецмножество mSQL. Многие из идей API заимствованы в mSQL, чтобы сделать простым портирование программ mSQL на MySQL API. Программное обеспечение MySQL не содержит кода от mSQL. Два файла в дистрибутиве (client/insert_test.c и client/select_test.c) основаны на соответствующих (незащищенных авторским правом) файлах в mSQL, но изменены как примеры, показывая изменения, необходимые, чтобы преобразовать код из mSQL в MySQL Server. mSQL is copyrighted David J. Hughes.

  • Patrick Lynch

    Для того, чтобы помочь нам приобрести http://www.mysql.com/.

  • Fred Lindberg

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

  • Igor Romanenko < igor@frog.kiev.ua>

    mysqldump (ранее msqldump, но перенесен и улучшен Monty).

  • Yuri Dario

    Для поддержания на высоком уровне и распространения порта MySQL в OS/2.

  • Tim Bunce

    Автор mysqlhotcopy.

  • Zarko Mocnik < zarko.mocnik@dem.si>

    Сортировка для словенского языка.

  • "TAMITO" <tommy@valley.ne.jp >

    Макроопределение набора символов _MB и наборов символов ujis и sjis.

  • Joshua Chamas < joshua@chamas.com>

    Основа для параллельной вставки, расширенного синтаксиса даты, отладки под NT и ответы в списке рассылки MySQL.

  • Yves Carlier < Yves.Carlier@rug.ac.be>

    mysqlaccess, программа, чтобы показать права доступа для пользователя.

  • Rhys Jones <rhys@wales.com > (And GWE Technologies Limited)

    Для одного из ранних драйверов JDBC.

  • Dr Xiaokun Kelvin ZHU < X.Zhu@brad.ac.uk>

    Дальнейшее развитие одного из ранних драйверов JDBC и других MySQL-связанных инструментов Java.

  • James Cooper < pixel@organic.com>

    Для того, чтобы настроить доступный для поиска архив списка рассылки на его сайте.

  • Rick Mehalick < Rick_Mehalick@i-o.com>

    xmysql, графический X-клиент для MySQL Server.

  • Doug Sisk <sisk@wix.com>

    RPM-пакеты MySQL для Red Hat Linux.

  • Diemand Alexander V. < axeld@vial.ethz.ch>

    RPM-пакеты MySQL для Red Hat Linux-Alpha.

  • Antoni Pamies Olive < toni@readysoft.es>

    RPM-пакеты клиентов MySQL для Intel и SPARC.

  • Jay Bloodworth < jay@pathways.sde.state.sc.us>

    RPM-пакеты для MySQL 3.21.

  • David Sacerdote < davids@secnet.com>

    Идеи для безопасной проверки имен хоста DNS.

  • Wei-Jou Chen < jou@nematic.ieo.nctu.edu.tw>

    Некоторая поддержка китайского языка (BIG5).

  • Wei He < hewei@mail.ied.ac.cn>

    Большая функциональность для китайцев (GBK).

  • Jan Pazdziora < adelton@fi.muni.cz>

    Чешский порядок сортировки.

  • Zeev Suraski < bourbon@netvision.net.il>

    Функции FROM_UNIXTIME() , ENCRYPT() и помощь по вопросам bison. Активный участник списка рассылки.

  • Luuk de Boer <luuk@wxs.nl>

    Перенес (и расширил) эталонный набор на DBI/DBD. Большая помощь с crash-me и выполнение точек отсчета. Некоторые новые функции даты. Скрипт mysql_setpermission.

  • Alexis Mikhailov < root@medinf.chuvashia.su>

    User-defined functions (UDF), CREATE FUNCTION и DROP FUNCTION.

  • Andreas F. Bobak < bobak@relog.ch>

    Расширение AGGREGATE к определяемым пользователем функциям.

  • Ross Wakelin < R.Wakelin@march.co.uk>

    Помощь в настройке InstallShield для MySQL-Win32.

  • Jethro Wright III < jetman@li.net>

    Библиотека libmysql.dll.

  • James Pereria < jpereira@iafrica.com>

    Mysqlmanager, Win32 GUI для администрирования MySQL Server.

  • Curt Sampson <cjs@portal.ca >

    Перенес MIT-pthreads на NetBSD/Alpha и NetBSD 1.3/i386.

  • Martin Ramsch < m.ramsch@computer.org>

    Примеры в обучающей программе MySQL.

  • Steve Harvey

    Сделал mysqlaccess более безопасным.

  • Konark IA-64 Centre of Persistent Systems Private Limited

    Помощь с портом Win64 сервера MySQL.

  • Albert Chin-A-Young.

    Настройка обновления для Tru64, поддержки больших файлов и TCP wrappers.

  • John Birrell

    Эмулятор pthread_mutex() для OS/2.

  • Benjamin Pflugmann

    Расширенные таблицы MERGE, чтобы обработать INSERT. Активный член в списках рассылки MySQL.

  • Jocelyn Fournier

    Превосходное определение и сообщение о неисчислимых ошибках (особенно в коде подзапроса MySQL 4.1).

  • Marc Liyanage

    Поддержание пакетов OS X и обеспечение неоценимой обратной связи о том, как создать пакеты для OS X.

  • Robert Rutherford

    Предоставление неоценимой информации и обратной связи о порте QNX.

  • Предыдущие разработчики NDB Cluster

    Много людей было вовлечено различными способами. Всего больше 100 человек, слишком много, чтобы упомянуть здесь. Известное имя Ataullah Dabaghi, кто вплоть до 1999 внес приблизительно одну треть кодовой базы. Особая благодарность также разработчикам системы AXE, которая предоставила большую часть архитектурных фондов для NDB Cluster с блоками, сигналами и функциональностью рассмотрения катастрофического отказа. Также благодарность тем, кто верил в идеи достаточно, чтобы выделить бюджет для развития с 1992 до настоящего времени.

  • Google Inc.

    Мы хотим признать Google Inc. за вклады в распределение MySQL: Исполнительные патчи Mark Callaghan's SMP и другие патчи.

Другие помощники, оталдчики и тестеры: 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:

  • Daniel Koch < dkoch@amcity.com>

    Установка Irix.

  • Luuk de Boer <luuk@wxs.nl>

    Вопросы о точке отсчета.

  • Tim Sailer < tps@users.buoy.com>

    Вопросы о DBD::mysql.

  • Boyd Lynn Gerber < gerberb@zenez.com>

    Вопросы о SCO.

  • Richard Mehalick < RM186061@shellus.com>

    Вопросы о xmysql и основные вопросы об установке.

  • Zeev Suraski < bourbon@netvision.net.il>

    Вопросы о конфигурации модуля Apache (log & auth), PHP, синтаксисе SQL и другие.

  • Francesc Guasch < frankie@citel.upc.es>

    Общие вопросы.

  • Jonathan J Smith <jsmith@wtp.net >

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

  • David Sklar < sklar@student.net>

    MySQL с PHP и Perl.

  • Alistair MacDonald < A.MacDonald@uel.ac.uk>

    Гибкость и обработка Linux и HP-UX.

  • John Lyon < jlyon@imag.net>

    Вопросы об установке MySQL на системах Linux, используя также файлы .rpm и сборку из исходных текстов.

  • Lorvid Ltd. < lorvid@WOLFENET.com>

    Простое составление billing/license по авторскому праву.

  • Patrick Sherrill < patrick@coconet.com>

    Вопросы по интерфейсу ODBC и Visual C++.

  • Randy Harmon < rjharmon@uptimecomputers.com>

    Вопросы по DBD, Linux и SQL.

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

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

  • Paul DuBois

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

  • Kim Aldale

    Helped to rewrite Monty's and David's early attempts at English into English.

  • Michael J. Miller Jr. < mke@terrapin.turbolift.com>

    For the first MySQL manual. And a lot of spelling/language fixes for the FAQ (that turned into the MySQL manual a long time ago).

  • Yan Cailin

    First translator of the MySQL Reference Manual into simplified Chinese in early 2000 on which the Big5 and HK coded versions were based.

  • Jay Flaherty < fty@mediapulse.com>

    Большая часть раздела Perl DBI/DBD.

  • Paul Southworth < pauls@etext.org>, Ray Loyzaga <yar@cs.su.oz.au>

    Proof-reading of the Reference Manual.

  • Therrien Gilbert < gilbert@ican.net>, Jean-Marc Pouyot < jmp@scalaire.fr>

    French error messages.

  • Petr Snajdr, <snajdr@pvt.net >

    Czech error messages.

  • Jaroslaw Lewandowski < jotel@itnet.com.pl>

    Polish error messages.

  • Miguel Angel Fernandez Roiz

    Spanish error messages.

  • Roy-Magne Mo < rmo@www.hivolda.no>

    Norwegian error messages and testing of MySQL 3.21.xx.

  • Timur I. Bakeyev < root@timur.tatarstan.ru>

    Russian error messages.

  • <brenno@dewinter.com > & Filippo Grassilli <phil@hyppo.com>

    Italian error messages.

  • Dirk Munzinger < dirk@trinity.saar.de>

    German error messages.

  • Billik Stefan < billik@sun.uniag.sk>

    Slovak error messages.

  • Stefan Saroiu < tzoompy@cs.washington.edu>

    Romanian error messages.

  • Peter Feher

    Hungarian error messages.

  • Roberto M. Serqueira

    Portuguese error messages.

  • Carsten H. Pedersen

    Danish error messages.

  • Arjen Lentz

    Dutch error messages, completing earlier partial translation (also work on consistency and spelling).

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/.

  • Tim Bunce, Alligator Descartes

    For the DBD (Perl) interface.

  • Andreas Koenig < a.koenig@mind.de>

    For the Perl interface for MySQL Server.

  • Jochen Wiedmann < wiedmann@neckar-alb.de>

    For maintaining the Perl DBD::mysql module.

  • Eugene Chan < eugene@acenet.com.sg>

    For porting PHP for MySQL Server.

  • Georg Richter

    MySQL 4.1 testing and bug hunting. New PHP 5.0 mysqli extension (API) for use with MySQL 4.1 and up.

  • Giovanni Maruzzelli < maruzz@matrice.it>

    For porting iODBC (Unix ODBC).

  • Xavier Leroy < Xavier.Leroy@inria.fr>

    The author of LinuxThreads (used by the MySQL Server on Linux).

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.

  • Free Software Foundation

    From whom we got an excellent compiler (gcc), an excellent debugger (gdb and the libc library (from which we have borrowed strto.c to get some code working in Linux).

  • Free Software Foundation & The XEmacs development team

    For a really great editor/environment.

  • Julian Seward

    Author of valgrind, an excellent memory checker tool that has helped us find a lot of otherwise hard to find bugs in MySQL.

  • Dorothea Lц╪tkehaus and Andreas Zeller

    DDD (Data Display Debugger), прекрасный графический front end к gdb).

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

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

  • VA Linux / Andover.net

    Финансирование репликации.

  • NuSphere

    Редактирование MySQL.

  • Stork Design studio

    MySQL Web-сайт в 1998-2000.

  • Intel

    Развитие в Windows и Linux.

  • Compaq

    Развитие в Linux/Alpha.

  • SWSoft

    Развитие встроенной версии mysqld.

  • FutureQuest

    Опция --skip-show-database.

Поиск

 

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru