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

Содержание

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

1.2. Соглашения, используемые в данном руководстве

1.3. О русском переводе руководства

1.3.1. Список терминов, принятых в русском переводе

1.4. Что представляет собой MySQL?

1.4.1. История MySQL

1.4.2. Основные возможности MySQL

1.4.3. Насколько стабильным является MySQL?

1.4.4. Насколько большими могут быть таблицы в MySQL?

1.4.5. Вопросы, связанные с Проблемой-2000

1.5. Что представляет собой компания MySQL AB?

1.5.1. Бизнес-модель и услуги, оказываемые компанией MySQL AB

1.5.2. Как с нами связаться

1.6. Лицензии и поддержка MySQL

1.6.1. Поддержка, предлагаемая компанией MySQL AB

1.6.2. Авторские права и лицензии на MySQL

1.6.3. Лицензии на ПО MySQL

1.6.4. Логотипы и торговые марки MySQL AB

1.7. Кратко о MySQL 4.x

1.7.1. Поэтапный выпуск

1.7.2. Можно использовать уже прямо сейчас

1.7.3. Встроенный MySQL

1.7.4. Другие функции, доступные в MySQL 4.0

1.7.5. Функции MySQL 4.x, которые будут добавлены в будущем

1.7.6. MySQL 4.1, следующая ветка в разработке

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

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

1.8.2. Пользователи MySQL на IRC

1.9. Насколько MySQL соответствует стандартам?

1.9.1. Каким стандартам соответствует MySQL ?

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

1.9.3. Расширения MySQL к ANSI SQL92

1.9.4. Отличия MySQL от ANSI SQL92

1.9.5. Известные ошибки и недостатки проектирования в MySQL

1.10. MySQL и будущее (что предстоит сделать)

1.10.1. Что планируется реализовать в версии в 4.0

1.10.2. Что планируется реализовать в версии 4.1

1.10.3. Что планируется реализовать в версии 5.0

1.10.4. Что должно быть сделано в ближайшем будущем

1.10.5. То, что надо сделать когда-нибудь

1.10.6. То, чего не планируется делать

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

MySQL - это торговая марка MySQL АВ.

Программное обеспечение MySQL имеет двойное лицензирование. Это означает, что пользователи могут выбирать, использовать ли ПО MySQL бесплатно по общедоступной лицензии GNU General Public License (GPL) или приобрести одну из стандартных коммерческих лицензий MySQL AB. (http://www.gnu.org/licenses/).

Для получения самой свежей информации о программном обеспечении MySQL обращайтесь на веб-сайт MySQL (http://www.mysql.com/).

Ниже перечислены наиболее интересные разделы данного руководства.

• Информация о компании, которая занимается разработкой и распространением ПО MySQL, находится в разделе Раздел 1.5, «Что представляет собой компания MySQL AB?».

• Основные возможности сервера MySQL рассматриваются в разделе Раздел 1.4.2, «Основные возможности MySQL».

• Инструкции по инсталляции приведены в разделе Глава 2, Установка MySQL.

• Советы по переносу на другие архитектуры и операционные системы вы найдете в разделе Приложение E, Перенос на другие системы.

• Информация по апгрейду с версии 3.23 находится в разделе Раздел 2.5.2, «Модернизация с версии 3.23 до версии 4.0»

• Информация по апгрейду с версии 3.22 находится в разделе Раздел 2.5.3, «Модернизация с версии 3.22 до версии 3.23»

• Введение в обучающий курс по серверу MySQL см. в разделе Глава 3, Учебное пособие по MySQL.

• Примеры по SQL и данные по тестам производительности находятся в директории тестов производительности (sql-bench в дистрибутиве).

• Информацию о новых возможностях и об исправлениях ошибок см. в разделе Приложение D, История изменений и обновлений MySQL.

• Список известных на сегодняшний день ошибок и конструктивных дефектов см. в разделе Раздел 1.9.5, «Известные ошибки и недостатки проектирования в MySQL».

• Планы развития MySQL см. в разделе Раздел 1.10, «MySQL и будущее (что предстоит сделать)».

• Полный список тех людей, которые сделали вклад в наш проект, вы найдете в разделе Приложение C, Благодарности.

Что важно:

Отчеты об ошибках (bugs), а также вопросы и комментарии следует посылать по адресу <[email protected]>. See Раздел 1.8.1.3, «Как отправлять отчеты об ошибках или проблемах». Для составления отчетов об ошибках следует использовать сценарий mysqlbug. В поставках исходного текста сценарий mysqlbug находится в директории scripts. Если у вас бинарная поставка, то сценарий mysqlbug следует искать в директории bin.

Если вы обнаружите существенную ошибку, относящуюся к безопасности в сервере MySQL, следует сообщить об этом по адресу: <[email protected]>.

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

Это - справочное руководство по MySQL; оно представляет собой документацию по MySQL версии 5.0.6-beta. Функциональные изменения отмечены номером версии, в которой они произведены, поэтому это руководство будет полезно при освоении также и более старых версий MySQL.

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

Руководство часто обновляется, поскольку ПО СУБД MySQL находится в состоянии постоянного развития. Самая последняя версия данного руководства доступна по адресу http://www.mysql.com/documentation/ в различных форматах, включая HTML, PDF и Windows HLP.

Исходным документом для всех версий документации является файл Texinfo. HTML-версия генерируется автоматически модифицированной версией texi2html. Текстовая и Info-версии генерируются при помощи makeinfo, PostScript-версия создается texi2dvi и dvips. PDF-версия генерируется с помощью pdftex.

Если найти нужную информацию в руководстве не удается, можно прибегнуть к помощи версии руководства с функцией поиска, находящейся по адресу http://www.mysql.com/doc/.

Группа, работающая над документацией, рассмотрит любые предложения по дополнению или исправлению данного руководства. Их следует отправлять по адресу <[email protected]>.

Данное руководство было изначально написано Дэвидом Аксмарком (David Axmark) и Майклом (Монти) Видениусом (Michael (Monty) Widenius). Сейчас это руководство поддерживается Майклом (Монти) Видениусом, Полом Дюбуа (Paul DuBois), Арйен Ленц (Arjen Lentz). Остальные разработчики упомянуты в разделе Приложение C, Благодарности.

Авторское право (2003-2006) на данное руководство принадлежит шведской компании MySQL AB. See Раздел 1.6.2, «Авторские права и лицензии на MySQL».

1.2. Соглашения, используемые в данном руководстве

В данном руководстве используются следующие обозначения:

• Моноширинный

  Для имен команд и опций; SQL-операторов; имен баз данных, таблиц, столбцов; кода на C и Perl, переменных окружения применяется моноширинный шрифт. Например: ''Чтобы увидеть, как работает mysqladmin, запустите его с опцией --help.''

• filename

  Моноширинный шрифт и кавычки используются для имен файлов и путей. Например: "Дистрибутив устанавливается в каталог /usr/local/".

• ‘c’

  Для представления последовательности символов используется моноширинный шрифт, а сама последовательность символов заключается в кавычки. Например: "Для задания шаблонного символа используется символ ‘%’".

• Курсив

  Курсив используется для выделения текста, подобно данному.

• полужирный шрифт

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

Если нужно показать, что приведенная команда должна выполняться определенной программой, она предваряется подсказкой с именем этой программы. Например, shell> указывает, что команда будет выполняться вашей оболочкой, а mysql> означает, что команда будет выполняться клиентской программой mysql:

shell> набирайте команды оболочки здесь
mysql> набирайте SQL-операторы здесь

Для представления команд оболочки в данном руководстве применяется синтаксис оболочки Bourne. Если у вас используется csh-оболочка, синтаксис для нее будет несколько отличаться. Например, последовательность команд для установки переменной окружения и запуска команды в синтаксисе оболочки Bourne выглядит следующим образом:

shell> ПЕРЕМЕННАЯ=значение некая_команда

В случае csh-оболочки для выполнения тех же действий вам потребуются следующие команды:

shell> setenv ПЕРЕМЕННАЯ значение
shell> некая_команда

Часто в командах имена баз данных, таблиц, столбцов следует заменять конкретными значениями. Чтобы показать необходимость такой замены, в данном руководстве используются выражения типа db_name (имя базы данных), table_name (имя таблицы) и col_name (имя столбца). Например, в тексте руководства может встретиться оператор, подобный следующему:

mysql> SELECT col_name FROM db_name.table_name;

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

mysql> SELECT author_name FROM biblio_db.author_list;

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

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

DROP TABLE [IF EXISTS] имя_таблицы

Если элемент синтаксиса состоит из ряда альтернативных элементов, последние отделяются друг от друга вертикальными чертами (‘|’ ). В случае, когда может быть выбран один элемент из такого ряда, альтернативные элементы заключаются в квадратные скобки (‘[’ и ‘]’):

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

В случае, когда должен быть выбран один элемент из такого ряда, альтернативные элементы заключаются в фигурные скобки (‘{’ и ‘}’):

{DESCRIBE | DESC } имя_таблицы {имя_столбца | wild}

1.3. О русском переводе руководства

1.3.1. Список терминов, принятых в русском переводе

Русский перевод документации на ПО СУБД MySQL выполнен в 2002-2003гг. компанией Ensita.NET (http://www.ensita.net/).

Переводчики: (в алфавитном порядке) Василюк Елена, Добродеев Сергей, Закиянов Денис, Коротун Юрий, Пономарев Алексей, Ченцов Алексей; а также Жданов Сергей (раздел "Интерфейс DBI").

Научная редакция: Егор Егоров, Людмила Мезенко, Виктория Резниченко.

Литературный редактор: Людмила Мезенко (the best!)

Главный редактор перевода: Егор Егоров

Все замечания по русской документации направляйте по адресу <[email protected]>.

* * * * *

Компания Ensita.NET (http://www.ensita.net/), являясь официальным партнером MySQL AB с января 2002г. консультирует пользователей ПО СУБД MySQL по всему миру, поддерживая список рассылки [email protected] (see Раздел 1.8.1.1, «Списки рассылки MySQL»).

Ensita.NET с 1999г. занимается разработкой программного обеспечения для веб-сайтов, обслуживанием СУБД и консалтингом.

1.3.1. Список терминов, принятых в русском переводе

Редакционная коллегия при подготовке этого перевода старалась как можно адекватнее перевести специфические термины с английского языка на русский. Нами была поставлена цель создать справочное руководство на живом и понятном языке, но в то же время не переходить на чистый сленг. Поэтому терминология, принятая в этом переводе, возможно, не полностью соответствует четким терминам, принятым в русскоязычной литературе на "около-реляционную" тему.

Для ясности понимания мы включаем в документацию список принятых в этом переводе терминов.

1.4. Что представляет собой MySQL?

1.4.1. История MySQL

1.4.2. Основные возможности MySQL

1.4.3. Насколько стабильным является MySQL?

1.4.4. Насколько большими могут быть таблицы в MySQL?

1.4.5. Вопросы, связанные с Проблемой-2000

Разработку и сопровождение MySQL, самой популярной SQL-базы данных с открытым кодом, осуществляет компания MySQL AB. MySQL AB - коммерческая компания, основанная разработчиками MySQL, строящая свой бизнес, предоставляя различные сервисы для СУБД MySQL. See Раздел 1.5, «Что представляет собой компания MySQL AB?».

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

• MySQL - это система управления базами данных.

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

• MySQL - это система управления реляционными базами данных.

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

• Программное обеспечение MySQL - это ПО с открытым кодом.

  ПО с открытым кодом означает, что применять и модифицировать его может любой желающий. Такое ПО можно получать по Internet и использовать бесплатно. При этом каждый пользователь может изучить исходный код и изменить его в соответствии со своими потребностями. Использование программного обеспечения MySQL регламентируется лицензией GPL (GNU General Public License), http://www.gnu.org/licenses/, в которой указано, что можно и чего нельзя делать с этим программным обеспечением в различных ситуациях. Если работа в рамках GPL вас не устраивает или планируется встраивание MySQL-кода в коммерческое приложение, есть возможность купить коммерческую лицензированную версию у компании MySQL AB. See Раздел 1.6.3, «Лицензии на ПО MySQL».

• В каких случаях следует отдавать предпочтение СУБД MySQL?

  MySQL является очень быстрым, надежным и легким в использовании. Если вам требуются именно эти качества, попробуйте поработать с данным сервером. MySQL обладает также рядом удобных возможностей, разработанных в тесном контакте с пользователями. Сравнительные характеристики MySQL и других средств управления базами данных приведены на нашей странице тестов производительности (see Раздел 5.1.4, «Набор тестов MySQL (The MySQL Benchmark Suite)»).

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

• Технические возможности СУБД MySQL

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

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

• Доступно также большое количество программного обеспечения MySQL,

  разработанного сторонними разработчиками.

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

MySQL правильно произносится как ''Май Эс Кью Эль'' (а не ''майсиквел''), хотя никто не запрещает вам произносить эту аббревиатуру как ``майсиквел'' или еще каким-либо образом.

1.4.1. История MySQL

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

Происхождение имени MySQL не совсем ясно. Уже около 10 лет наша основная директория и большое количество библиотек и инструментария имеют префикс my. Более того, дочь Монти (она несколькими годами моложе) тоже получила имя My! Что из этих двух факторов повлияло на имя - до сих пор остается загадкой, даже для разработчиков.

1.4.2. Основные возможности MySQL

Ниже приведено описание важных характеристик программного обеспечения MySQL. See Раздел 1.7, «Кратко о MySQL 4.x».

• Внутренние характеристики и переносимость

  • Написан на C и C++. Протестирован на множестве различных компиляторов.

  • Работает на различных платформах. See Раздел 2.2.3, «Операционные системы, поддерживаемые MySQL».

  • Для обеспечения переносимости используется GNU Automake, Autoconf и Libtool.

  • API для C, C++, Eiffel, Java, Perl, PHP, Python, Ruby и Tcl. See Глава 8, Интерфейсы для MySQL.

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

  • Очень быстрые дисковые таблицы на основе В-деревьев со сжатием индексов.

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

  • Очень быстрые соединения, использующие оптимизированный метод однопроходного мультисоединения (one-sweep multi-join).

  • Хеш-таблицы в памяти, используемые как временные таблицы.

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

  • MySQL- код протестирован с использованием Purify (коммерческий детектор утечки памяти), а также Valgrind, одного из GPL-инструментов (http://developer.kde.org/~sewardj/

• Типы столбцов

  • Большое количество: целочисленные со знаком/беззнаковые, длиной в 1, 2, 3, 4 и 8 байтов, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET и ENUM. See Раздел 6.2, «Типы данных столбцов».

  • С записями фиксированной и переменной длины.

  • Все столбцы имеют значения по умолчанию. С помощью INSERT можно вставить подмножество столбцов таблицы; столбцы, для которых явно не заданы значения, устанавливаются в значения по умолчанию.

• Команды и функции

  • Полная поддержка операторов и функций в SELECT- и WHERE- частях запросов. Например:

    mysql> SELECT CONCAT(first_name, " ", last_name)
        -> FROM tbl_name
        -> WHERE income/dependents > 10000 AND age > 30;
    

  • Полная поддержка для операторов SQL GROUP BY и ORDER BY с выражениями SQL. Поддержка групповых функций (COUNT(), COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX() и MIN()).

  • Поддержка LEFT OUTER JOIN и RIGHT OUTER JOIN с синтаксисом ANSI SQL и ODBC.

  • Разрешены псевдонимы для таблиц и столбцов в соответствии со стандартом SQL92.

  • DELETE, INSERT, REPLACE, and UPDATE возвращают число строк, которые были изменены. Вместо этого можно задать возвращение совпавших строк. Для этого следует установить флаг при соединении с сервером.

  • Команду SHOW, которая является специфической для MySQL, можно использовать для получения информации о базах данных, таблицах и индексах. Чтобы выяснить, как оптимизатор выполняет запрос, можно применять команду EXPLAIN.

  • Имена функций не конфликтуют с именами таблиц и столбцов. Например, ABS является корректным именем столбца. Для вызова функции существует только одно ограничение: между именем функции и следующей за ним открывающей скобкой ‘(’ не должно быть пробелов. See Раздел 6.1.7, «``Придирчив'' ли MySQL к зарезервированным словам?».

  • В одном и том же запросе могут указываться таблицы из различных баз данных (с версии 3.22).

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

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

• Масштабируемость и ограничения

  • Управляет очень большими базами данных. Компания MySQL AB. использует MySQL для работы с несколькими базами данных, которые содержат 50 миллионов записей, кроме того, нам известны пользователи, использующие MySQL для работы с 60000 таблицами, включающими около 5000000000 строк.

  • Для каждой таблицы разрешается иметь до 32 индексов. Каждый индекс может содержать от 1 до 16 столбцов или частей столбцов. Максимальная ширина индекса 500 бит (это значение может быть изменено при компиляции MySQL). Для индекса может использоваться префикс поля CHAR или VARCHAR.

• Установка соединений

  • Клиенты могут соединяться с MySQL, используя сокеты TCP/IP, сокеты Unix или именованные каналы (named pipes, под NT).

  • Поддержка ODBC (Open-DataBase-Connectivity) для Win32 (с исходным кодом). Все функции ODBC 2.5 и многие другие. Например, для соединения с MySQL можно использовать MS Access. See Раздел 8.3, «Поддержка ODBC в MySQL».

• Локализация

  • Сервер может обеспечивать сообщения об ошибках для клиентов на различных языках. See Раздел 4.6.2, «Сообщения об ошибках на языках, отличных от английского».

  • Полная поддержка нескольких различных кодировок, включая ISO-8859-1 (Latin1), немецкий, big5, ujis и многие другие. Например, скандинавские символы разрешены в именах таблиц и столбцов.

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

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

• Клиенты и инструментарий

  • Включает myisamchk, очень быструю утилиту для проверки, оптимизации и восстановления таблиц. Все функциональные возможности myisamchk также доступны через SQL-интерфейс. See Глава 4, Администрирование баз данных.

  • Все MySQL-программы можно запускать с опциями --help или -? для получения помощи.

1.4.3. Насколько стабильным является MySQL?

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

Самые первые версии кода были созданы в начале 80-х. Это был устойчивый код с форматом таблиц ISAM, обеспечивающим обратную совместимость с предыдущими версиями. Во времена компании TcX, предшественника MySQL AB, с середины 1986 года код MySQL работал в проектах без каких-либо проблем. Но когда сервер MySQL был выпущен для широкого использования, оказалось, что существует несколько фрагментов ``непротестированного кода''. Эти фрагменты были быстро обнаружены новыми пользователями, которые составляли запросы в несколько ином виде, чем мы.

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

Каждый релиз MySQL был рабочим, проблемы возникали только при использовании кода из ``серых зон''. Естественно, что новые пользователи не знают о том, где находятся такие ``серые зоны''; в данном разделе сделана попытка описать те из них, которые известны на данный момент. Большая часть описания относится к версии 3.23 MySQL-сервера. В самой последней версии все известные ошибки устранены, за исключением тех, которые перечислены в разделе ошибок, а также конструктивных дефектов. See Раздел 1.9.5, «Известные ошибки и недостатки проектирования в MySQL».

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

• Репликация - Gamma

  Большие серверные кластеры, в которых применяется репликация, находятся в промышленной эксплуатации и показывают хорошие результаты. Работа над средствами репликации в MySQL 4.x продолжается.

• InnoDB-таблицы - стабильно (в 3.23 с 3.23.49)

  Обработчик транзакционных InnoDB-таблиц объявлен в настоящее время стабильными в дереве MySQL 3.23, начиная с версии 3.23.49. InnoDB используется в больших промышленных системах с большой нагрузкой.

• BDB-таблицы - Gamma

  Код Berkeley DB очень устойчив, но на настоящий момент продолжается усовершенствование интерфейса обработчика транзакционных BDB-таблиц с MySQL, поэтому должно пройти некоторое время, пока он будет так же хорошо протестирован, как и таблицы других типов.

• Полнотекстовый поиск - Beta

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

• MyODBC 2.50 (использующий ODBC SDK 2.5) - Gamma

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

• Aвтоматическое восстановление MyISAM-таблиц - Gamma

  Статус Gamma относится только к новому коду в обработчике таблиц, который проверяет правильность закрытия таблицы после ее открытия и выполняет автоматическую проверку/восстановление незакрытой таблицы.

• Вставка больших объемов данных - Alpha

  Новая возможность в MyISAM-таблицах в MySQL 4.0 для быстрой вставки большого количества строк.

• Блокировка - Gamma

  В большой степени зависит от системы. В некоторых системах возникают большие проблемы с использованием стандартной для ОС блокировки (fcntl()). В таких случаях следует запустить демон mysqld с флагом --skip-external-locking. Известно, что проблемы имеют место в некоторых системах Linux и в SunOS, когда используются NFS-монтированные файловые системы.

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

1.4.4. Насколько большими могут быть таблицы в MySQL?

MySQL версии 3.22 имеет предел по размеру таблиц 4 Гб. В MySQL версии 3.23, где используется новый тип таблиц, максимальный размер таблицы доведен до 8 миллионов терабайтов (2 ^ 63 bytes).

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

В Linux 2.2 существует возможность создавать таблицы с размерами более 2 Гб, используя патч LFS для файловой системы ext2. Существуют также патчи, обеспечивающие поддержку больших файлов для ReiserFS в Linux 2.4.

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

По умолчанию MySQL-таблицы имеют максимальный размер около 4 Гб. Для любой таблицы можно проверить/определить ее максимальный размер с помощью команд SHOW TABLE STATUS или myisamchk -dv table_name. See Раздел 4.5.6, «Синтаксис команды SHOW».

Если необходимы таблицы большего размера, чем 4 Гб (и используемая операционная система ``не возражает''), следует при создании такой таблицы задать параметры AVG_ROW_LENGTH и MAX_ROWS (see Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»). Эти параметры можно задать и позже - с помощью ALTER TABLE (see Раздел 6.5.4, «Синтаксис оператора ALTER TABLE»).

Если большая таблица предназначена только для чтения, можно воспользоваться myisampack, чтобы слить несколько таблиц в одну и сжать ее. Обычно myisampack ужимает таблицу по крайней мере на 50%, поэтому в результате можно получить очень большие таблицы (see Раздел 4.7.4, «myisampack, MySQL-генератор сжатых таблиц (только для чтения)»).

Есть еще одна возможность обойти ограничения операционной системы на размеры файлов данных MyISAM, - это делается при помощи опции RAID (see Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»).

Еще одним решением может быть использование функции MERGE, которая обеспечивает возможность обрабатывать набор идентичных таблиц как одну таблицу (see Раздел 7.2, «Таблицы MERGE»).

1.4.5. Вопросы, связанные с Проблемой-2000

Сам MySQL не имеет проблем, связанных с Проблемой-2000 (Y2K):

• В MySQL используются функции времени Unix, поэтому проблемы с датами, вплоть до 2069, исключены. Принимается, что все двузначные значения годов находятся в диапазоне с 1970 по 2069, поэтому число 01 в столбце с типом year MySQL обрабатывает как 2001.

• Все MySQL-функции, обрабатывающие даты, хранятся в одном файле sql/time.cc. Их код был написан очень тщательно, чтобы застраховаться от проблем, связанных с 2000-м годом.

• В версиях MySQL 3.22 и более поздних в столбцах с новым типом YEAR, который обеспечивает хранение нулевого 0 года и значений лет от 1901 до 2155 в одном байте, а также отображение дат при помощи 2 или 4 знаков.

Проблемы, связанные с 2000-м годом, могут возникнуть в приложениях, которые используют MySQL так, что это может оказаться небезопасным с точки зрения Y2K. Например, во многих старых приложениях для хранения и обработки значений годов используются 2-значные величины (которые можно трактовать неоднозначно), а не 4-значные. Эта проблема может быть урегулирована при помощи приложений, которые используют 00 или 99 как ``отсутствующие'' индикаторы значений.

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

Приведенный ниже код является наглядной демонстрацией того, что в MySQL Server проблемы с датами вплоть до 2030 года отсутствуют.

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE y2k (date DATE,
    -> date_time DATETIME,
    -> time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO y2k VALUES
    -> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
    -> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
    -> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
    -> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
    -> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
    -> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
    -> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
    -> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
    -> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
    -> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
    -> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
    -> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

Можно видеть, что при использовании типов DATE и DATETIME проблем с датами будущего не возникнет (эти типы ``справляются'' с датами вплоть до 9999 года).

Тип TIMESTAMP, который используется для сохранения текущего времени, имеет диапазон только до 2030-01-01. В 32-разрядных машинах TIMESTAMP тип имеет диапазон от 1970 до 2030 (значение со знаком). В 64-разрядных машинах этот тип ``справляется'' со значениями времени до 2106 года (значение без знака).

Таким образом, даже несмотря на то, что MySQL является Y2K-совместимым, ответственность за однозначную интерпретацию значений даты ложится на плечи пользователя. See Раздел 6.2.2.1, «Проблема 2000 года и типы данных», где приведены правила по работе MySQL с входными данными, которые имеют неоднозначные значения даты (данные, содержащие 2-значные значения года).

1.5. Что представляет собой компания MySQL AB?

1.5.1. Бизнес-модель и услуги, оказываемые компанией MySQL AB

1.5.2. Как с нами связаться

MySQL AB - компания, в состав которой входят основатели MySQL и основные разработчики. MySQL AB создана в Швеции Дэвидом Аксмарком (David Axmark), Аланом Ларссом (Allan Larsson) и Майклом Монти Видениусом (Michael Monty Widenius).

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

Наша компания занимается разработкой и распространением СУБД MySQL и сопутствующего ПО. MySQL AB владеет всеми правами на исходный код MySQL, на логотип и торговую марку MySQL, а также на данное руководство (see Раздел 1.4, «Что представляет собой MySQL?»).

Наши основные ценности - это то, что наша деятельность посвящена MySQL и идеям Open Source, открытого программного обеспечения.

Мы хотим, чтобы сервер MySQL соответствовал следующим критериям:

• Лучший и популярнейший сервер СУБД в мире

• Доступный всем

• Простой в эксплуатации

• Постоянно развивающийся не в ущерб скорости и безопасности

• Работающий надежно

• Удобный для использования и усовершенствования

MySQL AB и люди, работающие в MySQL AB:

• Продвигают философию Open Source и поддерживают пользователей Open Source

• Хорошие граждане

• С удовольствием работают с партнерами, разделяющими нашу точку зрения и ценности

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

• Является виртуальной командой, взаимодействующей через Internet

• Работают ``против'' патентованного ПО

Свежая информация о MySQL и MySQL AB находится на сайте MySQL (http://www.mysql.com/).

1.5.1. Бизнес-модель и услуги, оказываемые компанией MySQL AB

1.5.1.1. Поддержка

1.5.1.2. Обучение и сертификация

1.5.1.3. Консультации

1.5.1.4. Коммерческие лицензии

1.5.1.5. О нашей программе партнерства

1.5.1.6. О рекламе

Очень часто нам задают такой вопрос: ''Как вам удается зарабатывать на жизнь, ведь вы все раздаете бесплатно?''

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

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

1.5.1.1. Поддержка

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

Майкл Монти Вайдиниус (Michael Monty Widenius), главный автор MySQL Server. See Раздел 1.6.1, «Поддержка, предлагаемая компанией MySQL AB».

Для более подробной информации и заказа различных уровней поддержки обратитесь на веб-сайт https://order.mysql.com/ или свяжитесь с нашим отделом сбыта по адресу <[email protected]>.

1.5.1.2. Обучение и сертификация

Компания MySQL AB проводит обучение по MySQL и другим смежным продуктам по всему миру. Мы предлагаем как общедоступные, так и внутрифирменные курсы, подготовленные в соответствии с конкретными потребностями вашей компании. Обучение по MySQL проводят также наши партнеры - авторизованные центры обучения по MySQL.

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

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

• сэкономите время

• повысите эффективность работы своих приложений

• уменьшите или устраните необходимость в дополнительном оборудовании, сократив таким образом издержки

• усилите защищенность своих приложений

• полнее удовлетворите потребности ваших заказчиков и коллег.

• подготовитесь к сертификации по MySQL.

Если предлагаемое нами обучение интересует вас как потенциального участника нашего проекта или партнера в реализации учебных курсов, посетите учебный раздел на нашем веб-сайте http://www.mysql.com/training/ или свяжитесь с нами по адресу: <[email protected]>.

Для более подробной информации о программе сертификации MySQL, см. http://www.mysql.com/certification/.

1.5.1.3. Консультации

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

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

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

Заинтересованных в наших консультационных услугах, а также тех, кто хотели бы стать нашими партнерами в оказании таких услуг, приглашаем посетить консультационный раздел на нашем веб-сайте http://www.mysql.com/consulting/.

1.5.1.4. Коммерческие лицензии

ПО баз данных MySQL выпускается по общедоступной лицензии GNU General Public License (GPL). Это означает, что при соблюдении условий GPL ПО MySQL можно пользоваться бесплатно. Если вы не хотите связывать себя лицензионными ограничениями GPL (например, вас не устраивает условие, что ваше собственное приложение также подпадает под действие GPL), есть возможность приобрести у компании MySQL AB на этот же продукт коммерческую лицензию.

См. https://order.mysql.com/).

Компания MySQL AB владеет авторскими правами на исходный код MySQL, поэтому мы вправе использовать двойное лицензирование, в соответствии с которым один и тот же продукт доступен как по лицензии GPL, так и по коммерческой лицензии, и это никоим образом не нарушает обязательств компании MySQL AB по предоставлению исходного кода. Более подробную информацию о том, в каких случаях необходимо приобретение коммерческой лицензии, вы найдете в разделе Раздел 1.6.3, «Лицензии на ПО MySQL».

Компания MySQL AB занимается также продажей коммерческих лицензий на ПО сторонних разработчиков, предоставляемое с открытым исходным кодом на условиях GPL. Это ПО расширяет возможности MySQL. Хороший пример - транзакционный обработчик таблиц InnoDB, обеспечивающий поддержку технологии ACID, строковую блокировку, восстановление системы после аварии, управление версиями, поддержку внешних ключей и многое другое (see Раздел 7.5, «Таблицы InnoDB»).

1.5.1.5. О нашей программе партнерства

Компания MySQL AB реализует глобальную программу партнерства, которая охватывает учебные курсы, консультативные услуги и поддержку продукта, издательскую деятельность, а также продажу и распространение MySQL и смежных продуктов. Партнеры компании MySQL AB получают право быть представленными на веб-сайте http://www.mysql.com/ и использовать в маркировке своих продуктов специальные варианты торговой марки MySQL - с целью идентификации и продвижения этих продуктов на рынке.

Тех, кто заинтересован в получении статуса партнера MySQL, просим обращаться по адресу <[email protected]>.

Название MySQL и логотип MySQL в виде дельфина являются торговыми марками компании MySQL AB (see Раздел 1.6.4, «Логотипы и торговые марки MySQL AB»), принадлежащими компании MySQL AB. Узнаваемость этих торговых марок свидетельствует о том, что за годы своей работы основатели компании MySQL AB сумели добиться для своей компании заметного положения и признания в мире.

1.5.1.6. О рекламе

Веб-сайт компании MySQL (http://www.mysql.com/) пользуется популярностью среди разработчиков и пользователей. Например, в октябре 2001 г. мы обслужили 10 миллионов запросов на просмотр размещенных на нем страниц. Наши посетители относятся к категории лиц, принимающих решения и дающих рекомендации о покупке как программного, так и аппаратного обеспечения. 12% наших посетителей утверждают решения о приобретении, и только 9% наших посетителей совсем не имеют отношения к принятию подобных решений. Более 65% наших посетителей сделали в деловых целях как минимум одну покупку в Сети за последние полгода, а 70% - планируют совершить ее в ближайшие месяцы.

1.5.2. Как с нами связаться

Самая свежая информация о MySQL и нашей компании представлена на веб-сайте MySQL (http://www.mysql.com/).

По вопросам связи с прессой и темам, не затронутым в наших сообщениях для печати (http://www.mysql.com/news/), обращайтесь по адресу <[email protected]>.

Для получения своевременных и точных ответов на технические вопросы, касающиеся ПО MySQL, необходимо иметь действующий контракт с компанией MySQL AB по поддержке (за дополнительной информацией обращайтесь к разделу Раздел 1.6.1, «Поддержка, предлагаемая компанией MySQL AB»). Чтобы заказать контракт по поддержке, следует обратиться на сайт https://order.mysql.com/ или направить сообщение по адресу <[email protected]>.

Для получения информации об учебных курсах, которые проводит компания MySQL AB, посетите раздел по обучению на веб-сайте http://www.mysql.com/training/. Тех, кто имеет ограниченный доступ в Internet, просим связаться с учебным отделом компании MySQL AB по адресу <[email protected]> (see Раздел 1.5.1.2, «Обучение и сертификация»).

Информацию о программе сертификации компании MySQL AB вы найдете на странице http://www.mysql.com/certification/index.html нашего веб-сайта. Если вы желаете быть в курсе текущего состояния программы сертификации по MySQL, просим сообщить об этом по адресу <[email protected]>. See Раздел 1.5.1.2, «Обучение и сертификация».

Заинтересованных в получении консультаций приглашаем посетить раздел консультаций на веб-сайте http://www.mysql.com/consulting/.

Коммерческие лицензии можно приобрести по Сети, на веб-сайте https://order.mysql.com/. Здесь вы найдете также информацию о том, как передать в компанию MySQL AB свой заказ на покупку по факсу. Более подробная информация о лицензировании доступна на http://www.mysql.com/products/pricing.html.

Если у вас имеются вопросы, касающиеся лицензирования, или вы хотите знать расценки на лицензии в случае массового выпуска продукта, заполните форму на нашем веб-сайте (http://www.mysql.com/) или пошлите сообщение по электронной почте: вопросы, касающиеся лицензирования, направляйте по адресу <[email protected]>, а запросы на покупку - по адресу <[email protected]>. Обращайтесь также к разделу Раздел 1.6.3, «Лицензии на ПО MySQL».

Если вы представляете деловые круги, заинтересованные в партнерских отношениях с компанией MySQL AB, напишите нам по адресу <[email protected].> Обращайтесь к разделу Раздел 1.5.1.5, «О нашей программе партнерства».

Для получения дополнительной информации о политике компании MySQL в отношении торговых марок обращайтесь на наш веб-сайт http://www.mysql.com/company/trademark.html или напишите письмо по адресу <[email protected]>. Обратитесь к разделу Раздел 1.6.4, «Логотипы и торговые марки MySQL AB».

Если вас заинтересовало какое-либо из предложений, перечисленных в нашем разделе предложений работы (http://www.mysql.com/company/jobs/), направляйте свои письма по адресу <[email protected]>. Просьба не оформлять свои личные данные в виде вложения в письмо: лучше добавьте эту информацию в виде обычного текста в конце своего сообщения.

Если вы желаете принять участие в общей дискуссии с нашими многочисленными пользователями, обращайтесь на соответствующий список рассылки (see Раздел 1.8.1, «Списки рассылки MySQL»).

Сообщения об ошибках (или bugs), а также вопросы и комментарии следует направлять в список рассылки по адресу <[email protected]>. При обнаружении в MySQL ошибок, влияющих на безопасность баз данных, просим сообщать об этом по адресу <[email protected]>. Обратитесь также к разделу Раздел 1.8.1.3, «Как отправлять отчеты об ошибках или проблемах».

Если у вас имеются сравнительные результаты тестирования, которые мы можем опубликовать, свяжитесь с нами по адресу <[email protected]>.

Предложения по внесению дополнений или исправлений в данное руководство пользователя следует направлять коллективу разработчиков руководства по адресу <[email protected]>.

Вопросы и замечания по работе или содержанию веб-сайта MySQL (http://www.mysql.com/) направляйте по адресу <[email protected]>.

Компания MySQL AB придерживается определенной политики относительно конфиденциальности информации. Об этом вы можете прочитать на странице http://www.mysql.com/company/privacy.html нашего веб-сайта. По вопросам этой политики просим обращаться по адресу <[email protected]>.

По всем другим вопросам обращайтесь по адресу <[email protected]>.

1.6. Лицензии и поддержка MySQL

1.6.1. Поддержка, предлагаемая компанией MySQL AB

1.6.2. Авторские права и лицензии на MySQL

1.6.3. Лицензии на ПО MySQL

1.6.4. Логотипы и торговые марки MySQL AB

В этом разделе описаны условия предоставления компанией MySQL AB лицензий и поддержки.

1.6.1. Поддержка, предлагаемая компанией MySQL AB

Что подразумевается под технической поддержкой компании MySQL AB? Это означает, что на каждый свой вопрос вы получите адресованный лично вам ответ непосредственно от программистов, пишущих программы баз данных MySQL.

Мы стараемся, чтобы наша техническая поддержка носила широкий и содержательный характер. Если вопрос, который вы задаете по MySQL, важен для вас, то, следовательно, он должен быть важен и для нас. Как правило, клиенты просят помочь разобраться в том, как работают те или иные команды или утилиты, как устранить ``узкие места'', мешающие эффективной работе системы, как восстановить систему в случае аварии, как влияет на работу MySQL та или иная операционная система или локальная сеть, какие технологии резервного копирования и восстановления данных лучше применять, как использовать API-интерфейсы и т.д. Наша поддержка охватывает вопросы, относящиеся только к серверу MySQL и нашим собственным утилитам, но не к продуктам сторонних разработчиков, которые обеспечивают доступ к серверу MySQL, хотя мы стараемся и в этих случаях оказывать посильную помощь.

Подробная информация о различных видах поддержки, которую предлагает компания, приведена на веб-сайте http://www.mysql.com/support/. Там же вы можете заказать по Сети контракты по поддержке. Те, кто имеет ограниченный доступ в Internet, могут связаться с нашим отделом сбыта по адресу <[email protected]>.

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

1.6.2. Авторские права и лицензии на MySQL

Компания MySQL AB является владельцем авторских прав на исходный код ПО MySQL, логотипы и торговые марки MySQL, а также на данное руководство пользователя. Обратитесь к разделу Раздел 1.5, «Что представляет собой компания MySQL AB?» Распространение MySQL подпадает под действие нескольких различных лицензий:

1. Весь код ПО сервера, специфичный только для MySQL, библиотека mysqlclient и клиентское ПО, а также библиотека GNU readline подпадают под действие общедоступной лицензиии GNU General Public License (see Приложение H, GNU General Public License). Текст этой лицензии имеется также в составе дистрибутива ПО, в файле COPYING.

2. Библиотека GNU getopt подпадает под действие GNU Lesser General Public License (see Приложение I, GNU Lesser General Public License).

3. Некоторые фрагменты исходного кода (библиотека regexp) подпадают под действие Berkeley-подобной лицензии.

4. Старые версии MySQL (3.22 и более ранние) подпадают под действие более строгой лицензии (http://www.mysql.com/products/mypl.html). Информация об условиях лицензии имеется в документации на конкретную версию.

5. Распространение руководства пользователя в данное время не подпадает под действие лицензии типа GPL. Его использование допускается на следующих условиях:

   • Допускается конвертирование в другие форматы, но внесение при этом каких-либо изменений или редактирование содержания не допускается.

   • Разрешается выпуск печатных копий руководства для личных целей.

   • Во всех остальных случаях, таких как продажа печатных изданий руководства или использование руководства (или его части) в других публикациях, требуется предварительно получить письменное согласие компании MySQL AB.

   Для получения дополнительной информации или в случае, если вы хотели бы принять участие в переводе руководства, обращайтесь по адресу <[email protected]>.

Дополнительная информация о том, как практически осуществляется лицензирование MySQL, находится в разделе Раздел 1.6.3, «Лицензии на ПО MySQL». Обращайтесь также к разделу Раздел 1.6.4, «Логотипы и торговые марки MySQL AB».

1.6.3. Лицензии на ПО MySQL

1.6.3.1. Использование ПО MySQL под коммерческой лицензией

1.6.3.2. Бесплатное использование ПО MySQL по лицензии GPL

ПО MySQL распространяется в соответствии с условиями общедоступной лицензии GNU General Public License (GPL), которая является одной из наиболее широко распространенных лицензий на ПО с открытым исходным кодом. Официальные условия лицензии GPL вы найдете на веб-сайте http://www.gnu.org/licenses/. Обратитесь также к http://www.gnu.org/licenses/gpl-faq.html и http://www.gnu.org/philosophy/enforcing-gpl.html.

Так как ПО MySQL выпускается по лицензии GPL, зачастую им можно пользоваться бесплатно, но в некоторых случаях желательно или необходимо приобрести коммерческую лицензию у компании MySQL AB (это можно сделать на веб-сайте https://order.mysql.com/).

См. http://www.mysql.com/products/licensing.html для получения более подробной информации.

Старые версии MySQL (3.22 и более ранние) подпадают под действие более строгой лицензии (http://www.mysql.com/products/mypl.html). Информацию об условиях лицензии вы найдете в документации на конкретную версию.

Обращаем ваше внимание на то, что использование ПО MySQL, подпадающего под коммерческую лицензию, лицензию GPL или старую лицензию MySQL, не означает, что вы автоматически получаете право на использование торговых марок, принадлежащих компании MySQL AB. Об этом читайте в разделе Раздел 1.6.4, «Логотипы и торговые марки MySQL AB».

1.6.3.1. Использование ПО MySQL под коммерческой лицензией

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

Коммерческая лицензия является необходимой в следующих случаях:

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

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

• В случае, когда вам требуется распространять ПО MySQL без предоставления исходного кода, как того требует лицензия GPL.

• Если вы хотите сделать вклад в дальнейшее развитие технологии баз данных MySQL - в таких случаях коммерческая лицензия формально может и не требоваться. Еще одним хорошим способом оказать содействие развитию ПО MySQL является приобретение контракта по поддержке непосредственно у компании MySQL AB - это сразу же принесет пользу и вам (see Раздел 1.6.1, «Поддержка, предлагаемая компанией MySQL AB»).

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

По поводу коммерческих лицензий, см. http://www.mysql.com/products/licensing.html. Для контрактов на поддержку, см. http://www.mysql.com/support/. Тех, для кого требуются особые условия лицензирования, а также тех, у кого имеется ограниченный доступ в Internet, просим связаться с нашим отделом сбыта по адресу <[email protected]>.

1.6.3.2. Бесплатное использование ПО MySQL по лицензии GPL

По лицензии GPL допускается бесплатное использование ПО MySQL если вы согласны с условиями GPL. Подробнее по поводу лицензии GPL и освещение наиболее популярных вопросов вы найдете по адресу http://www.gnu.org/licenses/gpl-faq.html.

Некоторые общие примеры GPL-использования MySQL:

• Если вы распространяете код вашего приложения и код MySQL под лицензией GPL и в исходных текстах.

• При распространении исходного кода MySQL в комплекте с другими программами, не связанными с MySQL или не зависящими от него по своему функциональному назначению, даже в том случае, если они распространяются на коммерческой основе. Это называется mere aggregation в лицензии GPL.

• Если вы не распространяете никаких частей кода MySQL - вы можете использовать MySQL бесплатно.

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

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

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

В общем случае мы рекомендуем приобретать контракт на поддержку компании MySQL AB и тем, кому для использования ПО баз данных MySQL не требуется коммерческой лицензии: этим вы будете способствовать развитию технологии MySQL и заодно немедленно получите для себя дополнительные преимущества (see Раздел 1.6.1, «Поддержка, предлагаемая компанией MySQL AB»).

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

1.6.4. Логотипы и торговые марки MySQL AB

1.6.4.1. Оригинальный логотип MySQL

1.6.4.2. Логотипы MySQL, которые могут использоваться без письменного разрешения

1.6.4.3. В каком случае для использования логотипов необходимо письменное разрешение?

1.6.4.4. Партнерские логотипы MySQL AB

1.6.4.5. Использование слова MySQL в текстовых документах и презентациях

1.6.4.6. Использование слова MySQL в названиях компаний и продуктов

Многие пользователи СУБД MySQL выражают желание расположить логотип MySQL AB с изображением дельфина на своих веб-сайтах, книгах или коробках со своими программными продуктами. Мы приветствуем это желание, хотя и обязаны напомнить, что MySQL и логотип MySQL с изображением дельфина являются торговыми марками компании MySQL AB и могут применяться только в соответствии с нашими правилами использования торговых знаков, с которыми вы можете ознакомиться по адресу http://www.mysql.com/company/trademark.html.

1.6.4.1. Оригинальный логотип MySQL

Логотип MySQL с изображением дельфина был создан финским рекламным агентством Priority в 2001 году. Мы решили сделать эмблемой СУБД MySQL дельфина - умное, проворное и изящное животное, с удивительной легкостью плавающее в океане, так же как и наша СУБД - в океане данных. К тому же дельфины нам просто нравятся.

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

1.6.4.2. Логотипы MySQL, которые могут использоваться без письменного разрешения

Мы разработали несколько специальных логотипов для договорного использования, которые можно загрузить с нашего сайта, расположенного по адресу http://www.mysql.com/press/logos.html и применять на сайтах третьих сторон без письменного разрешения MySQL AB. Возможности использования этих логотипов, как и следует из их названия, определенным образом ограничены: они регламентируются правилами применения наших торговых знаков (которые также приведены у нас на сайте). Если вы планируете использовать данные логотипы, необходимо ознакомиться с указанными правилами. Они в основном сводятся к следующим:

• Нужный вам логотип вы можете использовать в том виде, в котором он приведен на сайте http://www.mysql.com/. Вы имеете право задать необходимые размеры логотипа, но не можете менять его цвета или вносить в изображение какие-либо другие изменения.

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

• Не разрешается использовать торговый знак в целях, которые могли бы принести вред MySQL AB или понизить ценность торговых знаков MySQL AB. Мы оставляем за собой право запретить использование торгового знака MySQL AB.

• Помещая торговый знак на своем сайте, сделайте его гиперссылкой на сайт http://www.mysql.com/.

• Если вы используете СУБД MySQL в своем приложении на условиях лицензии GPL, оно должно быть создано в соответствии с идеологией Open Source и снабжено способностью подсоединяться к серверу MySQL.

Связаться с нами с целью заключения соответствующих вашим потребностям соглашений можно по адресу <[email protected]>.

1.6.4.3. В каком случае для использования логотипов необходимо письменное разрешение?

Письменное разрешение MySQL AB для использования логотипов MySQL необходимо в следующих случаях:

• При использовании логотипа MySQL AB где бы то ни было, кроме вашего веб-сайта.

• При использовании любого логотипа MySQL AB, кроме вышеупомянутых специальных логотипов для договорного использования, на веб-сайтах или в любых других местах.

Исходя из юридических и коммерческих соображений, мы следим за использованием торговых знаков MySQL на различных продуктах, книгах и т.п. Обычно мы взимаем плату за помещение логотипов MySQL AB на коммерческих продуктах, так как считаем, что вполне справедливо, если часть полученных производителем прибылей идет таким образом на финансирование дальнейшего усовершенствования СУБД MySQL.

1.6.4.4. Партнерские логотипы MySQL AB

Партнерские логотипы MySQL могут использоваться только теми компаниями и частными лицами, которые подписали письменное соглашение о партнерстве с MySQL AB. В условия подписания такового соглашения входит сертификация в качестве преподавателя или консультанта MySQL. See Раздел 1.5.1.5, «О нашей программе партнерства».

1.6.4.5. Использование слова MySQL в текстовых документах и презентациях

MySQL AB приветствует упоминания о СУБД MySQL, но не следует забывать о том, что слово MySQL - торговая марка MySQL AB. Поэтому первое встречающееся в тексте слово MySQL следует снабдить символом, обозначающим торговую марку (TM), а также (по возможности) упомянуть о том, что MySQL является зарегистрированной торговой маркой компании MySQL AB. Дополнительную информацию вы сможете получить, ознакомившись с нашими правилами использования торговых знаков, расположенными по адресу http://www.mysql.com/company/trademark.html.

1.6.4.6. Использование слова MySQL в названиях компаний и продуктов

Использовать слово MySQL в названиях компаний, продуктов или в именах доменов без письменного разрешения MySQL AB запрещено.

1.7. Кратко о MySQL 4.x

1.7.1. Поэтапный выпуск

1.7.2. Можно использовать уже прямо сейчас

1.7.3. Встроенный MySQL

1.7.4. Другие функции, доступные в MySQL 4.0

1.7.5. Функции MySQL 4.x, которые будут добавлены в будущем

1.7.6. MySQL 4.1, следующая ветка в разработке

Наконец-то появилась давно обещанная компанией MySQL AB бета-версия MySQL Server 4.0, которую так долго ждали пользователи. Ее можно загрузить с веб-сайта http://www.mysql.com/ или с наших зеркал.

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

1.7.1. Поэтапный выпуск

Начиная с 4.0.6, MySQL имеет статус gamma, что означает что версии 4.0.x в течении более чем 2 месяцев (сначала в alpha-, затем и в beta-статусе) используются без каких-либо известных серьезных и сложных для исправления ошибок и готовы для промышленного использования.

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

Все новые функции будут добавляться в версию MySQL 4.1, доступную сейчас из нашего репозитория bk, выпуск alpha-версии которой запланирован на первый квартал 2003. See Раздел 2.3.4, «Установка из экспериментального набора исходных кодов».

1.7.2. Можно использовать уже прямо сейчас

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

1.7.3. Встроенный MySQL

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

Большинство пользователей libmysqld оценят преимущество Двойной лицензии MySQL. Для тех, кто не хочет связывать себя условиями GPL лицензии, программное обеспечение доступно также на условиях коммерческой лицензии. Для встроенной библиотеки MySQL используется такой же интерфейс, как и для обычной клиентской библиотеки, поэтому ею удобно и легко пользоваться. See Раздел 8.4.9, «libmysqld, встраиваемая библиотека сервера MySQL».

1.7.4. Другие функции, доступные в MySQL 4.0

• В версии 4.0 еще больше возросла скорость работы MySQL в нескольких областях, таких как множественные вставки (bulk INSERT) для большого количества данных, поиск в сжатых индексах, создание полнотекстовых индексов (FULLTEXT), а также COUNT(DISTINCT).

• Обработчик таблиц InnoDB теперь входит в стандартный набор сервера MySQL, включая полную поддержку транзакций и блокировок уровня строки.

• Немецкие, австрийские и швейцарские пользователи нашей программы обратят внимание, что мы добавили новый набор символов, latin1_de, который позволяет исправить порядок сортировки немецких символов, размещая немецкие умляуты в соответствии с телефонными книгами, используемыми в Германии.

• Функции для упрощения преобразования из других систем баз данных в MySQL, включают TRUNCATE TABLE (как в Oracle) и IDENTITY, как синоним автоматически инкрементируемых ключей (как в Sybase). Многим пользователям также будет приятно узнать, что MySQL теперь поддерживает оператор UNION, долгожданную стандартную функцию SQL.

• Создавая новые функции для новых пользователей, мы не забыли о запросах наших постоянных пользователей. У нас есть многотабличные операторы DELETE и UPDATE Добавив поддержку символических ссылок к MyISAM на уровне таблицы (а не только на уровне базы данных, как это было раньше), а также включив обработку таких ссылок как функцию, используемую в Windows по умолчанию, мы надеемся продемонстрировать, что серьезно относимся к предложениям по усовершенствованиям. Такие функции как SQL_CALC_FOUND_ROWS и FOUND_ROWS() позволяют узнать, сколько строк возвратит запрос без оператора LIMIT.

1.7.5. Функции MySQL 4.x, которые будут добавлены в будущем

В последующих версиях MySQL 4.x будут добавлены следующие функции, которые на данный момент находятся в стадии разработки:

• Пользователи MySQL, работающие с критически важными системами и большими объемами данных, оценят дополнения к нашей системе репликации и удаленного резервного копирования. В более поздние версии 4.x будет включена отказобезопасная репликация; а к функциям уже существующей в версии 4.0 команды LOAD DATA FROM MASTER в скором времени будет добавлена автоматизация настройки подчиненных серверов. Удаленное резервное копирование обеспечит возможность легко добавлять новые подчиненные серверы, не отключая головной сервер, - это позволит практически избежать потерь в производительности при обновлении объемных систем.

• Для администраторов баз данных удобным окажется еще одно новшество: в скором времени параметры mysqld (настройки запуска) можно будет изменять без выключения серверов.

• Новые свойства поиска FULLTEXT в MySQL 4.0 позволяют использовать FULLTEXT-индексацию больших объемов текста при помощи как бинарной логики поиска, так и логики поиска естественного языка. Пользователи могут производить настройку минимальной длины слова и задавать свои списки недопустимых слов на любом естественном языке, благодаря чему появляется возможность создания новой группы программ на основе MySQL.

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

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

1.7.6. MySQL 4.1, следующая ветка в разработке

MySQL 4.0 готовит базу для реализации новых возможностей в сервере MySQL 4.1 и более новых версиях. Имеются в виду такие возможности, как вложенные подзапросы (nested subqueries) (4.1), хранимые процедуры (5.0) и правила целостности ссылок (foreign key integrity rules) для MyISAM-таблиц (5.0).

Эти возможности возглавляют список наиболее востребованных нашими потребителями функций.

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

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

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

1.8.2. Пользователи MySQL на IRC

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

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

1.8.1.2. Как задавать вопросы и направлять сообщения об ошибках

1.8.1.3. Как отправлять отчеты об ошибках или проблемах

1.8.1.4. Рекомендации по ответам на вопросы, направляемые в список рассылки

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

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

Чтобы подписаться на главный список рассылки MySQL, следует отправить сообщение на адрес электронной почты <[email protected]>.

Чтобы отказаться от подписки на главный список рассылки MySQL, следует отправить сообщение на адрес электронной почты <[email protected]>.

В посылаемом сообщении роль играет только адрес, на который это сообщение отправляется. Тема и текст сообщения игнорируются.

Если адрес, с которого было отправлено ваше сообщение, не действителен, можно точно указать адрес для подписки или адрес, подписку для которого следует аннулировать. Для этого в указанных выше адресах электронной почты следует добавить дефис в конце командного слова, обозначающего подписку (subscribe) или отказ от нее (unsubscribe), а за ним - нужный адрес электронной почты, заменив в нем символ ‘@’ на символ ‘=’. Например, чтобы подписать адрес <[email protected]>, необходимо отправить сообщение на <[email protected]>.

Сообщения, посланные по адресам <[email protected]> или <[email protected]>, обрабатываются автоматически программой обслуживания списка рассылки ezmlm. Информация по программе ezmlm доступна на веб-узле ezmlm (http://www.ezmlm.org/).

Чтобы отправить сообщение в список рассылки, следует послать сообщение по адресу <[email protected]>. Пожалуйста, не отправляйте сообщения о подписке или отказе от подписки на адрес <[email protected]>, поскольку все сообщения, направленные на этот адрес, автоматически распространяются среди тысяч других подписчиков.

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

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

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

• <[email protected]> announce

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

• <[email protected]> mysql

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

• <[email protected]> mysql-digest

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

• <[email protected]> bugs

  В этот список можно отправлять только подробные отчеты о повторяющихся ошибках, используя макропрограмму mysqlbug (если вы работаете в Windows, необходимо включить описание операционной системы и указать версию MySQL). Прежде чем отправлять отчет об ошибке, желательно проверить, при использовании какой версии MySQL данная ошибка возникает - последней окончательной или находящейся на стадии разработки! Чтобы любой желающий мог воспроизвести эту ошибку, желательно также включить в отчет контрольный тестовый пример, который можно было бы запустить при помощи mysql test < script. Все ошибки, сообщения о которых будут направлены в список рассылки, будут либо исправлены, либо включены в список ошибок в следующей версии MySQL! Если необходимо только небольшое изменение кода, мы также отправим исправляющую эту ошибку заплатку для программы.

• <[email protected]> bugs-digest

  Список bugs в виде сборника.

• <[email protected]> internals

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

• <[email protected]> internals-digest

  Версия в виде сборника для списка internals.

• <[email protected]> java

  Обсуждение вопросов, связанных с MySQL и Java. В основном обсуждение по драйверам JDBC включая MySQL Connector/J.

• <[email protected]> java-digest

  Версия в виде сборника для списка java.

• <[email protected]> win32

  Все вопросы, касающиеся программного обеспечения MySQL в операционных системах Microsoft, таких как Windows 9x/Me/NT/2000/XP.

• <[email protected]> win32-digest

  Версия в виде сборника для списка win32.

• <[email protected]> myodbc

  Все вопросы, касающиеся соединения MySQL через ODBC.

• <[email protected]> myodbc-digest

  Версия в виде сборника для списка myodbc.

• <[email protected]> mysqlcc

  Все вопросы, касающиеся графического клиента MySQL Control Center (MyCC).

• <[email protected]> mysqlcc-digest

  Версия в виде сборника для списка mysqlcc.

• <[email protected]> plusplus

  Все вопросы, касающиеся программирования на C++ API для MySQL.

• <[email protected]> plusplus-digest

  Версия в виде сборника для списка plusplus.

• <[email protected]> msql-mysql-modules

  Список по поддержке Perl для MySQL при помощи msql-mysql-modules.

• <[email protected]> msql-mysql-modules-digest

  Версия в виде сборника для списка msql-mysql-modules.

Подписаться или отказаться от подписки на все списки рассылки можно способом, указанным выше. В своем сообщении о подписке или отказе от подписки вместо mysql просто укажите соответствующее название списка рассылки. Например, чтобы подписаться на список рассылки myodbc или отказаться от подписки на него, следует отправить сообщение по адресу <[email protected]> или <[email protected]>.

Если получить ответы на свои вопросы в списке рассылки не удалось, можно оплатить поддержку от MySQL AB - это позволит вам напрямую общаться с разработчиками MySQL. See Раздел 1.6.1, «Поддержка, предлагаемая компанией MySQL AB».

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

• <[email protected]> Французский список рассылки, <[email protected]> Корейский список рассылки

  Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql [email protected].

• <[email protected]> Немецкий список рассылки

  Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql-de [email protected]. Информацию по этому списку рассылки можно найти на http://www.4t2.com/mysql/.

• <[email protected]> Португальский список рассылки

  Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql-br [email protected].

• <[email protected]> Испанский список рассылки

  Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql [email protected].

1.8.1.2. Как задавать вопросы и направлять сообщения об ошибках

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

• Сначала проведите поиск в интерактивном руководстве по MySQL на: http://www.mysql.com/doc/

  Мы стараемся постоянно обновлять данное руководство, добавляя информацию об исправлениях последних обнаруженных ошибок! Приложение, описывающее историю изменений (http://www.mysql.com/doc/en/News.html) также может быть полезным, т.к. вполне возможно, что именно в новой версии уже есть решение вашей проблемы.

• Посмотрите в базе данных ошибок по адресу http://bugs.mysql.com. Может, известная ошибка уже сообщена и исправлена.

• Просмотрите архивы списка рассылки MySQL: http://lists.mysql.com/

• Можно также воспользоваться ссылкой http://www.mysql.com/search/, чтобы произвести поиск по всем веб-страницам (включая руководство), расположенным на веб-узле http://www.mysql.com/.

Если в руководстве или архивах не удалось найти ответ, обратитесь к локальному эксперту по MySQL. Если же и таким образом не удалось получить ответы на вопросы, переходите к следующему разделу, в котором описано, как отправлять почту на <[email protected]>.

1.8.1.3. Как отправлять отчеты об ошибках или проблемах

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

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

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

Обычно отчеты об ошибках и проблемах направляются в <[email protected]>. Если же вы можете создать подробное описание, четко определяющее ошибку, его можно направить в список рассылки <[email protected]>. Обратите внимание: в этот список рассылки можно посылать только полный отчет о повторяющейся ошибке, составленный при помощи сценария mysqlbug. Если вы работаете в Windows, необходимо включить описание операционной системы и версии MySQL. Прежде чем направлять отчет, желательно проверить, проявляется ли данная проблема при использовании последней окончательной или находящейся в стадии разработки версии MySQL! Чтобы любой желающий мог воспроизвести эту ошибку, желательно также включить в отчет контрольный тестовый пример, который можно было бы запустить при помощи ``mysql test < script'', либо Perl-сценарий или сценарий оболочки, которые можно запустить непосредственно. Все ошибки, сообщения о которых будут направлены в список рассылки, будут либо исправлены, либо включены в список ошибок в следующей версии MySQL! Если необходимо только небольшое изменение кода, мы также отправим исправляющий эту ошибку патч для программы.

Если вы нашли ошибку в системе безопасности MySQL, необходимо отправить сообщение по адресу <[email protected]>.

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

Чаще всего наши корреспонденты не указывают используемую версию MySQL или платформу, на которой установлен сервер MySQL (включая версию платформы). Это довольно существенная информация, и в 99 случаях из 100 отчет об ошибке без нее будет совершенно бесполезным! Очень часто бывает и так: мы получаем вопрос типа: ''Почему это у меня не работает?'', а потом оказывается, что указанная функция в данной версии MySQL отсутствует или что ошибка, описанная в отчете, уже была исправлена в более новой версии MySQL. Иногда ошибка зависит от используемой платформы. В таких случаях практически невозможно ничего исправить, не имея информации об операционной системе и о версии платформы.

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

Вы окажете нам значительную помощь, включив в отчет об ошибке подробное описание проблемы. В качестве хорошего примера подобной информации можно привести описание всех действий, которые привели к возникновению проблемы и описание самой проблемы. Лучшие отчеты содержат подробные примеры, в которых показано, как можно воспроизвести ошибку или проблему. Раздел E.1.6, «Создание контрольного примера при повреждении таблиц».

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

Если возникли проблемы с MyODBC, необходимо попытаться создать файл трассировки MyODBC. See Раздел 8.3.7, «Составление отчетов о проблемах с MyODBC».

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

В свой отчет вам необходимо включить следующую информацию:

• Версию используемого дистрибутива MySQL (например MySQL Version 3.22.22). Чтобы узнать, какая версия запущена, следует выполнить команду mysqladmin version. Программу mysqladmin можно найти в каталоге bin инсталляционного каталога MySQL.

• Производителя и модель компьютера, на котором вы работаете.

• Название и версию операционной системы. Для большинства операционных систем эту информацию можно получить, выполнив команду Unix uname -a.

• Иногда важную роль играет количество памяти (реальной и виртуальной). Если у вас есть основания считать, что такая информация может оказаться полезной, включите в отчет эти значения.

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

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

• Если произошло аварийное завершение работы mysqld, необходимо сообщить о запросе, который привел к такому завершению. Это можно выяснить, запустив mysqld с включенной функцией ведения журнала. See Раздел E.1.5, «Использование журналов для определения причин ошибок в mysqld».

• Если с программой связана какая-либо таблица базы данных, включите в отчет выходную информацию команды mysqldump --no-data db_name tbl_name1 tbl_name2 .... Выполняется это очень легко. Таким способом можно получить подробную информацию о таблице в базе данных, что поможет нам создать ситуацию, соответствующую той, в которой оказались вы.

• Для ошибок, связанных со скоростью выполнения или проблемами с операторами SELECT, всегда необходимо включать в отчет выходную информацию команды EXPLAIN SELECT ... и, по крайней мере, количество строк, которые выдает оператор SELECT. Вы также должны включить вывода SHOW CREATE TABLE ... для каждой таблицы, задействованной в запросе. Чем больше информации будет предоставлено о сложившейся ситуации, тем больше шансов, что будет оказана надлежащая помощь! Например, ниже приведен образец очень хорошего отчета об ошибке (он, конечно, должен быть отправлен при помощи сценария mysqlbug):

  Пример запускается при помощи командной строки mysql (обратите внимание на применение терминатора операторов \G, который используется для операторов, если ширина выводимой ими информации превышает ширину строки 80-символьного дисплея):

  mysql> SHOW VARIABLES;
  mysql> SHOW COLUMNS FROM ...\G
         <вывод SHOW COLUMNS>
  mysql> EXPLAIN SELECT ...\G
         <вывод EXPLAIN>
  mysql> FLUSH STATUS;
  mysql> SELECT ...;
         <Корокая версия вывода SELECT, включая время,
          затраченное на обработку запроса>
  mysql> SHOW STATUS;
         <вывод SHOW STATUS>
  

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

  Если вы можете создать воспроизводимый контрольный пример, его необходимо отправить на <[email protected]> для немедленного рассмотрения! Если сценарий обеспечить нельзя, необходимо, по крайней мере, включить в свое сообщение выходную информацию команды mysqladmin variables extended-status processlist, чтобы предоставить данные о работе системы!

• Если не удается создать контрольный пример в несколько строк, или если таблица тестирования слишком велика для отправления в список рассылки (более 10 строк), необходимо вывести содержимое таблиц при помощи команды mysqldump и создать файл README с описанием вашей проблемы.

  Запакуйте файлы при помощи tar и gzip или zip, и по ftp загрузите архив на ftp://support.mysql.com/pub/mysql/secret/. Затем отправьте краткое описание проблемы на <[email protected]>.

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

• Когда вы приводите пример ситуации, при которой возникает проблема, лучше сохранить действительные имена переменных, таблиц и т.п., вместо того, чтобы давать им новые имена. Иногда проблема может быть вызвана именем переменной или таблицы! Это довольно редкие случаи, но лучше, чтобы не терять времени, такую информацию отправить нам сразу. В конце концов, вам будет даже легче использовать данные, соответствующие реальной ситуации, и это во всех отношениях лучше для нас. Те же, кто не хотел бы показывать свои данные другим пользователям, могут загрузить файл по ftp на ftp://support.mysql.com/pub/mysql/secret/. Если данные действительно представляют собой секретную информацию, которую нельзя показывать даже нам, тогда можно привести пример, используя другие имена, но этот вариант следует оставить на крайний случай.

• Включите в отчет все параметры, указанные для важных программ, если это возможно. Например, приведите параметры, которые вы используете как для запуска сервера mysqld, так и для запуска клиентских программ MySQL. Параметры таких программ как mysqld и mysql, а также сценарий configure часто содержат ответы на многие вопросы и очень важны! Включить их в отчет не помешает в любом случае! Если используются какие-либо модули, такие как Perl или PHP, также укажите их версии.

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

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

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

• Укажите в своем почтовом сообщении, что вы просмотрели справочное руководство и почтовый архив - тогда будет видно, как вы пытались решить эту проблему самостоятельно.

• Если возникла синтаксическая ошибка, внимательно просмотрите свою программу! Если не удается найти никаких ошибок, может оказаться, что ваша версия MySQL не поддерживает используемый запрос. Если используется текущая версия в руководстве на http://www.mysql.com/doc/ не описан синтаксис, который вы используете, MySQL не поддерживает ваш запрос. В этом случае вы можете либо самостоятельно реализовать такой синтаксис, либо направить сообщение по адресу <[email protected]> и попросить либо предложить реализовать его! Если в руководстве описан используемый синтаксис, но у вас установлена более старая версия MySQL, необходимо проверить журнал изменений MySQL, чтобы узнать, когда был реализован данный синтаксис. В этом случае вы можете произвести обновление до более новой версии MySQL. See Приложение D, История изменений и обновлений MySQL.

• Если в результате ошибки ваши данные оказываются поврежденными, или возникают ошибки при обращении к какой-либо определенной таблице, сначала необходимо проверить, а потом попытаться восстановить таблицы при помощи команды myisamchk или CHECK TABLE и REPAIR TABLE. See Глава 4, Администрирование баз данных.

• Если повреждения ваших таблиц случаются часто, необходимо выяснить, когда и почему это происходит. В этом случае файл mysql-data-directory/`hostname`.err может содержать некоторую информацию о происходящем. See Раздел 4.9.1, «Журнал ошибок». Включите в отчет об ошибке всю важную информацию из этого файла. Обычно mysqld никогда не должна повреждать данные в таблицах, если не произошло никакого сбоя во время обновления! Если вам удалось найти причину ошибки в mysqld, нам будет гораздо проще оказать вам помощь в решении этой проблемы. See Раздел A.1, «Как определить, чем вызваны проблемы».

• Если это возможно, загрузите и установите последнюю версию MySQL Server и проверьте, не решена ли в ней ваша проблема. Все версии программного обеспечения MySQL проходят тщательное тестирование и должны работать без проблем. Мы делаем все возможное, чтобы сохранить обратную совместимость, поэтому при переходе с одной версии MySQL на другую никаких проблем не должно возникать. See Раздел 2.2.4, «Какую версию MySQL использовать».

Если вы пользователь, пользующийся официальной поддержкой, направьте отчет об ошибке на <[email protected]>, чтобы его рассмотрели в первую очередь, а также в соответствующий список рассылки, чтобы узнать, сталкивался ли кто-нибудь еще с этой проблемой (и, возможно, нашел решение).

Чтобы получить информацию по отчетам об ошибках в MyODBC, See Раздел 8.3.4, «Как сообщать о проблемах с MyODBC».

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

Если ответы направляются к вам индивидуально, не попадая в список рассылки, хорошим тоном считается составить отчет по полученным ответам и отправить его в список рассылки, чтобы другие пользователи смогли получить информацию, которая помогла решить вашу проблему!

1.8.1.4. Рекомендации по ответам на вопросы, направляемые в список рассылки

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

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

Не отправляйте сообщения из своего браузера с включенным режимом HTML! Многие пользователи не используют браузер для чтения почты!

1.8.2. Пользователи MySQL на IRC

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

Вот сети/каналы, известные нам на данный момент:

• freenode (см. список серверов на http://www.freenode.net/ )

  • #mysql В основном обсуждение MySQL, но вопросы по другим СУБД приветствуются.

  • #mysqlphp Вопросы про популярную связку MySQL+PHP

• EFnet (см. список серверов на http://www.efnet.org/)

  • #mysql Вопросы по MySQL.

Мы можем рекомендовать вам X-Chat для подключения к IRC-сети. X-Chat доступен как для Unix, так и для Windows по адресу: http://www.xchat.org/.

1.9. Насколько MySQL соответствует стандартам?

1.9.1. Каким стандартам соответствует MySQL ?

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

1.9.3. Расширения MySQL к ANSI SQL92

1.9.4. Отличия MySQL от ANSI SQL92

1.9.5. Известные ошибки и недостатки проектирования в MySQL

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

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

Одним из главных направлений разработки данного продукта является продолжение работы в области соответствия его стандартам ANSI 99, но не за счет ущерба для скорости или надежности. Мы без опаски добавляем к серверу MySQL расширения к SQL или поддержку не предусмотренных в SQL возможностей, если это заметно увеличивает удобство его использования для значительной части наших пользователей (одним из примеров такой стратегии является новый интерфейс HANDLER в версии сервера MySQL 4.0; see Раздел 6.4.2, «Синтаксис оператора HANDLER»).

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

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

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

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

1.9.1. Каким стандартам соответствует MySQL ?

Начальный уровень SQL92. Для ODBC уровни 0-3.51.

Мы стремимся к полной поддержке стандарта ANSI SQL99, но без ущерба для скорости и качества кода.

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

При запуске mysqld с опцией --ansi поведение сервера MySQL изменяется следующим образом:

• || представляет собой конкатенацию строк вместо ИЛИ (OR).

• Допускается любое количество пробелов между именем функции и скобкой ‘(’. Это заставляет MySQL интерпретировать все имена функций как зарезервированные слова.

• ‘"’ будет интерпретироваться как символ кавычки идентификатора (как символ кавычки ‘`’ сервера MySQL), а не как символ кавычки строки.

• REAL будет синонимом для FLOAT, а не для DOUBLE.

• Уровнем изоляции транзакций по умолчанию является SERIALIZABLE (see Раздел 6.7.3, «Синтаксис команды SET TRANSACTION»).

• Вы можете использовать столбец/выражение в GROUP BY, которое не перечислено в списке столбцов.

Использование данной опции равносильно применению --sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES, IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY.

1.9.3. Расширения MySQL к ANSI SQL92

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

SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...

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

CREATE /*!32302 TEMPORARY */ TABLE t (a int);

Это означает, что при наличии версии 3.23.02 или выше сервер MySQL будет использовать ключевое слово TEMPORARY.

Ниже приводится перечень расширений MySQL:

• Типы полей MEDIUMINT, SET, ENUM и различные типы BLOB и TEXT.

• Атрибуты полей AUTO_INCREMENT, BINARY, NULL, UNSIGNED и ZEROFILL.

• Все сравнения строк по умолчанию являются независимыми от регистра символов с порядком сортировки, заданным текущей кодировкой (ISO-8859-1 Latin1 по умолчанию). Если вас это не устраивает, то можно объявить столбцы с атрибутом BINARY или использовать явное приведение типов BINARY, в результате чего сравнение будет выполняться в соответствии с порядком ASCII, используемом на хосте сервера MySQL.

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

  Это правило имеет несколько следствий:

  • В сервере MySQL, работающем под операционными системами с зависимыми от регистра символов именами файлов (таковыми являются большинство Unix-систем), имена баз данных и имена таблиц являются зависимыми от регистра символов (see Раздел 6.1.3, «Чувствительность имен к регистру»).

  • Имена базы данных, таблицы, индекса, столбца или псевдонимы могут начинаться с цифры (но не должны содержать только цифры).

  • Можно использовать стандартную систему команд выполнения резервного копирования, переименования, перемещения, удаления и копирования таблиц. Например, для переименования таблицы необходимо переименовать соответствующие этой таблице файлы .MYD, .MYI и .frm.

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

• LIKE разрешается на числовых столбцах.

• Использование INTO OUTFILE и STRAIGHT_JOIN в команде SELECT (see Раздел 6.4.1, «Синтаксис оператора SELECT»).

• Опция SQL_SMALL_RESULT в команде SELECT.

• Использование EXPLAIN SELECT для получения описаний объединения таблиц.

• Использование индексных имен, индексов на префиксах полей, а также INDEX или KEY в команде CREATE TABLE (see Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»).

• Использование TEMPORARY или IF NOT EXISTS с CREATE TABLE.

• Использование COUNT(DISTINCT list), где list представляет собой более чем один элемент.

• Использование CHANGE col_name, DROP col_name или DROP INDEX, IGNORE или RENAME в команде ALTER TABLE (see Раздел 6.5.4, «Синтаксис оператора ALTER TABLE»).

• Использование RENAME TABLE. See Раздел 6.5.5, «Синтаксис оператора RENAME TABLE».

• Использование нескольких выражений ADD, ALTER, DROP или CHANGE в команде ALTER TABLE.

• Использование DROP TABLE с ключевыми словами IF EXISTS.

• Возможность удаления нескольких таблиц одной командой DROP TABLE.

• Условие LIMIT в команде DELETE.

• Условие DELAYED в командах INSERT и REPLACE.

• Условие LOW_PRIORITY в командах INSERT, REPLACE, DELETE и UPDATE.

• Использование LOAD DATA INFILE. Во многих случаях этот синтаксис совместим с применяющимся в Oracle LOAD DATA INFILE (see Раздел 6.4.9, «Синтаксис оператора LOAD DATA INFILE»).

• Команды ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE и REPAIR TABLE.

• Команда SHOW (see Раздел 4.5.6, «Синтаксис команды SHOW»).

• Строки могут быть заключены в кавычки с помощью или ‘"’, или ‘'’, но не просто ‘'’.

• Использование символа экранирования ‘\’.

• Команда SET (see Раздел 5.5.6, «Синтаксис команды SET»).

• Нет необходимости называть имена всех выбранных столбцов в части GROUP BY. Это дает лучшую производительность для некоторых очень специфических, но вполне нормальных запросов (see Раздел 6.3.7, «Функции, используемые в операторах GROUP BY»).

• Можно указывать ASC и DESC с GROUP BY.

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

• Сервер MySQL понимает операторы || и && для обозначения логических ИЛИ (OR) и И (AND), как это принято в языке программирования C. В сервере MySQL || и ИЛИ (OR) являются синонимами, так же, как && и И (AND). Благодаря этому удобному синтаксису, в сервере MySQL не поддерживается оператор ANSI SQL || для конкатенации строк: вместо него используется функция CONCAT(). Поскольку функция CONCAT() принимает любое количество аргументов, то в сервере MySQL можно легко модифицировать использование оператора ||.

• CREATE DATABASE или DROP DATABASE (see Раздел 6.5.1, «Синтаксис оператора CREATE DATABASE»).

• Оператор % является синонимом для MOD(). Т.е. N % M эквивалентно MOD(N,M). Оператор % поддерживается для программистов на C и для совместимости с PostgreSQL.

• Операторы =, <>, <=,<, >=,>, <<, >>, <=>, AND, OR или LIKE могут использоваться при сравнении столбцов слева от FROM в командах SELECT. Например:

  mysql> SELECT col1=1 AND col2=2 FROM tbl_name;
  

• Функция LAST_INSERT_ID() (see Раздел 8.4.3.31, «mysql_insert_id()»).

• Операторы 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() для усечения подстрок. В ANSI SQL поддерживается только удаление единичных символов.

• Операция GROUP BY для функций STD(), BIT_OR() и BIT_AND().

• Использование REPLACE вместо DELETE + INSERT (see Раздел 6.4.8, «Синтаксис оператора REPLACE»).

• Команды FLUSH, RESET и DO.

• Возможность устанавливать переменные в команде с помощью :=:

  SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table;
  SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
  

1.9.4. Отличия MySQL от ANSI SQL92

1.9.4.1. Вложенные SELECTы

1.9.4.2. Оператор SELECT INTO TABLE

1.9.4.3. Транзакции и атомарные операции

1.9.4.4. Хранимые процедуры и триггеры

1.9.4.5. Внешние ключи

1.9.4.6. Представления

1.9.4.7. Символы `--' как начало комментария

Наши усилия направлены на то, чтобы сервер MySQL соответствовал стандартам ANSI SQL и ODBC SQL, но в некоторых случаях сервер MySQL функционирует по-другому. Ниже приведен перечень таких отличий:

• Для столбцов VARCHAR при хранении величины концевые пробелы удаляются (see Раздел 1.9.5, «Известные ошибки и недостатки проектирования в MySQL»).

• В некоторых случаях столбцы CHAR без уведомления изменяются на столбцы VARCHAR (see Раздел 6.5.3.1, «Молчаливые изменения определений столбцов»).

• Привилегии для таблицы не аннулируются автоматически при удалении таблицы; чтобы удалить привилегии для таблицы, необходимо явно вызвать REVOKE (see Раздел 4.3.1, «Синтаксис команд GRANT и REVOKE»).

• NULL AND FALSE будет трактоваться как NULL, а не как FALSE. Причина здесь в том, что мы не считаем необходимым оценивать множество дополнительных условий для этого случая.

Если вас интересует, когда к серверу MySQL будут добавляться новые расширения, необходимо обратиться к онлайновому списку перспективных задач к выполнению, в котором дан их перечень в порядке приоритетности. Он находится по адресу http://www.mysql.com/doc/en/TODO.html. Это самая последняя версия списка задач к выполнению (TODO list) в данном руководстве (see Раздел 1.10, «MySQL и будущее (что предстоит сделать)»).

1.9.4.1. Вложенные SELECTы

В сервер MySQL поддерживает вложенные запросы вида INSERT ... SELECT ... и REPLACE ... SELECT .... В других контекстах можно использовать и функцию IN().

Вложенные операции выборки реализованы в версии 4.1.

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

SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);

можно переписать следующим образом:

SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id;

Запросы:

SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE NOT EXISTS (SELECT id FROM table2
         WHERE table1.id=table2.id);

эквивалентны следующему:

SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
                WHERE table2.id IS NULL;

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

Первый вариант следующий: при помощи какого-либо процедурно-ориентированного языка программирования (такого как Perl или PHP) делается запрос SELECT для получения первичных ключей тех записей, которые должны быть удалены, а затем полученные величины используются для составления команды DELETE (DELETE FROM ... WHERE ... IN (key1, key2, ...)).

Второй вариант предполагает применение диалогового SQL для автоматического создания набора команд DELETE с использованием расширения MySQL CONCAT() (вместо стандартного оператора ||). Например:

SELECT CONCAT('DELETE FROM tab1 WHERE pkid = ', "'", tab1.pkid, "'", ';')
       FROM tab1, tab2
       WHERE tab1.col1 = tab2.col2;

Можно поместить этот запрос в файл скрипта, перенаправить стандартный вход клиента командной строки с этого файла, а стандартный выход - на еще один экземпляр клиента командной строки:

shell> mysql --skip-column-names mydb < myscript.sql | mysql mydb

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

1.9.4.2. Оператор SELECT INTO TABLE

Для сервера MySQL пока не реализована поддержка расширения Oracle SQL: SELECT ... INTO TABLE .... Вместо этого сервер MySQL поддерживает синтаксис ANSI SQL INSERT INTO ... SELECT ..., который, по существу, представляет собой то же самое (see Раздел 6.4.3.1, «Синтаксис оператора INSERT ... SELECT»).

INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID
       FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100;

Можно также использовать выражения SELECT INTO OUTFILE... или CREATE TABLE ... SELECT.

1.9.4.3. Транзакции и атомарные операции

Поддержка транзакций в сервере MySQL реализуется при помощи обработчиков транзакционных таблиц типов InnoDB и BDB (see Глава 7, Типы таблиц MySQL). Таблицы InnoDB обеспечивают соответствие требованиям ACID.

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

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

1. Транзакционная парадигма обеспечивает следующие возможности: если приложения написаны таким образом, что в критических ситуациях зависят от вызова ROLLBACK вместо COMMIT, то транзакции предпочтительней атомарных операций. Транзакции также обеспечивают гарантию того, что незаконченные обновления или искаженные действия не будут фиксироваться в базе данных; серверу предоставляется возможность выполнить автоматический откат, и база данных будет сохранена. Почти во всех случаях при работе с сервером MySQL решить возможные проблемы можно путем включения простых проверок перед обновлениями и запуска простых скриптов, которые выполняют проверку баз данных на нарушение целостности с автоматическим исправлением повреждений или выдачей предупреждения, если такое нарушение возникает. Отметим, что полноценное выявление и устранение ошибок в таблицах без потери целостности данных можно обеспечить, просто используя системный журнал MySQL или добавив еще один дополнительный журнал.

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

3. Даже в транзакционной системе возможна потеря данных в случае внезапной остановки сервера (если сервер ``упадет''). Разница между различными системами состоит только в том, насколько мал промежуток времени, в течение которого данные могут быть потеряны. Ни одна система не является надежной на 100%, только ``достаточно надежной''. Даже для сервера Oracle (эта база данных считается наиболее надежной транзакционной базой данных), по сообщениям, в подобных ситуациях иногда возможна потеря данных. Что же касается использования сервера MySQL, то в любом случае, независимо от того, применяются или нет транзакционные таблицы, для обеспечения безопасности необходимо только иметь резервные копии и включенную регистрацию обновлений. Благодаря этим мерам в MySQL, так же как и в других транзакционных базах данных, можно восстановить информацию в любой ситуации. Резервные копии вообще хорошо иметь всегда, независимо от того, какая база данных используется.

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

В ситуациях, где целостность данных чрезвычайно важна, сервер MySQL обеспечивает даже для нетранзакционных таблиц надежность и целостность данных уровня транзакций или лучше. При блокировании таблиц с помощью LOCK TABLES все обновления останавливаются до тех пор, пока не будут выполнены все проверки на целостность. При наличии только блокировки чтения (в противоположность блокировке записи) операции чтения и вставки, тем не менее, производятся. Новые внесенные записи не будут видны никому из имеющих блокировку чтения клиентов до освобождения этих блокировок. С iомощью INSERT DELAYED вставки становятся в очередь и находятся там до тех пор, пока не будут сняты все блокировки. При этом клиент не вынужден ждать, пока отработает INSERT (see Раздел 6.4.4, «Синтаксис оператора INSERT DELAYED»).

То, что мы подразумеваем под термином ``атомарные'', не означает ничего сверхъестественного. Имеется в виду лишь следующее: гарантируется, что при выполнении каждого конкретного обновления никакой другой пользователь не может повлиять на него и никогда не произойдет автоматического отката (который возможен на транзакционных таблицах, если не приняты должные меры предосторожности). Сервер MySQL также гарантирует, что не случится грязного чтения (dirty read)".

Ниже описаны некоторые технические приемы работы с нетранзакционными таблицами:

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

• Чтобы избежать применения ROLLBACK, можно использовать следующую стратегию:

  • Применить LOCK TABLES ... для блокирования всех таблиц, к которым необходим доступ.

  • Проверить условия.

  • Обновить, если все в порядке.

  • Использовать UNLOCK TABLES для освобождения произведенных блокировок.

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

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

  • Поля модифицируются относительно их текущей величины.

  • Обновляются только те поля, которые действительно изменились.

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

  UPDATE tablename SET pay_back=pay_back+'relative change';
  UPDATE customer
    SET
      customer_date='current_date',
      address='new address',
      phone='new phone',
      money_he_owes_us=money_he_owes_us+'new_money'
    WHERE
      customer_id=id AND address='old address' AND phone='old phone';
  

  Как можно видеть, этот способ очень эффективно и работает, даже если другой клиент изменит величины в столбцах pay_back или money_he_owes_us.

• Во многих случаях пользователи хотят применять ROLLBACK и/или LOCK TABLES для управления уникальными идентификаторами для разных таблиц. Того же результата можно добиться намного более эффективно, используя столбец AUTO_INCREMENT и либо SQL-функцию LAST_INSERT_ID(), либо функцию C API mysql_insert_id() (see Раздел 8.4.3.31, «mysql_insert_id()»).

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

  UPDATE tbl_name SET row_flag=1 WHERE id=ID;
  

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

  UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
  

1.9.4.4. Хранимые процедуры и триггеры

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

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

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

1.9.4.5. Внешние ключи

Следует учитывать, что в SQL внешние ключи используются не для объединения таблиц, а главным образом для проверки целостности ссылочных данных (ограничения внешних ключей). Если необходимо получить результаты из большого количества таблиц от команды SELECT, следует делать это через объединение таблиц:

SELECT * FROM table1,table2 WHERE table1.id = table2.id;

См. разделы Раздел 6.4.1.1, «Синтаксис оператора JOIN» и See Раздел 3.5.6, «Использование внешних ключей».

В версии сервера MySQL 3.23.44 и выше таблицы InnoDB поддерживают проверку ограничений внешних ключей (see Раздел 7.5, «Таблицы InnoDB»). Для таблиц других типов сервер MySQL производит анализ синтаксиса FOREIGN KEY в командах CREATE TABLE, но без выполнения дальнейших действий.

Синтаксис FOREIGN KEY без ON DELETE ... главным образом применяется для целей документирования. В некоторых ODBC-приложениях его можно использовать для автоматического создания выражений WHERE, но обычно это легко сделать вручную. FOREIGN KEY иногда используется в качестве проверки ограничений, но на практике такая проверка не является необходимой, если строки вносятся в таблицу в правильном порядке.

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

В версии сервера MySQL 4.0 можно использовать многотабличное удаление, чтобы удалить строки из многих таблиц одной командой (see Раздел 6.4.6, «Синтаксис оператора DELETE»).

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

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

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

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

• Использование каскадных обновлений и удалений может упростить код клиента.

• Должным образом разработанные правила внешних ключей помогают в документировании отношений между таблицами.

Недостатки:

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

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

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

1.9.4.6. Представления

Представления планируется реализовать примерно в версии сервера MySQL 5.0.

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

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

Для сервера MySQL нет необходимости в применении представлений для ограничения доступа к столбцам, так как в нем реализована хорошо продуманная система привилегий (see Раздел 4.2, «Общие проблемы безопасности и система привилегий доступа MySQL»).

1.9.4.7. Символы `--' как начало комментария

В некоторых отличных от MySQL базах данных SQL символы '--' используются как начальные символы комментариев. В сервере MySQL символом начала комментариев является ‘#’. Для сервера MySQL можно также использовать стиль комментирования из C: /* this is a comment */ (see Раздел 6.1.6, «Синтаксис комментариев»).

В версии сервера MySQL 3.23.3 и выше поддерживается комментирование с помощью символов '--' - при условии, что за комментарием следует пробел. Это объясняется тем, что данный стиль комментирования вызвал много проблем при автоматической генерации SQL-запросов, в которых присутствовал код, подобный приведенному ниже (величина платежа вставляется в выражение !payment! автоматически):

UPDATE tbl_name SET credit=credit-!payment!

Давайте представим себе, что произойдет в случае, если величина payment окажется отрицательной. Поскольку выражение 1--1 в SQL является допустимым, то просто страшно себе вообразить последствия в случае, если будут разрешены комментарии, начинающиеся с '--',

Использование нашей реализации этого метода комментирования в версии сервера MySQL 3.23.3 и выше - в форме 1-- This is a comment - является действительно безопасным.

Существует еще один безопасный способ решения этой проблемы. Он заключается в том, что клиент командной строки mysql удаляет все строки, начинающиеся с '--'.

Приведенная ниже информация относится только к работе более ранних, чем 3.23.3, версий MySQL.

Если ваша SQL-программа представлена в виде текстового файла, содержащего комментарии '--', необходимо использовать:

shell> replace " --" " #" < text-file-with-funny-comments.sql \
  | mysql database

вместо обычного:

shell> mysql database < text-file-with-funny-comments.sql

Можно также отредактировать сам командный файл, заменив комментарии '--' комментариями ‘#’:

shell> replace " --" " #" -- text-file-with-funny-comments.sql

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

shell> replace " #" " --" -- text-file-with-funny-comments.sql

1.9.5. Известные ошибки и недостатки проектирования в MySQL

1.9.5.1. Ошибки, известные в 3.23 и исправленные в более поздних версиях MySQL

1.9.5.2. Открытые ошибки / особенности строения MySQL

1.9.5.1. Ошибки, известные в 3.23 и исправленные в более поздних версиях MySQL

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

• Можно получить взаимоблокировку при помощи LOCK TABLE на множестве таблиц, а затем выполнив в том же соединениии DROP TABLE одной из таблиц, пока другой поток пытается получить блокировку на таблицу. Однако можно уничтожить (KILL) эти потоки с тем, чтобы ситуация была исправлена. Исправлено в 4.0.12.

• SELECT MAX(key_column) FROM t1,t2,t3... где одна из таблиц является пустой не вернет NULL, но вместо этого вернет максимальное значение для столбца. Исправлено в 4.0.11.

1.9.5.2. Открытые ошибки / особенности строения MySQL

Устранение следующих из выявленных проблем относится к числу первоочередных задач:

• ANALYZE TABLE на таблицах BDB в некоторых случаях может сделать таблицу недоступной для использования, пока не произойдет перезапуск mysqld. При этом в файле ошибок MySQL можно будет увидеть ошибки, подобные следующим:

  001207 22:07:56 bdb: log_flush: LSN past current end-of-log
  

• Не следует выполнять ALTER TABLE на таблицах BDB, на которых осуществляются многокомандные транзакции, пока все эти транзакции не завершатся (возможно, данные транзакции будут проигнорированы).

• ANALYZE TABLE, OPTIMIZE TABLE и REPAIR TABLE могут вызвать проблемы на таблицах, для которых используется INSERT DELAYED.

• Выполнение LOCK TABLE ... и FLUSH TABLES ... не гарантирует, что на данной таблице нет исполняемых в текущий момент незаконченных транзакций.

• Открытие таблиц BDB происходит несколько медленно. Если база данных содержит много таблиц BDB, то потребуется значительное время для использования клиента mysql на этой базе данных, если не применять опцию -A или если использовать rehash. Это особенно заметно при наличии большого табличного кэша.

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

• При использовании функции RPAD, или любой другой строковой функции, добавляющией пробелы в правую часть строки, в запросе, для которого MySQL будет создавать временные таблицы для его выполнения, все результирующие строки будут в результате обработаны RTRIM'ом (RTRIM'ed). Вот пример запроса:

  SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

  В результате невозможно получить пробелы в правой части результирующего столбца.

  Такое поведение присутствует во всех версиях MySQL.

  Причина заключается в том, что HEAP-таблицы, которые в первую очередь используются для временных таблиц, неспособны работать с VARCHAR-столбцами.

  Такое поведение будет исправлено в одной из версий 4.1.

• При использовании SET CHARACTER SET нельзя использовать преобразованные символы в именах базы данных, таблицы и столбца.

• Нельзя использовать _ или % с ESCAPE в LIKE ... ESCAPE.

• Если в столбце DECIMAL число хранится в различных форматах (+01.00, 1.00, 01.00), то GROUP BY может рассматривать каждую величину как самостоятельную.

• DELETE FROM merge_table при использовании без WHERE будет очищать только отображение для этой таблицы, а не удалять все данные в отображенных таблицах.

• При использовании потоков MIT-pthreads нельзя расположить сервер в ином каталоге. Поскольку для решения данной проблемы требуются изменения для потоков MIT-pthreads, маловероятно, что мы ее устраним (see Раздел 2.3.6, «Замечания по потокам MIT-pthreads»).

• Не обеспечивается ``надежное'' применение величин BLOB в GROUP BY или ORDER BY или DISTINCT. В этих случаях при сравнении величин BLOB используются только первые max_sort_length байтов (по умолчанию 1024). Это можно изменить с помощью опции -O max_sort_length для mysqld. Обходной путь для большинства случаев заключается в использовании подстроки: SELECT DISTINCT LEFT(blob,2048) FROM tbl_name.

• В сервере MySQL вычисления производятся в форматах типов BIGINT или DOUBLE (оба типа обычно имеют длину 64 бита). Это зависит от того, какую точность обеспечивает применяемая функция. Общее правило состоит в том, что битовые функции работают с точностью BIGINT, функции IF и ELT() - с точностью BIGINT или DOUBLE, а остальные - с точностью DOUBLE. Следует избегать применения беззнаковых величин двойной точности, если они могут превысить 63 бита (9223372036854775807), для каких-либо величин, кроме битовых полей! В версии сервера MySQL 4.0 реализована лучшая обработка BIGINT, чем в 3.23.

• Во всех строковых столбцах, исключая BLOB и TEXT при извлечении данных автоматически удаляются все концевые пробелы. Для типов CHAR это хорошо и может рассматриваться как свойство, соответствующее ANSI SQL92. Ошибка заключается в том, что в сервере MySQL столбцы VARCHAR трактуются тем же самым образом.

• В одной таблице может быть только до 255 столбцов типа ENUM и SET.

• В MIN(), MAX() и других групповых функциях, MySQL сейчас сравнивает ENUM и SET-столбцы по их строковому значению, а не по относительной позиции строки в множестве.

• При указании параметра safe_mysqld все сообщения из mysqld направляются в журнал данного потока mysqld. Одна из проблем заключается в том, что если вы исполняете mysqladmin refresh для того, чтобы закрыть и заново открыть журнал, то stdout и stderr будут все еще по-прежнему направлены в старый журнал. При активном использовании --log следует отредактировать safe_mysqld, чтобы записи велись в `hostname`.err, а не в `hostname`.log, с тем, чтобы вы могли очищать пространство, удаляя старые журналы и вызывая mysqladmin refresh.

• При выполнении команды UPDATE столбцы обновляются слева направо. При ссылке на обновленный столбец вместо исходной величины будет получена обновленная величина. Например:

  mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
  

  Эта команда обновит KEY со значением 2 вместо значения 1.

• В одном и том же запросе нельзя использовать временные таблицы более чем один раз. Например, следующая команда выполнена не будет:

  mysql> SELECT * FROM temporary_table, temporary_table AS t2;
  

• RENAME не работает с временными таблицами или при использовании таблицы MERGE.

• Оптимизатор может обрабатывать DISTINCT по-разному, в зависимости от того, используются или нет в объединении ``скрытые'' столбцы. В объединении скрытые столбцы считаются частью результата (даже если они не показываются), в то время как в обычных запросах скрытые столбцы не участвуют в сравнении DISTINCT. Возможно, в будущем мы изменим это правило таким образом, чтобы при выполнении DISTINCT скрытые столбцы никогда не сравнивались. Например:

  SELECT DISTINCT mp3id FROM band_downloads
         WHERE userid = 9 ORDER BY id DESC;
  

  и

  SELECT DISTINCT band_downloads.mp3id
         FROM band_downloads,band_mp3
         WHERE band_downloads.userid = 9
         AND band_mp3.id = band_downloads.mp3id
         ORDER BY band_downloads.id DESC;
  

  Во втором случае в версии сервера MySQL 3.23.x можно получить две идентичных строки в результирующем наборе данных (поскольку скрытый столбец id может варьироваться). Заметьте, что это случается только с запросами, где в результате отсутствуют столбцы ORDER BY, что не разрешается делать в ANSI SQL.

• Поскольку сервер MySQL обеспечивает возможность работать с типами таблиц, которые не поддерживают транзакции и, следовательно, не допускают отката данных, то поведение сервера MySQL в некоторых аспектах отличается от других серверов SQL. Это делается, чтобы гарантировать, что сервер MySQL никогда не будет нуждаться в откате SQL-команд. Такое поведение временами может быть несколько неудобным, так как вследствие этого величины столбцов должны проверяться в приложении. Однако благодаря такому решению вы получаете действительно хорошее увеличение скорости, поскольку для сервера MySQL обеспечивается возможность производить определенные оптимизации, что в противном случае было бы очень трудно сделать. При попытке установить столбец в некорректную величину сервер MySQL вместо выполнения отката будет сохранять в данном столбце ``наиболее вероятную величину'':

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

  • При попытке сохранить в числовом столбце строку, которая начинается не с числа, сервер MySQL будет сохранять в нем 0.

  • При попытке сохранить NULL в числовом столбце, который не принимает значения величины NULL, сервер MySQL вместо NULL будет сохранять 0 или '' (пустая строка) (однако это поведение можно изменить с помощью опции компиляции -DDONT_USE_DEFAULT_FIELDS).

  • MySQL обеспечивает возможность сохранять некоторые ошибочные величины даты в столбцах DATE и DATETIME (такие как 2000-02-31 или 2000-02-00). Идея заключается в том, что задача проверки валидности даты не входит в круг обязанностей сервера баз данных. Если MySQL может сохранить и корректно воспроизвести какие-либо значение даты, пусть и неправильное - MySQL будет сохранять такое значение. Если дата полностью неправильна, сервер MySQL будет сохранять в этом столбце специальную величину даты 0000-00-00.

  • Если устанавливать столбец ENUM в неподдерживаемую величину, то он будет устанавливаться в значение ошибки empty string с числовым значением 0.

  • Если устанавливать столбец SET в неподдерживаемую величину, то эта величина будет игнорироваться.

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

• При создании таблицы типа MERGE не происходит проверки, если лежащие в ее основе таблицы имеют совместимые типы.

• Сервер MySQL пока еще не может обрабатывать величины NaN, -Inf и Inf с двойной точностью. Их использование вызовет проблемы при попытке экспорта или импорта данных. В качестве промежуточного решения мы должны изменить NaN на NULL (если возможно) и -Inf и Inf на минимальную или, соответственно, максимально возможную величину двойной точности.

• LIMIT на отрицательных числах трактуются как большие положительные числа.

• Если ALTER TABLE используется для того, чтобы сначала добавить индекс UNIQUE к таблице, которая входит в таблицу MERGE, а затем - чтобы добавить обычный индекс к таблице MERGE, то в случае, если существовал старый ключ, который не был уникальным в данной таблице, порядок ключей для таблиц будет различным. Это обусловлено тем, что ALTER TABLE помещает уникальные ключи перед обычными ключами, чтобы обеспечить возможность определять дублирующиеся ключи как можно раньше.

В более ранних версиях MySQL известны следующие ошибки:

• Можно получить зависший поток при выполнении DROP TABLE на таблице, которая является одной из числа многих таблиц, заблокированных с помощью LOCK TABLES.

• В следующем случае может произойти аварийное завершение процесса:

  • Обработчик задержанных вставок имеет незаконченные вставки в таблицу.

  • LOCK table с помощью WRITE.

  • FLUSH TABLES.

• В версиях сервера MySQL до 3.23.2 команда UPDATE, которая обновляла ключ с помощью WHERE на тот же самый ключ, может оказаться неудачной, поскольку данный ключ использовался для поиска записей и одна и та же строка может быть найдена много раз:

  UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;
  

  Обходным решением является использование:

  mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;
  

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

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

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

1.10. MySQL и будущее (что предстоит сделать)

1.10.1. Что планируется реализовать в версии в 4.0

1.10.2. Что планируется реализовать в версии 4.1

1.10.3. Что планируется реализовать в версии 5.0

1.10.4. Что должно быть сделано в ближайшем будущем

1.10.5. То, что надо сделать когда-нибудь

1.10.6. То, чего не планируется делать

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

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

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

1.10.1. Что планируется реализовать в версии в 4.0

Уже все сделано. Сейчас мы только исправляем обнаруженные ошибки в MySQL 4.0. See Раздел D.2, «Изменения в версии 4.0.x (В разработке; Альфа)». Сейчас ведется разработка версий 4.1 и 5.0.

1.10.2. Что планируется реализовать в версии 4.1

Следующие возможности планируются для реализации в MySQL 4.1. Список того, что уже сделано, можно найти в See Раздел D.1, «Изменения в версии 4.1.x (Alpha)».

• Стабильная поддержка OpenSSL (MySQL 4.0 поддерживает базовую, не 100%-протестированную поддержку OpenSSL).

• Схема перекодировки и синтаксис для поддержки множества разных кодировок.

• Встроенная помощь для всех команд из клиента командной строки.

• Больше тестирования подготовленных выражений и множественных кодировок для одной таблицы.

1.10.3. Что планируется реализовать в версии 5.0

Перечисленные ниже функции планируется реализовать в MySQL 5.0.

Отметим также, что поскольку у нас над новыми проектами работает большое количество разработчиков, появятся и дополнительные возможности. Существует - хотя и очень небольшая - вероятность, что эти возможности будут введены уже в MySQL 4.1. Список того, что уже сделано в 4.1, можно найти в See Раздел D.1, «Изменения в версии 4.1.x (Alpha)».

• Хранимые процедуры

• Поддержка внешних ключей для всех типов таблиц.

• Новый текстовый формат файлов определения структуры таблиц (.frm-файлы) и табличный кэш для определений таблиц. Это позволит нам быстрее получать информацию о структуре таблиц и более качественно поддерживать внешние ключи.

• SHOW COLUMNS FROM table_name (используемый клиентом mysql для получения информации о столбцах) не должен открывать таблицы, а только файл определения структуры. Это занимает меньше памяти и будет работать быстрее.

• Отказобезопасная репликация.

• Резервное копирование без остановки работы системы с очень малыми затратами на выполнение. Резервное копирование без остановки работы системы позволит добавлять новый подчиненный сервер репликации без демонтажа головного сервера.

• ROLLUP и CUBE OLAP (Online Analytical Processing) опции группировки для приложения хранения данных (Data warehousing).

• Обеспечить возможность для DELETE, работающей с MyISAM-таблицами, использовать кэш записей. Чтобы осуществить это, нам необходимо обновлять кэш записей потока при обновлении .MYD-файла.

• При использовании SET CHARACTER SET мы должны преобразовать весь запрос целиком, а не только строки. Это позволит пользователям использовать сконвертированные символы в именах баз данных, таблиц и столбцов.

• Решить проблему, заключающуюся в том, что оператор RENAME TABLE, использующийся для активной MERGE-таблицы, может повредить таблицу.

• Добавить к клиент-серверному протоколу возможность получения информации о прогрессе выполнения для сложных и длительных запросов.

• Реализовать RENAME DATABASE. Чтобы сделать эту команду безопасной для всех обработчиков таблиц, она будет работать следующим образом:

  • Создавать новую базу данных.

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

  • Удалять старую базу данных.

  • Добавить корректную поддержку VARCHAR (такая поддержка уже имеется для MyISAM).

• Оптимизировать тип BIT, чтобы он занимал 1 бит (сейчас 1 символ).

• Новое изменение внутреннего файлового интерфейса. Это позволит сделать обработку всех файлов более однотипной и упростит добавление такой функциональности, как RAID (текущая реализация - это просто хак).

• Улучшенные таблицы в памяти (HEAP):

  • Записи динамического размера

  • Более быстрая обработка строк (сокращение операций копирования)

1.10.4. Что должно быть сделано в ближайшем будущем

• Не разрешать более чем определенному количеству потоков одновременно заниматься восстановлением MyISAM-таблиц.

• Изменение INSERT ... SELECT с целью оптимального использования одновременных вставок.

• Возвращать истинные типы полей при выполнении SELECT MIN(столбец) GROUP BY.

• Множественные результаты.

• Сделать возможным задание long_query_time с градацией в микросекундах.

• Cлинковать код myisampack прямо в сервер.

• Перенос кода MySQL на QNX.

• Перенос кода MySQL на BeOS.

• Перенос MySQL-клиентов на LynxOS.

• Добавление временного буферного кэша ключей во время выполнения INSERT/DELETE/UPDATE, чтобы обеспечить изящное восстановление в случае, если индексный файл окажется полностью заполненным.

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

• Реализация типа DATE/DATETIME с корректной обработкой информации о временных зонах, чтобы упростить работу с форматом даты для различных временных зон.

• FreeBSD и MIT-pthreads; отнимают ли спящие потоки время процессора?

• Проверить, занимают ли блокированные потоки время процессора.

• Исправить configure так, чтобы можно было компилировать все библиотеки (подобно MyISAM) без потоков.

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

• Возможность связывания по частям ключа (проблема оптимизации).

• INSERT SQL_CONCURRENT и mysqld --concurrent-insert для выполнения одновременной вставки в конец файла, если файл закрыт для чтения.

• Серверные курсоры.

• Проверить, работает ли lockd с современными ядрами Linux; если нет, то внести исправления в lockd! Чтобы это протестировать, необходимо запустить mysqld с --enable-locking и выполнить различные наборы тестов на fork*. Они не должны выявить никаких ошибок, если lockd работает.

• Возможность использования SQL-переменных в LIMIT, как, например, в LIMIT @a,@b.

• Возможность обновления переменных в операторах UPDATE. Например: UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c.

• Изменение: если пользовательские переменные обновляются, то сделать так, чтобы их можно было использовать с GROUP BY, как в следующем примере: SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id.

• Запретить автоматическое внесение DEFAULT-значений (значений по умолчанию) в столбцы. Выдавать ошибку в случае использования INSERT, не содержащего столбца, для которого не определено значение по умолчанию.

• Исправить libmysql.c так, чтобы две команды mysql_query(), идущие подряд, могли работать без чтения результатов или с выдачей хорошего сообщения об ошибке, если это все-таки происходит.

• Проверка, почему функция ctime() потоков MIT-pthreads не работает на некоторых FreeBSD системах.

• Добавление опции IMAGE опции к LOAD DATA INFILE, чтобы не обновлять поля TIMESTAMP и AUTO_INCREMENT.

• Добавляемый синтаксис LOAD DATE INFILE ... UPDATE.

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

• Для таблиц с первичными ключами, для которых отсутствует некоторая часть ключа во входном потоке данных или которые не имеют первичного ключа, входные данные интерпретируются сейчас как LOAD DATA INFILE ... REPLACE INTO.

• Сделать понятный синтаксис LOAD DATA INFILE, подобно следующему:

  LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name
       TEXT_FIELDS (text_field1, text_field2, text_field3)
       SET table_field1=CONCAT(text_field1, text_field2),
           table_field3=23
       IGNORE text_field3
  

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

• LOAD DATA INFILE 'file_name' INTO TABLE 'table_name' ERRORS TO err_table_name. Этот оператор задает запись всех ошибок и предупреждений в таблицу err_table_name, которая будет иметь структуру, подобную следующей:

  line_number   - номер строки в файле данных
  error_message - сообщение об ошибке/предупреждение
    и, возможно
  data_line     - строка из файла данных
  

• Автоматический вывод из mysql в Netscape.

• LOCK DATABASES (с различными опциями.)

• Функции: ADD_TO_SET(value,set) и REMOVE_FROM_SET(value,set).

• Добавить использование t1 JOIN t2 ON ... и t1 JOIN t2 USING ... В данное время можно использовать этот синтаксис только с LEFT JOIN.

• Намного большее количество переменных для SHOW STATUS. Фиксирование операций чтения и обновления. Выборки по 1 таблице и выборки по связям. Среднее число таблиц в выборке. Большое число запросов ORDER BY и GROUP BY.

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

• Добавить интерфейс обработчика для табличных данных таким образом, чтобы была возможность использовать его как системную таблицу. Это будет работать несколько медленно в случае запрашивания информации обо всех таблицах, но очень гибко. Должен быть реализован SHOW INFO FROM tbl_name для основных данных о таблицах.

• Сделать возможным SELECT a FROM crash_me LEFT JOIN crash_me2 USING (a); в данном случае подразумевается, что a будет браться из таблицы crash_me.

• Oracle-подобный CONNECT BY PRIOR ... для изучения иерархических структур.

• mysqladmin copy database new-database; требуется добавить команду COPY в mysqld.

• Список процессов должен показывать количество запросов/потоков.

• SHOW HOSTS для распечатки информации о кэше имен хостов.

• Опции DELETE и REPLACE для оператора UPDATE (оператор с этими опциями будет удалять строки при получении ошибки дублирующихся ключей во время обновления).

• Изменить формат DATETIME, чтобы сохранять порции в секундах.

• Добавить все недостающие типы ANSI92 и ODBC 3.0.

• Изменить имена таблиц с пустых строк на NULL для вычисляемых столбцов.

• Не использовать Item_copy_string для числовых значений во избежание преобразований число->строка->число в случае: SELECT COUNT(*)*(id+0) FROM table_name GROUP BY id

• Сделать возможным использование новой библиотеки GNU regexp вместо текущей (библиотека GNU должна быть намного быстрее, чем предыдущая).

• Сделать так, чтобы ALTER TABLE не срывал работу INSERT DELAYED.

• Сделать следующее исправление: если на столбцы есть ссылки в выражении UPDATE, они будут содержать значения, хранившиеся там до запуска процесса обновления.

• Добавить эмуляцию pread()/pwrite() под Windows, чтобы сделать возможными одновременные вставки.

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

• Добавить SUM(DISTINCT).

• Добавить групповые функции ANY(), EVERY() и SOME(). В ANSI SQL эти функции работают только с булевыми столбцами, но мы можем расширить эти функции, чтобы они работали с любыми столбцами/выражениями, применив: value == 0 -> FALSE и value <> 0 -> TRUE.

• Добиться, чтобы тип для MAX(column) был таким же как и тип столбцов:

  mysql> CREATE TABLE t1 (a DATE);
  mysql> INSERT INTO t1 VALUES (NOW());
  mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1;
  mysql> SHOW COLUMNS FROM t2;
  

• Придумать хороший синтаксис для оператора, который будет выполнять UPDATE над строкой при наличии таковой, и INSERT новой строки, если строка отсутствует (подобно тому, как REPLACE работает с INSERT / DELETE).

1.10.5. То, что надо сделать когда-нибудь

• Реализовать функцию: get_changed_tables(timeout,table1,table2,...).

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

• Сделать лучше автоматический код временных меток (timestamp). Добавлять временные метки в журнал обновлений при помощи SET TIMESTAMP=#;.

• Использовать в некоторых местах семафор чтения/записи для увеличения скорости.

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

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

• Реализовать автоматическое закрытие некоторых таблиц, если таблица, временная таблица или временные файлы получат ошибку 23 (недостаточно открытых файлов).

• Если обнаружится поле=#, заменить все местонахождения поля на #. Сейчас такое делается только для некоторых простых случаев.

• Заменить все константные выражения вычисляемыми, если возможно.

• Реализовать оптимизацию ключ=выражение. К данному моменту делается оптимизация только для ключ=поле или ключ=константа.

• Связывать некоторые функции копирования для улучшения кода.

• Заменить sql_yacc.yy внутритекстовым синтаксическим анализатором, чтобы уменьшить ее размер и получать лучшие сообщения об ошибке (5 дней).

• Изменить собственный синтаксический анализатор так, чтобы он использовал только одно правило для различного количества аргументов в функции.

• Использовать полные вычисляемые имена в части сортировки (для ACCESS97).

• MINUS, INTERSECT и FULL OUTER JOIN (в настоящее время поддерживаются UNION [в 4.0] и LEFT OUTER JOIN).

• SQL_OPTION MAX_SELECT_TIME=#, чтобы устанавливать ограничения по времени для запроса.

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

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

• Сигналы предупреждений для функций соединения/чтения/записи клиента.

• Необходимо обратить внимание на изменения на safe_mysqld; согласно FSSTND (которому пытается следовать Debian) PID-файлы должны помещаться в /var/run/<progname>.pid, a файлы журналов - в /var/log. Было бы хорошо, если бы было можно поместить "DATADIR" в первое объявление "pidfile" и "log", чтобы местоположение этих файлов можно было изменить одним оператором.

• Разрешать клиенту запрашивать ведение журналов.

• Добавить использование zlib() для gzip-файлов в LOAD DATA INFILE.

• Исправить сортировку и группирование BLOB-столбцов (сейчас проблема частично решена).

• Хранимые процедуры. Рассматриваются также триггеры.

• Простой (атомарный) язык обновления, который может быть использован для написания циклов и т.п. в MySQL-сервере.

• Произвести изменения для того, чтобы пользоваться семафорами при подсчете потоков. Но сначала нужно реализовать библиотеку семафоров для потоков MIT-pthreads.

• Не устанавливать новое значение во время установки колонки в 0. вместо этого использовать NULL.

• Добавить полную поддержку круглых скобок для JOIN.

• В качестве альтернативы одному потоку/соединению управлять пулом потоков при обработке запросов.

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

Время отводится согласно объемам работ, а не реальному времени.

1.10.6. То, чего не планируется делать

• Такого не существует; мы стремимся к полной совместимости с ANSI 92/ANSI 99.

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.