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

1 Основная информация про MySQL

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

MySQL является free software. Он лицензируется по GNU GENERAL PUBLIC LICENSE http://www.gnu.org.

Сайт MySQL предоставляет последнюю информацию касательно MySQL.

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

  • Все о разработчиках MySQL можно узнать в разделе "1.1.2 Что такое MySQL AB".
  • Обсуждение основных возможностей MySQL приведено в разделе "1.1.4 Основные возможности MySQL".
  • Примеры на SQL и информация по тестированию производительности есть в каталоге sql-bench дистрибутива.
  • Перечень известных на сегодняшний день проблем и дефектов приведен в разделе "1.2.7 Известные ошибки в MySQL".

ВАЖНО:

Сообщения об ошибках также как вопросы и комментарии, должны быть посланы списку рассылки mysql@lists.mysql.com. Подробности в разделе "1.4.1 Как сообщать о проблемах и сбоях". Скрипт mysqlbug должен использоваться, чтобы генерировать отчеты об ошибках. Для дистрибутивов исходных текстов скрипт mysqlbug может быть найден в каталоге scripts. Для двоичных дистрибутивов mysqlbug находится в каталоге bin. Если Вы нашли ошибку защиты в MySQL, Вы должны послать e-mail на security@mysql.com.

Если Вы имеете любые предложения относительно добавлений или исправлений этого руководства, пожалуйста, пошлите их на docs@mysql.com.

1.1 MySQL, MySQL AB и Open Source

1.1.1 Что такое MySQL

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

MySQL представляет собой систему управления базами данных.
Базой данных называют структурированный набор данных. Это может быть чем угодно: от простого перечня покупок до галереи изображений. Чтобы добавлять, обращаться и обрабатывать данные, сохраненные в компьютерной базе данных, Вы нуждаетесь в системе управления базы данных, типа MySQL. Так как компьютеры очень хороши при обработке больших количеств данных, базы данных играют центральную роль в вычислениях, как автономные утилиты, или как части других пакетов прикладных программ.
MySQL является реляционной СУБД.
Реляционная база данных сохраняет данные в отдельных таблицах. Это добавляет быстродействие и гибкость. Таблицы связаны определенными отношениями, делающими возможным объединить данные из нескольких таблиц в одном запросе. SQL-часть MySQL ориентирована на Structured Query Language, наиболее общий стандартизированный язык, используемый, чтобы обратиться к компьютерным базам данных.
MySQL является Open Source Software.
Open Source означает, что тексты открыты для чтения и правки всем желающим. Любой может скачать MySQL из Internet и использовать его совершенно бесплатно. Любой желающий может изучать исходный текст и изменять его по своему усмотрению. MySQL использует лицензию GPL (GNU General Public License) http://www.gnu.org, чтобы определить то, что Вы можете делать с программным обеспечением в различных ситуациях. Если Вы считаете GPL неудобной или должны внедрить MySQL в коммерческую прикладную программу, Вы можете купить коммерчески запатентованную версию у авторов.
Почему используют MySQL?
MySQL очень быстр, надежен и легок в использовании. Если это то, что Вы ищете, Вы должны попробовать его. MySQL также имеет очень практичный набор свойств, разработанных в очень близком сотрудничестве с пользователями. Вы можете найти сравнение эффективности MySQL с некоторыми другими администраторами баз данных на странице эталонных тестов. Подробности в разделе "5.1.4 Пакет тестов MySQL Benchmark Suite". MySQL был первоначально разработан, чтобы обработать очень большие базы данных намного быстрее, чем существующие решения, и успешно использовался в высокотребовательных промышленных средах в течение нескольких лет. При постоянной разработке MySQL сегодня предлагает богатый и очень полезный набор функций. Связность, быстродействие и защита делают MySQL очень подходящим для обращения к базам данных из Internet.
Технические возможности MySQL.
MySQL является системой "клиент-сервер", состоящей из многопоточного SQL-сервера, который поддерживает различные функции, нескольких различных клиентских программ и библиотек, административных инструментальных средств и нескольких интерфейсов программирования.
MySQL имеет много дополнительных программ.
Вероятно, Вы обнаружите, что Ваша любимая прикладная программа или язык программирования уже поддерживает MySQL.

Официально MySQL произносится как "Май-Эс-Ку-Эль", а не как MY-SEQUEL.

1.1.2 Что такое MySQL AB?

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

Авторы ищут партнеров, которые хотели бы поддерживать разработку MySQL так, чтобы они могли бы ускорить темп разработки. Если Вы заинтересованы в этом, напишите на e-mail partner@mysql.com!

MySQL AB имеет в настоящее время свыше 20 разработчиков ( http://www.mysql.com/development/team.html) в платежной ведомости, и это число возрастает быстро.

Основные источники дохода:

  • Коммерческая поддержка высокого качества для MySQL, обеспеченная разработчиками MySQL непосредственно. Если Вы заинтересованы в закупке контракта поддержки, пожалуйста, посетите https://order.mysql.com, чтобы рассмотреть параметры поддержки или собственно заказать поддержку.
  • Консультантские услуги. Фирма MySQL AB имеет разработчиков и консультантов в 12 странах и партнеров во многих других странах, которые могут помочь Вам почти с любой проблемой с MySQL. Если Вы нуждаетесь в консультантских услугах, пожалуйста, напишите по e-mail хорошее описание Ваших потребностей на info@mysql.com! Если авторы не смогут обработать это непосредственно, то они обычно могут найти партнера или разработчика, который может помочь Вам с Вашими проблемами.
  • Авторы продают лицензии на использование MySQL как встроенной базы данных. Если Вы имеете коммерческую программу, для которой Вам требуется база данных высоких качеств, но Вы не можете позволить себе открыть ее исходники, Вы можете купить право использовать сервер MySQL под нормальным коммерческим авторским правом. Если Вы заинтересованы этим, Вы можете купить лицензию прямо на сайте https://order.mysql.com или написать на licensing@mysql.com.
  • Реклама. Сайт http://www.mysql.com представаляет собой очень популярное место более, чем с 10000000 показами страницы в месяц (на январь 2001). Сами понимаете, что баннер на таком сайте гарантирует известность в среде Open source, Linux и баз данных. Если это Вам интересно и нужно, напишите на advertising@mysql.com.
  • Авторы пакета формируют программу партнеров, чтобы иметь возможность обеспечивать услуги MySQL в каждой стране. Если Вы заинтересованы в том, чтобы стать таким партнером, пишите на partner@mysql.com или посетите сайт программы партнерства http://www.mysql.com/information/partners.html.
  • Разработчики обеспечивают обучение MySQL через свои программы партнеров. Для получения большего количества информации, пожалуйста, пишите на info@mysql.com.
  • Если Вы заинтересованы использованием марки изготовителя MySQL в Вашем маркетинге, Вы можете написать об этом на e-mail info@mysql.com.

Авторы пакета хотят, чтобы MySQL всегда был:

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

MySQL AB и команда MySQL AB:

  • Продвигает в массы философию Open Source (открытых исходных текстов) и поддерживает все сообщество разработчиков Open Source Community.
  • Предпочитает партнеров, которые совместно используют знания.
  • Отвечают на почту и оказывает поддержку.
  • Является виртуальной компанией, работающей в основном по сети.
  • Выступает против программных патентов.

1.1.3 История MySQL

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

Название возникло из сокращения (а вернее, слияния) слов My SQL, что на английском языке значит "мой SQL". Названию около десяти лет, оно прижилось еще в те времена, когда пакет не был коммерческой разработкой.

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

Следующий перечень описывает наиболее важные возможности MySQL:

  • Полностью многопоточное использование ядерных нитей. Это означает, что пакет может легко использовать много CPUs, если они есть.
  • Интерфейсы для языков C, C++, Eiffel, Java, Perl, PHP, Python и Tcl.
  • Работает на многих различных платформах.
  • Много типов столбцов: целые со знаком или без него длиной 1, 2, 3, 4 и 8 байт, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET и ENUM.
  • Очень быстрые объединения, использующие оптимизированное однопроходное объединение многих таблиц.
  • Полная поддержка операторов и функций в частях запроса SELECT и WHERE. Например:
    mysql> SELECT CONCAT(first_name, " ", last_name) FROM tbl_name
                      WHERE income/dependents > 10000 AND age > 30;
    
  • SQL-функции выполнены через хорошо оптимизированную библиотеку классов и должны выполняться с такой скоростью, с какой только возможно! Обычно не имеется никакого распределения памяти вообще после инициализации запроса.
  • Полная поддержка предложений SQL GROUP BY и ORDER BY. Поддержка групповых функций (COUNT(), COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX() и MIN()).
  • Поддержка LEFT OUTER JOIN и RIGHT OUTER JOIN с синтаксисами ANSI SQL и ODBC.
  • Вы можете смешивать таблицы из разных баз данных в одном запросе.
  • Привилегии и система паролей, которая является очень гибкой и безопасной, и позволяет проверку, основанную на имени хоста. Пароли безопасны потому, что вся передача пароля шифрована, когда Вы соединяетесь с сервером.
  • ODBC (Open-DataBase-Connectivity) поддерживается для Win32 (с исходниками). Все функции ODBC 2.5 и многие другие реализованы. Например, Вы можете использовать MS Access для связи с сервером MySQL.
  • Очень быстрые дисковые таблицы B-tree с индексным сжатием.
  • Можно иметь до 32 индексов на таблицу. Каждый индекс может состоять от 1 до 16 столбцов или частей столбцов. Максимальная индексная длина 500 байт (это может быть изменено при компиляции MySQL). Индекс может использовать префикс поля CHAR или VARCHAR.
  • Записи фиксированной и переменной длины.
  • Таблицы в памяти, которые используются как временные таблицы.
  • Поддержка поистине огромных объемов данных. Известен случай использования MySQL на 60000 таблиц, хранящих около 5000000000 строк.
  • Все столбцы имеют значения по умолчанию. Вы можете использовать вызов INSERT, чтобы вставить подмножество столбцов таблицы. Те столбцы, которым явно не заданы значения, будут автоматически установлены к их значениям по умолчанию.
  • Для переносимости использованы GNU Automake, Autoconf и Libtool.
  • Пакет написан на C и C++. Оттестирован на всех распространенных компиляторах этих языков.
  • Очень быстрая поточно-безопасная система управления памятью.
  • Никаких утечек памяти. MySQL тестировался с помощью Purify, коммерческого детектора утечек памяти.
  • Есть myisamchk, очень быстрая утилита для проверки таблицы, оптимизации и ремонта. Все функциональные возможности myisamchk также доступны через интерфейс SQL.
  • Полная поддержка для нескольких различных наборов символов, включая ISO-8859-1 (Latin1), german, big5, ujis и много других. Например, скандинавские символы `@ringaccent{a}', `@"a' и `@"o' позволяются в именах столбцов и таблиц.
  • Все данные сохранены в выбранном наборе символов. Все сравнения для нормальных столбцов нечувствительны к регистру.
  • Сортировка выполнена согласно выбранному набору символов (шведский по умолчанию). Возможно изменить это, когда сервер MySQL работает. Чтобы увидеть пример очень продвинутой сортировки, рассмотрите сортировочный код для Czech. MySQL поддерживает много различных наборов символов, которые могут быть определены при компиляции или во время выполнения.
  • Псевдонимы на таблицах и именах столбцов доступны как в стандарте SQL92.
  • DELETE, INSERT, REPLACE и UPDATE возвращают число строк, которые были изменены (обработаны). Можно взамен вернуть число согласованных строк, устанавливая флажок при соединении с сервером.
  • Имена функции не сталкиваются с именами столбцов или таблиц. Например, ABS представляет собой имеющее силу имя столбца. Единственное ограничение: для обращения к функции никакие пробелы не позволяются между именем функции и символом скобки (`('), который следует за ним.
  • Все программы пакета MySQL понимают параметры командной строки --help или -? для выдачи справки о параметрах запуска конкретной программы.
  • Сервер умеет выдавать сообщения об ошибках и диагностику на разных языках.
  • Клиенты могут соединяться с сервером MySQL, используя все мыслимые способы, допустимые в сегодняшних сетях: сокеты TCP/IP, сокеты Unix (под Unix) или даже именованные каналы (под NT).
  • MySQL-специфичная команда SHOW может использоваться, чтобы получить информацию относительно баз данных, таблиц и индексов. Команда EXPLAIN может использоваться, чтобы определить, как именно оптимизатор решает запрос.

1.1.5 Насколько стабилен MySQL?

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

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

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

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

MySQL написан на нескольких уровнях и различных независимых модулях. Эти модули перечислены ниже с индикацией относительно того, как хорошо проверен каждый из них (сравните с MS SQL Server!):

Драйвер ISAM-таблиц: стабилен.
Это управляет хранением и поиском всех данных в MySQL Version 3.22 и ранее. Во всех выпусках MySQL не имелось сообщений об ошибках в этом коде. Единственный известный способ получить разрушенную таблицу состоит в том, чтобы уничтожить сервер в середине модификации. Даже это вряд ли уничтожит любые данные потому, что все данные сбрасываются на диск между запросами. Не было отчетов об ошибках относительно потерянных данных из-за ошибок в MySQL.
Драйвер MyISAM-таблиц: стабилен.
Это ноовведение MySQL Version 3.23. Это в значительной степени основано на коде ISAM-таблиц, но имеет много новых и очень полезных свойств.
Лексический анализатор и обработчик команд: стабильны.
Не было сообщений об ошибках в этой системе в течение длительного времени.
Клиентский код на C: стабилен.
Никаких известных проблем. До Version 3.20 имелись некоторые ограничения в размере буферов передачи/приема. Начиная с Version 3.21, буферный размер теперь динамически меняется до значения по умолчанию в 16M.
Стандартные клиентские программы: стабильны.
Это касается утилит mysql, mysqladmin, mysqlshow, mysqldump и mysqlimport.
Поддержка SQL: стабильна.
Базисная система функций SQL, классы строк и динамическая обработка памяти. Ни одной сообщенной ошибки в этой системе.
Оптимизатор запросов: стабилен.
Оптимизатор диапазонов: стабилен.
Оптимизатор объединений: стабилен.
Блокировки: пока Gamma.
Это очень зависит от системы. На некоторых системах имеются большие проблемы при использовании стандарта блокировки OS (fcntl()). В этих случаях Вы должны выполнить MySQL с опцией --skip-locking. Проблемы, как известно, происходят на некоторых Linux-системах и на SunOS при использовании файловых систем по NFS.
Linux threads: стабильно.
Главная найденная проблема была с обращением fcntl(), которое исправлено, используя опцию --skip-locking для mysqld. Некоторые пользователи сообщали о проблемах тупика в Version 0.5. LinuxThreads должен быть перетранслирован, если Вы планируете использовать свыше 1000 параллельных подключений. Хотя можно выполнить много подключений с LinuxThreads по умолчанию (однако, Вы никогда не будете иметь более, чем 1021 подключение), заданный по умолчанию лимит стека в 2 МБ делает прикладную программу ненадежной, и она способна свалиться в дамп ядра после создания 1021 неактивных подключений.
Solaris 2.5+ pthreads: стабильно.
Мы используем это для всей нашей промышленной работы.
MIT-pthreads (прочие системы): стабильно.
Не имелось никаких сообщенных ошибок, начиная с Version 3.20.15, и никаких известных авторам (почувствуйте разницу!) ошибок, начиная с Version 3.20.16. На некоторых системах имеется сильное замедление операций (до 1/20 секунды бездействия между каждыми двумя запросами). Конечно, MIT-pthreads может все немного замедлять, но индексные инструкции SELECT обычно выполняются в одном пакете.
Другие реализации потоков: Beta-Gamma.
Версии для других систем все еще очень новые и могут иметь ошибки, возможно, в MySQL, но наиболее часто непосредственно в реализации потоков.
LOAD DATA..., INSERT...SELECT: стабильно.
Некоторые люди думали, что они нашли ошибки здесь, но они обычно просто не поняли ситуацию. Пожалуйста, внимательно проверьте руководство перед тем, как сообщать о возникших проблемах!
ALTER TABLE: стабильно.
Маленькие изменения в Version 3.22.12.
DBD: стабильно.
Сейчас поддерживает Jochen Wiedmann (wiedmann@neckar-alb.de). Спасибо!
mysqlaccess: стабильно.
Написан и поддерживается Yves Carlier (Yves.Carlier@rug.ac.be). Спасибо!
GRANT: стабильно.
Большие изменения внесены в MySQL Version 3.22.12.
MyODBC (используется ODBC SDK 2.5): Gamma.
Это, кажется, уже работает хорошо с некоторыми программами.
Репликация: Beta/Gamma.
Авторы все еще работают над репликацией, так что не ожидайте, что это будет твердой скалой. С другой стороны, некоторые пользователи MySQL уже вовсю применяют это свойство с очень хорошими результатами.
Таблицы BDB: Beta.
Код Berkeley DB сам по себе очень устойчив, но разработчики пакета все еще улучшают интерфейс между MySQL и таблицами BDB, так что будет требоваться некоторое время прежде, чем все будет надежно.
Таблицы InnoDB: Beta.
Это недавнее добавление к MySQL. Они работают хорошо и могут использоваться после начального тестирования.
Автоматический ремонт таблиц MyISAM: Beta.
Это воздействует только на новый код, который проверяет, была ли таблица закрыта правильно, и выполняет автоматическую проверку/ремонт таблицы, если это не так.
Таблицы MERGE: Beta/Gamma.
Использование ключей на таблицах MERGE все еще не оттестировано как следует. Другая часть кода MERGE проверена.
FULLTEXT: Beta.
Текстовый поиск работает, но все еще не используется широко.

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

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

MySQL Version 3.22 имеет лимит в 4G на размер таблицы. С новым кодом MyISAM в MySQL Version 3.23 максимальный размер таблицы увеличен до 8 миллионов терабайт (2^63 байт).

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

Операционная системаОграничение размера файла
Linux-Intel 32 bit2G, 4G или больше, зависит от версии Linux
Linux-Alpha8T (?)
Solaris 2.5.12G (возможно, до 4G с патчем)
Solaris 2.64G
Solaris 2.7 Intel4G
Solaris 2.7 ULTRA-SPARC8T (?)

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

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

По умолчанию таблицы MySQL имеют максимальный размер около 4G. Вы можете проверять максимальный размер таблицы для каждой конкретной таблицы с помощью команды SHOW TABLE STATUS или утилитой myisamchk -dv table_name. Подробности приведены в разделе "4.5.5 Синтаксис SHOW".

Если Вы нуждаетесь в таблицах, больших, чем 4G (и Ваша операционная система поддерживает это), Вы должны установить параметры AVG_ROW_LENGTH и MAX_ROWS, когда Вы создаете Вашу таблицу. Вы можете установить их и позже с помощью ALTER TABLE.

Если Ваша большая таблица нужна только для чтения, Вы могли бы использовать myisampack, чтобы объединить и сжать много таблиц в одну. Утилита myisampack обычно сжимает таблицу по крайней мере на 50%, так что Вы можете иметь намного большие таблицы.

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

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

1.1.7 Совместимость с проблемой 2000

MySQL непосредственно не имеет никаких трудностей с проблемой 2000 (Y2K):

  • MySQL использует Unix-функции времени и не имеет никаких проблем с датами до 2069. Все годы с 2 цифрами расценены в интервале от 1970 до 2069, это означает, что, если Вы сохраняете 01 в столбце типа year, MySQL обрабатывает это как 2001.
  • Все функции даты в MySQL сохранены в одном файле sql/time.cc и кодированы очень тщательно, чтобы быть абсолютно 2000-безопасными.
  • В MySQL Version 3.22 и позже новый тип столбца YEAR может сохранять годы 0 и в интервале от 1901 до 2155 в 1 байте, а также отображать их, используя 2 или 4 цифры.

Вы можете сталкиваться с проблемами в прикладных программах, которые используют MySQL, но сами несовместимы с проблемой Y2K. Например, много старых прикладных программ сохраняют или управляют значениями лет, используя числа с 2 цифрами (которые являются неоднозначными). Эта проблема также может быть составлена прикладными программами, которые используют 00 или 99 как значения для индикатора "пропустить". В свое время пришлось столкнуться с программой, которая помечала удаленные записи, выставляя им год 00...

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

Имеется простой пример, иллюстрирующий, что MySQL не имеет любых проблем с датами до года 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. TIMESTAMP имеет диапазон от 1970 до 2030 на 32-разрядных машинах (значение со знаком). На 64-разрядных машинах это обрабатывает времена до 2106 года (значение без знака).

Даже при том, что MySQL Y2K-совместим, Вы отвечаете за то, чтобы обеспечить однозначный ввод.

1.2 MySQL и стандарты

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

1.2.1 MySQL-расширения для стандарта ANSI SQL92

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

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

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

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

Это означает, что, если Вы имеете Version 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-систем).
    • Имена баз данных, таблиц, индексов, столбцов или псевдонимы могут начинаться с цифр (но не могут состоять исключительно из цифр).
    • Вы можете использовать стандартные команды системы, чтобы резервировать, переименовывать, перемещать, удалять или копировать таблицы. Например, чтобы переименовать таблицу, переименуйте файлы .MYD, .MYI и .frm, которым таблица соответствует.
  • В инструкциях SQL Вы можете обращаться к таблицам из различных баз данных с помощью синтаксиса db_name.tbl_name. Некоторые SQL-серверы обеспечивают те же самые функциональные возможности, но называют это User space. MySQL не поддерживает пространство таблиц как in: create table ralph.my_table...IN my_tablespace.
  • LIKE позволяется на числовых столбцах.
  • Использование INTO OUTFILE и STRAIGHT_JOIN допустимо в инструкции SELECT.
  • Опция SQL_SMALL_RESULT в инструкции SELECT.
  • Есть инструкция EXPLAIN SELECT, чтобы получить описание того, как таблицы соединены.
  • Использование индексных имен на префиксе поля и параметров INDEX или KEY в инструкции CREATE TABLE.
  • Применение TEMPORARY или IF NOT EXISTS с CREATE TABLE.
  • Применение COUNT(DISTINCT list), где 'list' включает больше, чем один элемент.
  • Применение CHANGE col_name, DROP col_name или DROP INDEX, IGNORE или RENAME в вызове команды ALTER TABLE.
  • Применение 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.
  • Инструкции ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE и REPAIR TABLE.
  • Инструкция SHOW.
  • Строки могут быть обозначены с помощью `"' или `'', а не только `''.
  • Использование Escape-символа `\'.
  • Инструкция SET OPTION.
  • Вы не должны назвать все выбранные столбцы в 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.
  • Оператор % является синонимом для 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().
  • Регулярные выражения с расширениями 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.
  • Инструкция FLUSH flush_option.
  • Возможность устанавливать переменные в инструкции через :=:
    SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table;
    SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
    

1.2.2 Отличия MySQL от ANSI SQL92

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

  • -- является комментарием, только если сопровождается незаполненным пространством. Подробности чуть ниже.
  • Для столбцов VARCHAR конечные пробелы будут удалены, когда значение сохранено. Подробности в разделе "1.2.7 Известные ошибки и проблемы".
  • В ряде случаев столбцы типа CHAR тихо меняются на столбцы типа VARCHAR.
  • Привилегии для таблицы автоматически не отменяются, когда Вы удаляете таблицу. Вы должны явно выдать REVOKE, чтобы отменить все привилегии для таблицы.
  • NULL AND FALSE вернет NULL вместо FALSE, чтобы не возиться долго с оценкой выражений.

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

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

  • || является конкатенацией строк, а не OR.
  • Вы можете иметь любое число пробелов между именем функции и `('. Это вынуждает все имена функций обрабатываться как зарезервированные слова.
  • `"' будет цитировать идентификаторы (аналогично MySQL ``'), но не строки.
  • REAL превратится в синоним для FLOAT вместо синонима для DOUBLE.
  • Заданный по умолчанию уровень изоляции транзакции SERIALIZABLE .

Этого также можно достичь опцией --sql-mode=REAL_AS_FLOAT, PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY.

1.2.4 Функциональные возможности, отсутствующие в MySQL

Следующие функциональные возможности отсутствуют в текущей версии MySQL. Есть список, указывающий, когда новые расширения могут быть добавлены к MySQL (с их приоритетами), его можно посмотреть в Интернете по адресу http://www.mysql.com/documentation/manual.php?section=TODO.

1.2.4.1 Вложенные операторы select (sub-selects)

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

Во многих случаях Вы можете переписать запрос без sub-select:

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 не поддерживает объединения (за исключением sub-selects). Для этой ситуации имеются два решения, доступные пока подзапросы не поддержаны.

Первое должно использовать процедурный язык программирования (типа 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;

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

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

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

1.2.4.2 SELECT INTO TABLE

MySQL не поддерживает Oracle SQL-расширение SELECT ... INTO TABLE .... MySQL вместо него поддерживает синтаксис ANSI SQL INSERT INTO ... SELECT ..., который является в основном той же самой функциональностью.

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

Альтернативно, Вы можете использовать SELECT INTO OUTFILE... или CREATE TABLE ... SELECT, чтобы решить Вашу проблему.

1.2.4.3 Транзации

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

Часто спрашивают, почему MySQL не транзационная база данных?

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

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

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

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

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

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

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

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

Наконец, в ситуациях, где целостность имеет самую высокую важность, текущие свойства MySQL учитывают уровень транзакции или лучшую надежность и целостность. Если Вы блокируете таблицы с помощью LOCK TABLES, все модификации остановятся, пока любые проверки целостности не будут сделаны. Если Вы только получаете блокировку чтения (в противоположность блокировке записи), то чтение и вставки продолжают работать. Новые вставленные записи не будут замечены клиентами, имеющими блокировку READ, пока они не освободят их блокировки чтения. С помощью INSERT DELAYED Вы можете поместить вставки в локальную очередь, где они останутся до тех пор, пока блокировки не будут освобождены. Таким образом, сервер не будет иметь пользователя, который ждет завершения вставки.

"Атомная" означает, что Вы можете убедиться в том, что в то время как каждая специфическая модификация выполняется, никакой другой пользователь не может сталкиваться с ней, и никакой автоматической обратной перемотки не будет никогда (хотя это может случаться на транзакционных системах, если Вы не очень осторожны). MySQL также гарантирует, что не будет иметься лишних чтений. Вы можете найти пример того, как писать атомные модификации в разделе "1.2.6 Как справиться без COMMIT/ROLLBACK".

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

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

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

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

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

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

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

1.2.4.5 Внешние ключи

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

SELECT * from table1,table2 where table1.id = table2.id;

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

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

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

1.2.4.6 Почему не реализована поддержка для Foreign Keys

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

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

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

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

Противопоказания:

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

1.2.4.7 Views

MySQL не поддерживает views, но это планируется исправить примерно к 4.1.

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

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

Чтобы ограничить доступ к столбцам в MySQL views тоже не требуются: MySQL имеет очень сложную систему предоставления привилегий. Подробности в разделе "4.2 Общие проблемы защиты и система привилегий доступа MySQL".

1.2.4.8 `--' как начало комментария

Некоторые базы данных SQL применяют -- как начало комментария. MySQL имеет # как символ начала комментария, даже если инструмент командной строки mysql удаляет все строки, начинающиеся с --. Вы можете также использовать стиль комментариев языка C (/* это комментарий */) в MySQL.

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

UPDATE tbl_name SET credit=credit-!payment!

Как Вы думаете, что случится, когда значение payment отрицательное? А вот что. Поскольку 1--1 допустимо в SQL, пакет думает, что начался комментарий типа --. Вряд ли это входит в Ваши планы...

В MySQL Version 3.23 Вы можете использовать: 1-- Это был комментарий

Следующее обсуждение касается Вас, только если Вы управляете MySQL Version 3.23 или ранее:

Если Вы имеете программу 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.2.5 Каким стандартам соответствует MySQL?

Entry level SQL92. ODBC levels 0-2.

1.2.6 Как обойтись без COMMIT/ROLLBACK

Следующее обычно применяется только для таблиц ISAM, MyISAM и HEAP. Если Вы используете только транзакционно-безопасные таблицы (BDB или InnoDB) в модификации, Вы можете также делать COMMIT и ROLLBACK в MySQL.

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

Текущей проблемой является ROLLBACK. Без ROLLBACK Вы можете делать любой вид COMMIT с помощью LOCK TABLES. Для поддержки ROLLBACK с вышеупомянутыми типами таблицы MySQL должен быть изменен так, чтобы сохранять все старые записи, которые модифицировались, и иметь возможность быстро вернуться к отправной точке, если была выдана команда ROLLBACK. Для простых случаев это довольно просто (можно приспособить сюда isamlog), но будет намного трудней выполнить ROLLBACK для ALTER/DROP/CREATE TABLE.

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

  1. Примените LOCK TABLES ..., чтобы блокировать все таблицы, к которым Вы хотите обращаться.
  2. Проверьте все условия.
  3. Модифицируйте, если все в порядке.
  4. Вызовите команду UNLOCK TABLES, чтобы снять блокировки.

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

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

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

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

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

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

MySQL вернет для числа обработанных строк, если строка была найдена, и row_flag не был 1 в первоначальной строке.

1.2.7 Известные ошибки и проблемы

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

  • 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. Это особенно важно, когда Вы имеете большой кэш таблицы.
  • Текущий протокол репликации не может иметь дело с LOAD DATA INFILE и выравнивать символы признака конца строки, которые сами занимают больше, чем 1 символ.

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

  • MATCH работает только с инструкциями SELECT.
  • При использовании SET CHARACTER SET не могут быть применены транслируемые символы в базе данных, таблице и столбцах.
  • DELETE FROM merge_table, используемый без WHERE, только очистит отображение для таблицы, не удаляя ничего в самих отображенных таблицах.
  • Вы не можете формировать пакет в другом каталоге при использовании MIT-pthreads, поскольку это требует правки кода MIT-pthreads, мы вряд ли это свойство будем исправлять.
  • Значения BLOB не могут надежно использоваться в GROUP BY, ORDER BY или DISTINCT. Только первые max_sort_length байт (по умолчанию 1024) используются при сравнении BLOB в этих случаях. Это может быть изменено с помощью опции -O max_sort_length при запуске mysqld. Обход для большинства случаев должен использовать подстроку: SELECT DISTINCT LEFT(blob,2048) FROM tbl_name.
  • Вычисление выполнено с BIGINT или DOUBLE (оба обычно длиной в 64 бита). Это зависит от функции, которую обрабатывает пакет. Общее правило: битовые функции выполнены с точностью BIGINT, IF и ELT() с BIGINT или DOUBLE, а все прочие с DOUBLE. Нужно пробовать избегать использовать большие длинные значения без знака (9223372036854775807)!
  • Все строковые столбцы, кроме BLOB и TEXT, автоматически удаляют все конечные пробелы, когда сохраняются. Для типа CHAR это разрешено и может быть расценено как свойство согласно ANSI SQL92. Ошибка в том, что в MySQL столбцы VARCHAR обрабатываются тем же самым путем.
  • Вы можете иметь только до 255 столбцов типа 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.
  • Вы не можете использовать временные таблицы больше, чем однажды в том же самом запросе. Например, следующее не будет работать:
    select * from temporary_table, temporary_table as t2;
    
  • RENAME не работает с таблицами TEMPORARY.
  • Оптимизатор может обрабатывать 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 позволяет Вам работать с типами таблиц, которые не поддерживают транзакции (и таким образом не могут выполнить rollback), некоторые вещи ведут себя немного иначе, чем в других серверах SQL. Это только должно гарантировать, что MySQL никогда не должен делать обратную перемотку для команд SQL. Это может быть иногда немного неуклюже, поскольку значения столбца должны проверяться прикладной программой, но это фактически даст Вам хорошее увеличение быстродействия, поскольку это позволяет MySQL делать некоторые оптимизации, которые иначе были бы невозможны или очень трудны. Если Вы устанавливаете столбец к неправильному значению, MySQL будет, вместо того, чтобы делать обратную перемотку, сохранять самое лучшее возможное значение в столбце.
    • Если Вы пробуете сохранять значение вне диапазона в числовом столбце, MySQL взамен сохранит самое маленькое или самое большое возможное значение.
    • Если Вы пробуете сохранять строку, которая не начинается с числа, в числовой столбец, MySQL сохранит 0 в нем.
    • Если Вы пробуете сохранять NULL, который не берет значения NULL, MySQL сохранит 0 или '' (пустую строку). Это поведение может, однако, быть изменено с опцией компиляции -DDONT_USE_DEFAULT_FIELDS.
    • MySQL позволяет Вам сохранять некоторые неправильные значения даты в столбцы DATE и DATETIME. Например, 2000-02-31 или 2000-02-00. Если дата полностью неправильна, MySQL сохранит в столбце специальное значение даты 0000-00-00.
    • Если Вы устанавливаете enum к неподдерживаемому значению, это будет установлено к значению ошибки 'empty string' с числовым значением 0.
  • Если Вы выполняете PROCEDURE на запросе, который возвращает пустой набор, в некоторых случаях PROCEDURE не будет трансформировать столбцы.
  • Создание таблицы типа MERGE не проверяет, имеют ли основные таблицы совместимые типы.
  • MySQL не может все же обрабатывать значения NaN, -Inf и Inf в double. Использование их вызовет проблемы при попытке экспортировать и импортировать данные. Вы должны как промежуточное решение изменить NaN на NULL (если возможно), а -Inf и Inf соответственно к минимальному и максимальному возможным значениям double.
  • LIMIT на отрицательных числах превращается в очень большие положительные числа, что ошибочно.
  • Если Вы используете ALTER TABLE, чтобы сначала добавить индекс UNIQUE к таблице, используемой в таблице типа MERGE, и затем использовать ALTER TABLE, чтобы добавить нормальный индекс уже на таблице MERGE, порядок ключей будет иным для таблиц, если имелся старый не уникальный ключ в таблице. Это потому, что ALTER TABLE помещает ключи UNIQUE перед нормальными ключами, чтобы обнаружить двойные ключи как можно раньше.

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

  • Вы можете получать зависающий поток, если Вы делаете DROP TABLE на таблице, которая является одной среди многих таблиц, которые блокированы с помощью LOCK TABLES.
  • В следующих случаях Вы можете получать дамп ядра:
    • Отсроченный драйвер вставки имеет ждущие обработки вставки к таблице.
    • LOCK table с WRITE
    • FLUSH TABLES
  • До MySQL Version 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 Version 3.23 все числовые типы обрабатываются как поля с фиксированной точкой. Это означает, что Вы должны были определить, сколько десятичных чисел должно быть после запятой. Все результаты были возвращены с правильным количеством десятичных чисел.

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

1.3 Лицензирование и поддержка MySQL

Этот раздел описывает поддержку MySQL и меры патентования:

1.3.1 Политика лицензирования MySQL

Формальные условия лицензии GPL могут быть найдены в сети или в разделе "Приложение 4. GNU GENERAL PUBLIC LICENSE ". В основном, стратегия патентования и интерпретация GPL авторами следующие:

Обратите внимание, что старшие версии MySQL все еще используют более строгую лицензию. Так что изучите соответствующую документацию по адресу http://www.mysql.com/support/arrangements/mypl.html. Если Вы нуждаетесь в коммерческой лицензии потому, что лицензия GPL не удовлетворяет Вашу прикладную программу, Вы можете купить ее на сайте https://order.mysql.com.

Для нормального внутреннего использования MySQL не стоит ничего. Вы не должны никому ничего платить за некоммерческое использование пакета.

Лицензия требуется если:

  • Вы компонуете программу, которая не является free software, с кодом клиента или сервера MySQL, который имеет лицензию GPL. Это случается, например, когда Вы используете MySQL как вложенный сервер баз данных в Ваших прикладных программах, или когда Вы добавляете не свободные расширения в MySQL. В этом случае Ваша прикладная программа/код также стала бы GPL через лицензию GPL, которая действует как вирус. Покупая сервер MySQL у MySQL AB под коммерческой лицензией Вы избежите возникновения этой проблемы. Подробности по адресу http://www.gnu.org/copyleft/gpl-faq.html.
  • Вы имеете коммерческую прикладную программу, которая работает ТОЛЬКО с MySQL и продаете ее в комплекте с сервером MySQL.
  • Вы имеете дистрибутив MySQL, и Вы не обеспечиваете исходный текст для Вашей копии сервера MySQL, как определено в лицензии GPL.

Лицензия НЕ требуется если:

  • Вы не нуждаетесь в лицензии, чтобы включить код пользователя в коммерческие программы. Клиентская часть MySQL лицензируется под LGPL GNU Library General Public License. Клиент командной строки mysql включает код из библиотеки readline, которая находится под GPL.
  • Если Ваше использование MySQL не требует лицензии, но Вы находите приятным MySQL и хотите поощрить дальнейшую разработку, купите лицензию или хотя бы поддержку.
  • Если Вы используете MySQL в коммерческом контексте, который приносит доход, то должны купить поддержку. Если Вы зарабатываете деньги на MySQL, то будет только справедливо поделиться ими с авторами пакета.

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

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

Если Вам требуется лицензия MySQL, самый простой способ купить ее состоит в том, чтобы использовать форму лицензии на безопасном сервере MySQL по адресу https://order.mysql.com. Другие формы оплаты обсуждены в разделе "1.3.4.1 Информация об оплате".

1.3.2 Авторские права на MySQL

Имеется несколько различных авторских прав на дистрибутив MySQL:

  1. MySQL-специфический источник, необходимый, чтобы формировать библиотеку mysqlclient, запатентован под LGPL, и программы в каталоге client под GPL. Каждый файл имеет заголовок, который показывает, которое авторское право используется для этого файла.
  2. Библиотека пользователей и библиотека GNU getopt охвачены GNU LIBRARY GENERAL PUBLIC LICENSE. Подробности в разделе "Приложение 5. GNU LESSER GENERAL PUBLIC LICENSE".
  3. Некоторые части исходного кода (например, библиотека regexp) охвачены авторским правом Berkeley-стиля.
  4. Все исходники сервера и библиотека GNU readline лицензируются по GNU GENERAL PUBLIC LICENSE. Подробности в разделе "Приложение 4. GNU GENERAL PUBLIC LICENSE ". Она также доступна как файл COPYING в дистрибутивах.

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

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

1.3.2.1 Изменения авторского права

MySQL Version 3.22 все еще использует более строгую лицензию. Подробности есть в документации по ней.

1.3.3 Примеры лицензирования

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

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

1.3.3.1 Продажа программ, использующих MySQL

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

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

1.3.3.2 Сервисы ISP MySQL

Internet Service Providers (ISP) часто ставят серверы MySQL для своих заказчиков. По лицензии GPL это не требует покупки лицензии.

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

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

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

1.3.3.3 Запуск Web-сервера, использующего MySQL

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

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

1.3.4 Лицензирование и платная поддержка MySQL

Текущие (актуальные) цены на лицензии показываются ниже. Чтобы сделать покупку, посетите сайт https://order.mysql.com.

Если Вы оплачиваете кредитной карточкой, денежная единица: EURO (European Union Euro), так что цены немного отличаются.

Количество лицензий Цена одной копии
1-9230 EURO
10-24138 EURO
25-49117 EURO
50-99102 EURO
100-24991 EURO
250-49976 EURO
500-99966 EURO

Для большого объема (OEM) покупок, пожалуйста, войдите в контакт с sales@mysql.com.

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

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

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

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

Более всесторонняя поддержка продается отдельно. Описание того, что включает каждый уровень поддержки, даны в разделе "1.3.5 Типы коммерческой поддержки". Цены для различных типов коммерческой поддержки показываются ниже. Цены указаны в EURO (European Union Euro).

Тип поддержкиЦена годовой подписки на поддержку этого типа
Базовая поддержка электронной почтыEURO 200
Расширенная поддержка электронной почтыEURO 1000
Login-поддержкаEURO 2000
Расширенная Login-поддержкаEURO 5000
Телефонная поддержкаEURO 12000

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

Авторы обеспечивают также и телефонную поддержку (обычно аварийную, но и 24/7 тоже). Эта опция поддержки не имеет фиксированную цену, а бывает заключена в зависимости от ситуации. Если Вы заинтересованы этой опцией, Вы можете сообщать относительно Ваших потребностей по e-mail sales@mysql.com.

Обратите внимание, что, поскольку коммерческий штат фирмы очень занят, может потребоваться некоторое время, пока Ваш запрос обработают.

1.3.4.1 Информация об оплате

В настоящее время поддерживаются кредитные карточки, чеки или SWIFT.

Оплата должна быть сделана на:

Postgirot Bank AB
105 06 STOCKHOLM, SWEDEN

MySQL AB
BOX 6434
11382 STOCKHOLM, SWEDEN

SWIFT address: PGSI SESS
Account number: 96 77 06 - 3

Определите: лицензия и/или поддержка, Ваше имя и адрес электронной почты.

В Европе и Японии Вы можете использовать платеж EuroGiro (который должен быть менее дорог) к тому же самому счету.

Если Вы хотите оплачивать чеком, заполните его на ``MySQL Finland AB'' и отправьте по почте на адрес:

MySQL AB
BOX 6434, Torsgatan 21
11382 STOCKHOLM, SWEDEN

Если Вы хотите оплачивать кредитной карточкой через Internet, Вы можете использовать безопасную форму лицензии MySQL AB на https://order.mysql.com.

Вы можете также отпечатать копию формы лицензии, заполнить ее и отправить по факсу на:

+46-8-729 69 05

Если Вы хотите, чтобы Вам выставили счет, Вы можете использовать форму лицензии и написать ``bill us'' в поле комментария. Вы можете также отправить сообщение на адрес sales@mysql.com (но НЕ на mysql@lists.mysql.com!) с Вашей информацией о компании и попросить, чтобы авторы выставили счет Вам.

1.3.4.2 Контактная информация

Для коммерческого лицензирования, пожалуйста, войдите в контакт с группой лицензирования MySQL. Наилучший метод для этого: послать e-mail на адрес licensing@mysql.com. Факсы также возможны, но их обработка может занять намного большее время (факс: +46-8-729 69 05).

Если Вы представляете бизнес, который заинтересован в партнерстве с MySQL, пожалуйста, пошлите электронную почту на адрес partner@mysql.com.

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

Если Вы заинтересованы размещением рекламы на Web-сайте MySQL, пожалуйста, пошлите электронную почту на адрес advertising@mysql.com.

Если Вы заинтересованы любой из работ, перечисленных в разделе работ ( http://www.mysql.com/development/jobs), пожалуйста, пошлите электронную почту на адрес jobs@mysql.com.

Для общего обсуждения среди пользователей пакета, пожалуйста, направьте сообщение в соответствующий список рассылки. Их перечень есть на http://www.mysql.com/documentation/lists.html.

Для вопросов или комментариев относительно работ или содержания Web-сайта, пожалуйста, пошлите электронную почту на webmaster@mysql.com.

1.3.5 Типы коммерческой поддержки

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

  • Поддержка покупается сроком на год.
  • Авторы устраняют любую воспроизводимую ошибку (в крайнем случае обеспечат путь ее обхода).
  • Более высокий уровень поддержки подразумевает большее количество усилий, которое авторы прилагают для поиска решений Ваших проблем.
  • Следующее истинно для всех контрактов поддержки за исключением базовой поддержки электронной почты: вопросы, не относящиеся к ошибкам (оптимизация запросов, например), оплачиваются отдельно и стоят недешево (200 EURO/час).

1.3.5.1 Базовая поддержка электронной почты

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

На этом уровне поддержки списки рассылки по-прежнему являются основной коммуникацией. То есть, пишите в них о своих проблемах, выбирая соответствующий теме список (вдруг кто-то уже эту проблему решил?). Однако, покупая базовую поддержку электронной почты, Вы также имеете доступ к mysql-поддержке по адресу mysql-support@mysql.com, который не доступен как часть минимальной поддержки, которую Вы получаете, просто покупая лицензию MySQL. Это означает, что для особенно критических вопросов, Вы можете послать сообщение на mysql-support@mysql.com. Если сообщение содержит чувствительные данные, Вы должны писать только на mysql-support@mysql.com.

ПОМНИТЕ! ВСЕГДА включайте Ваш код регистрации и дату окончания, когда Вы посылаете сообщение на mysql-support@mysql.com.

Обратите внимание, что, если Вы столкнулись с критической воспроизводимой ошибкой, и, согласно правилам, отослали сообщение о ней на bugs@lists.mysql.com, разработчики будут пробовать исправить ее как можно скорее, независимо от Вашего уровня поддержки! Подробности в разделе "1.4.1 Как сообщать об ошибках и проблемах".

Базовая поддержка электронной почты включает следующие типы обслуживания:

  • Если на Ваш вопрос уже ответили в руководстве, Вам сообщат правильный раздел, в котором Вы можете найти ответ. Если ответ не в руководстве, Вам сообщат, где Вы можете ответ найти сами.
  • Авторы гарантируют своевременный ответ для Ваших сообщений электронной почты. Они не могут гарантировать, что решат любую проблему, но по крайней мере Вы получите ответ.
  • Авторы помогут с непредвиденными проблемами, когда Вы устанавливаете MySQL из двоичного дистрибутива на поддержанных платформах. Этот уровень поддержки не покрывает установку MySQL из исходников. Поддержанные платформы, для которых MySQL, как известно, работает, перечислены в разделе "2.2.2 ОС, поддерживаемые MySQL".
  • Авторы помогут с ошибками и отсутствующими свойствами. Любые ошибки, которые найдены, будут исправлены для следующего выпуска MySQL. Если ошибка критическая для Вас, по электронной почте Вы получите патч, как только он будет сделан. Критические ошибки всегда имеют самый высокий приоритет, и разработчики гарантируют, что они будут исправлены как можно скорее.
  • Ваши предложения для дальнейшей разработки MySQL будут учтены, но не как самые важные. Купив e-mail-поддержку, Вы тем самым уже немного помогли дальнейшей разработке MySQL. Если Вы хотите иметь больше сведений, перейдите к более высокому уровню поддержки.

1.3.5.2 Расширенная поддержка электронной почты

Расширенная поддержка электронной почты включает все из базовой поддержки электронной почты с этими добавлениями:

  • С Вашей электронной почтой будут иметь дело прежде, чем с почтой с уровня базовой поддержки.
  • Ваши предложения для дальнейшей разработки MySQL получат сильное рассмотрение. Простые расширения, которые удовлетворяют базисные цели MySQL, будут выполнены в течение нескольких дней. Купив расширенную поддержку электронной почты, Вы уже помогли дальнейшей разработке MySQL.
  • Типичные ситуации, покрытые расширенной поддержкой электронной почты:
    • Авторы отвечают и (в рамках вопроса) решают вопросы, которые касаются возможных ошибок в MySQL. Как только ошибка найдена и исправлена, Вам пришлют заплатку для нее.
    • Авторы помогают с непредвиденными проблемами, когда Вы устанавливаете MySQL из исходного или двоичного дистрибутива на поддержанных платформах.
    • Авторы отвечают на вопросы относительно отсутствия свойств, а также предлагают решения, как обойти проблему.
    • Предлагаются советы при оптимизации работы mysqld (и запросов) для Вашей конкретной ситуации.
  • Вам позволяют влиять на приоритет элементов списка MySQL TODO. Это гарантирует, что свойства, в которых Вы в самом деле нуждаетесь, будут выполнены скорее, чем они могли бы быть выполнены в иных случаях.

1.3.5.3 Login-поддержка

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

  • С вашей электронной почтой будут иметь дело даже прежде, чем с обращениями пользователей расширенной поддержки электронной почты.
  • Ваши предложения для дальнейшей разработки MySQL будут приниматься с очень пристальным вниманием. Расширения, которые могут быть выполнены за несколько часов, и в общем соответствуют базисным целям MySQL, будут выполнены как можно скорее.
  • Если Вы имеете очень специфическую проблему, возможна связь авторов прямо с Вашей системой, чтобы решить проблему на месте.
  • Конечно, как и любой производитель СУБД, разработчики пакета не могут гарантировать, что смогут спасти любые данные из разрушенных таблиц, но они помогут Вам в максимально возможной степени. MySQL доказал себя очень надежной системой, но что-нибудь всегда возможно из-за обстоятельств вне контроля авторов пакета.
  • Обеспечиваются советы при оптимизации Вашей системы и запросов.
  • Вам позволяют связываться (через модератора) с разработчиками и обсуждать Ваши проблемы с MySQL. Эта опция должна, однако, использоваться только как последний шанс после того, как не удалось устранить проблему по e-mail. Чтобы сделать эффективное использование времени, авторы должны сначала получить все факты относительно проблемы перед разговором по телефону, чтобы работать настолько эффективно, насколько это вообще возможно при решении проблемы.

1.3.5.4 Расширенная Login-поддержка

Расширенная Login-поддержка включает все из предыдущего типа поддержки, но уже с этими добавлениями:

  • Ваша электронная почта имеет самый высокий возможный приоритет.
  • Авторы активно исследуют Вашу систему и помогут Вам оптимизировать ее и Ваши запросы. Они могут также оптимизировать и/или расширить MySQL, чтобы лучше удовлетворить Ваши потребности.
  • Вы можете также запрашивать специальные расширения только для Вас. Например:
    mysql> select MY_FUNC(col1,col2) from table;
    
  • Авторы будут обеспечивать двоичный дистрибутив всех важных выпусков MySQL персонально для Вашей системы, пока им будет предоставлен shell-доступ к подобной системе. В крайнем случае предоставьте доступ к Вашей системе.
  • Если Вы можете обеспечивать размещение и дорожные расходы, Вы можете даже вызвать кого-то из разработчиков пакета к себе для решения проблем. Расширенная поддержка позволяет один такой визит в год, но авторы пакета всегда очень гибко относятся к заказчикам! Если посещение занимает 16 часов или больше, первые 8 часов бесплатны. За остальное время Вы будете обязаны заплатить в соответствии с тарифом, который является по крайней мере на 20% меньше, чем наши стандартные тарифы.

1.3.5.5 Телефонная поддержка

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

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

1.3.5.6 Поддержка для других драйверов таблицы

Чтобы получить поддержку для таблиц типов BDB и InnoDB Вы должны оплатить дополнительно по 30% от стандартной цены поддержки за каждый из драйверов таблицы, для которых Вы хотели бы иметь поддержку.

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

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

1.4 Выяснение вопросов или сообщение об ошибках в пакете

Перед отправкой отчета об ошибке или вопроса сделайте следующее:

  • Начните с поисков в руководстве по MySQL. Самая свежая версия (увы, только на английском языке) есть по адресу:
    http://www.mysql.com/documentation/manual.php.
  • Ищите также в архиве списков рассылки по MySQL: http://www.mysql.com/documentation.
  • Вы можете также использовать http://www.mysql.com/search.html для поиска по всем страницам на http://www.mysql.com.

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

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

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

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

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

Нормальное место, чтобы сообщить ошибки и проблемы: mysql@lists.mysql.com. Если Вы можете создать случай теста, который ясно показывает ошибку, Вы должны его послать на bugs@lists.mysql.com. Обратите внимание, что в этом списке Вы должны только регистрировать полный повторимый отчет ошибки, использующий скрипт mysqlbug. Если Вы работаете под Windows, Вы должны включить описание операционной системы и версии MySQL. Предпочтительно, Вы должны проверить проблему при использовании последнего устойчивого дистрибутива или версии для разработчика. Любой должен быть способен повторить ошибку, используя только mysql test<script на включенном случае теста или выполнить скрипт, который включен в отчет ошибки. Все ошибки, зарегистрированные в списке bugs, будут исправлены или зарегистрированы в следующем выпуске MySQL! Если имеются только маленькие изменения кода, в этом списке может быть опубликован патч.

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

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

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

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

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

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

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

  • Версия дистрибутива MySQL (например, MySQL Version 3.22.22). Вы можете выяснить, которой версией пользуетесь, командой mysqladmin version. mysqladmin может быть найден в каталоге bin под каталогом установок MySQL.
  • Изготовитель и модель машины, на которой Вы работаете.
  • Имя операционной системы и версия. Для большинства операционных систем, Вы можете получить эту информацию, выполняя Unix-команду uname -a.
  • Иногда объем памяти (реальной и виртуальной) релевантен. Если сомневаетесь, включите эти значения.
  • Если Вы используете исходники MySQL, нужны имя и версия компилятора. Если Вы имеете двоичный дистрибутив, необходимо его имя. Если проблема происходит в течение трансляции, включите точное сообщение об ошибках, а также несколько строк контекста кода из файла, где ошибка произошла.
  • Если mysqld рухнул, Вы должны также сообщить запрос, который потерпел крах. Вы можете обычно найти его, запуская mysqld с включеным протоколированием. Подробности в разделе "6.1.5 Использование журналов, чтобы найти причину ошибок в mysqld".
  • Если любая таблица базы данных связана с проблемой, включите вывод из mysqldump --no-data db_name tbl_name1 tbl_name2 .... Это очень простой и мощный способ получить информацию относительно любой таблицы в базе данных, которая поможет создать ситуацию, соответствующую той, что у Вас.
  • Для связанных с быстродействием ошибок или проблем с инструкциями SELECT Вы должны всегда включать вывод EXPLAIN SELECT ... и по крайней мере число строк, которые производит инструкция SELECT. Большее количество информации, которую Вы даете относительно Вашей ситуации, делает более вероятным, что кто-то сможет помочь Вам! Например, следующее представляет собой пример очень хорошо составленного отчета об ошибке (это должно быть, конечно, создано с помощью скрипта mysqlbug). Обратите внимание на использование признака конца оператора \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, попробуйте сделать скрипт, который воспроизведет аномалию. Этот скрипт должен включить любые необходимые исходные файлы. Если у Вас получается сделать такой пример, который точно воспроизводит ошибку при минимальных усилиях со стороны изучающего, направьте его на bugs@lists.mysql.com для приоритетной обработки ситуации! Если Вы не можете обеспечить готовый скрипт, Вы должны по крайней мере включить вывод mysqladmin variables extended-status processlist, чтобы обеспечить некоторую информацию о раболте Вашей системы.
  • Если Вы не можете изготовить случай теста в нескольких строках, или если таблица теста слишком большая, чтобы быть отправленной по почте в список рассылки (больше, чем 10 строк), Вы должны сделать дамп Вашей таблицы, используя mysqldump, и создать файл README, который описывает Вашу проблему. Создайте сжатый архив Ваших файлов, используя tar и gzip (или zip), и передайте его по ftp на ftp://support.mysql.com/pub/mysql/secret. Затем пошлите короткое описание проблемы на bugs@lists.mysql.com.
  • Если Вы думаете, что 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.
  • Если Вы имеете заплату для ошибки, которая является хорошей, пришлите ее авторам в комплекте со случаем теста, иллюстрирующим применение заплаты. Помните, что без детального описания и тестового примера, разработчики могут и не понять назначение заплатки, а следовательно, и не будут ее применять. Покажите, что заплата обработает все ситуации, которые могут возникнуть.
  • Присылайте предположения касательно причин ошибки. Без таких предположений сложно с первой попытки понять, какой именно кусок кода надо отлаживать и изучать. К тому же, описание причин упрощает отладку.
  • Если Вы получаете ошибку синтаксического анализа (parse error), пожалуйста, проверьте Ваш синтаксис очень тщательно! Если Вы не можете найти что-то неправильное в нем, чрезвычайно вероятно, что Ваша текущая версия MySQL просто не поддерживает запрос, который Вы используете. Если Вы применяете самую свежую версию, и руководство на http://www.mysql.com/documentation/manual.php не покрывает синтаксис, который Вы применили, значит MySQL не поддерживает Ваш запрос. Если руководство покрывает синтаксис, который Вы используете, но Вы имеете старую версию MySQL, Вы должны проверить хронологию изменения MySQL, чтобы увидеть, когда синтаксис был реализован. В этом случае следует обновить версию.
  • Если проблема разрушает данные в таблицах, или Вы получаете ошибки, когда обращаетесь к некоторой специфической таблице, Вы должны сначала проверить и пробовать восстановить Ваши таблицы с помощью myisamchk или CHECK TABLE и REPAIR TABLE.
  • Если Вы часто получаете разрушенные таблицы, Вы должны пробовать выяснить, когда и почему это случается! В этом случае файл mysql-data-directory/'hostname'.err может содержать некоторую информацию относительно того, что случалось. Пожалуйста, включите любую релевантную информацию из этого файла в Ваш отчет об ошибке. Как правило, mysqld никогда не должен разрушить таблицу, если ничто не уничтожило его посреди модификации. Если Вы можете найти причину слета mysqld, это сильно облегчит работу.
  • Если возможно, загрузите и поставьте самую современную версию MySQL и проверьте, не решило ли это проблему. Все версии MySQL полностью проверены и должны бы работать без проблем! В пакете поддерживается обратная совместимость, так что переход на новую версию займет несколько минут.

Направьте отчет на адрес соответствующей рассылки. Может кто-то еще испытал (и возможно решил) такую проблему. Если Вы подписаны на поддержку, пишите на mysql-support@mysql.com.

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

1.4.3 Руководящие принципы ответов на вопросы в списках рассылки

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

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

1.5 MySQL в сравнении с другим базами данных

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

Этот раздел первоначально был написан разработчиками MySQL. Не имеется никаких фактических ошибок, содержащихся в этом разделе, о которых я бы знал. Если Вы находите что-то неправильное, свяжитесь с авторами пакета по e-mail docs@mysql.com.

Перечень всех поддержанных ограничений, функций и типов есть на crash-me Web page по адресу http://www.mysql.com/information/crash-me.php.

1.5.1 MySQL в сравнении с mSQL

Производительность
Для истинного сравнения быстродействия, консультируйтесь с пакетом MySQL benchmark suite. Подробности в разделе "5.1.4 Набор тестов MySQL Benchmark Suite". Поскольку нет создания потоков и маленького синтаксического анализатора, зато есть упрощенная защита и немного возможностей, пакет mSQL должен быть более быстрым в следующих случаях:
  • Тесты, которые выполняют повторные подключения, работая с очень простым запросом в течение каждого подключения.
  • Операции INSERT в очень простые таблицы с немногими столбцами и ключами.
  • CREATE TABLE и DROP TABLE.
  • SELECT на чем-то, что не является индексом (просмотр таблицы очень прост).
С другой стороны, MySQL намного быстрее, чем mSQL (и большинство других реализаций SQL) на следующем:
  • Сложные запросы SELECT.
  • Получение больших результатов (MySQL имеет более быстрый и безопасный протокол обмена данными).
  • Таблицы со строками переменной длины потому, что MySQL имеет более эффективную обработку и может иметь индексы на столбцах VARCHAR.
  • Обработка таблиц с многими столбцами.
  • Обработка таблиц с большими длинами записи.
  • SELECT с многими выражениями.
  • SELECT на больших таблицах.
  • Обработка многих подключений в то же самое время. MySQL полностью многопоточный. Каждое подключение имеет собственный поток, что означает, что никакой поток не должен ждать другой (если поток не изменяет таблицу, к которой другой поток хочет обращаться). В mSQL как только одно подключение установлено, другие должны ждать его завершения независимо от того, управляет ли подключение запросом, который является коротким или длинным. Когда первое подключение завершается, следующее может обслуживаться.
  • Объединения. Пакет mSQL может стать патологически медленным, если Вы изменяете таблицу в SELECT. В эталонном наборе тестов время выполнения порой отличалось в 15000 раз! Это из-за недостатка оптимизатора объединения mSQL, который не может упорядочить таблицы в оптимальном порядке. Однако, если Вы помещаете таблицы точно в правильном порядке mSQL, а предложение WHERE простое и использует индексные столбцы, объединение будет относительно быстрым! Подробности в разделе "5.1.4 Набор тестов MySQL Benchmark Suite".
  • ORDER BY и GROUP BY.
  • DISTINCT.
  • Использование столбцов типов TEXT и BLOB.
Возможности SQL
  • GROUP BY и HAVING. mSQL не поддерживает GROUP BY вообще. MySQL поддерживает полную версию GROUP BY с HAVING и следующими функциями: COUNT(), AVG(), MIN(), MAX(), SUM() и STD(). COUNT(*) оптимизирован, чтобы возвратить данные очень быстро, если SELECT получает данные из одной таблицы, никакие другие столбцы не получены, и не имеется никакого предложения WHERE. MIN() and MAX() могут брать параметры-строки.
  • INSERT и UPDATE с вычислениями в фоновом режиме. MySQL может делать вычисления в вызовах INSERT или UPDATE. Например:
    mysql> UPDATE SET x=x*10+y WHERE x<20;
    
  • Псевдонимы. MySQL имеет псевдонимы для имени столбца.
  • Автоматическое дополнение спецификаций имен столбца. В MySQL, если имя столбца уникально среди таблиц, используемых в запросе, Вы не должны использовать полный спецификатор.
  • SELECT с функциями. MySQL имеет много функций (слишком много, чтобы перечислить их здесь.
Использование диска
Насколько маленькими Вы можете делать Ваши таблицы? MySQL имеет очень точные типы, так что Вы можете создавать таблицы, которые требуют минимум места. Пример полезного типа в MySQL: MEDIUMINT, который имеет длину в 3 байта. Если Вы имеете 100000000 записей, экономия даже одного байта на запись принципиальна. mSQL2 имеет более ограниченный набор типов столбца, так что труднее получить маленькие таблицы.
Стабильность
Сложно судить объективно. Вот что пишут авторы MySQL: мы не имеем никакого опыта со стабильностью mSQL, так что мы не можем говорить что-нибудь относительно этого.
Цена
Другая важная проблема: лицензия. MySQL имеет более гибкую лицензию, чем mSQL, а также менее дорог, чем mSQL.
Интерфейс с языком Perl
MySQL имеет в основном те же самые интерфейсы к Perl, что и mSQL, но с некоторыми добавленными свойствами.
JDBC (Java)
MySQL в настоящее время имеет много различных JDBC-драйверов:
  • Драйвер mm: type 4 JDBC (автор Mark Matthews, mmatthew@ecn.purdue.edu). Распространяется по LGPL.
  • Драйвер Resin. Это коммерческий драйвер JDBC, распространяемый как open source ( http://www.caucho.com/projects/jdbc-mysql/index.xtp).
  • Драйвер gwe: Java-интерфейс, разработанный GWE technologies (в настоящее время не поддерживается).
  • Драйвер jms: улучшенный вариант gwe (автор Xiaokun Kelvin ZHU, X.Zhu@brad.ac.uk). В настоящее время не поддерживается.
  • Драйвер twz: type 4 JDBC (автор Terrence W. Zellers, zellert@voicenet.com). Коммерческий, но свободен для частного и образовательного использования. В настоящее время не поддерживается.
Рекомендуемый драйвер: mm. Resin также хорош (по крайней мере просмотры эталонных тестов хороши), но о нем маловато сведений. Я знаю, что mSQL имеет JDBC-драйвер, но дел с ним имел мало, сравнивать их трудно из-за отсутствия данных.
Порядок разработки
MySQL имеет очень маленькую группу разработчиков, но они хорошо знают C и C++. Поскольку потоки, функции, GROUP BY и прочее пока не реализованы в mSQL, его разработчикам придется еще немало поработать головой. Чтобы получить некоторую перспективу, Вы можете просматривать файл HISTORY в mSQL за последний год и сравнивать это с разделом News в MySQL Reference Manual. Должно быть довольно очевидно, что развивается наиболее быстро.
Утилиты
mSQL и MySQL имеют много интересных инструментальных средств от третьего лица. Поскольку портирование из mSQL в MySQL легко, почти все интересные прикладные программы, которые являются доступными для mSQL, также доступны для MySQL. MySQL приходит с простой программой msql2mysql, которая устанавливает различия в проверке правописания между mSQL и MySQL для используемых функций C API. Например, это изменяет образцы msqlConnect() на mysql_connect(). Преобразование программы пользователя с mSQL в MySQL обычно занимает несколько минут.

1.5.1.1 Как конвертировать инструментальные средства mSQL для MySQL

Согласно опыту, требуется только несколько часов, чтобы преобразовать инструментальные средства, типа msql-tcl и msqljava, которые используют mSQL C API так, чтобы они работали с MySQL C API.

Процедура преобразования:

  1. Выполните скрипт оболочки msql2mysql на исходниках. Это требует программы replace, которая поставляется с MySQL.
  2. Откомпилируйте результат.
  3. Исправьте ошибки компиляции.

Различия между mSQL C API и MySQL C API:

  • MySQL применяет структуру MYSQL как тип подключения (mSQL использует int).
  • mysql_connect() берет указатель на структуру MYSQL как параметр. Просто определите его глобально или используйте malloc(). mysql_connect() также берет два параметра для определения пользователя и пароля. Вы можете устанавливать их к NULL, NULL для заданного по умолчанию использования.
  • mysql_error() берет указатель на структуру MYSQL как параметр. Только добавьте параметр для Вашего старого кода msql_error(), если Вы переносите старый код.
  • MySQL возвращает код ошибки и текстовое сообщение об ошибках для всех ошибок. mSQL возвращает только текстовое сообщение об ошибках.
  • Некоторые несовместимости существуют в результате многократных подключений к серверу MySQL из того же самого процесса.

1.5.1.2 Чем отличаются протоколы mSQL и MySQL клиент/сервер

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

Наиболее значительные вещи, которыми протокол MySQL отличается от mSQL, перечислены ниже:

  • Буфер сообщений может содержать много строк результатов.
  • Буфера сообщений динамически будут расширены, если запрос или результат больше, чем текущий (актуальный) буфер.
  • Все пакеты пронумерованы, чтобы отследить дублированные или отсутствующие пакеты, а также хакеров.
  • Все значения столбца представлены в ASCII. Длины столбцов и строк представлены в упакованном двоичном виде (1, 2 или 3 байта).
  • MySQL может работать с небуферизованными результатами (без того, чтобы иметь необходимость сохранять полный набор данных на клиенте).
  • Если одиночное чтение или запись берет больше, чем 30 секунд, сервер закрывает такое подключение.
  • Если подключение бездействует в течение 8 часов, сервер его закрывает.

1.5.1.3 Чем синтаксис mSQL 2.0 SQL отличается от MySQL

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

MySQL
Имеет следующие дополнительные типы:
  • ENUM: тип для одного значения из набора строк.
  • SET: тип для многих значений из набора строк.
  • BIGINT: тип для 64-разрядных целых чисел.
MySQL также поддерживает следующие дополнительные атрибуты для типов:
  • Опция UNSIGNED для целочисленных столбцов.
  • Опция ZEROFILL для целочисленных столбцов.
  • Опция AUTO_INCREMENT для целочисленных столбцов, которые являются PRIMARY KEY.
  • Значение DEFAULT для всех столбцов.
mSQL2
Типы столбцов mSQL соответствуют типам столбцов MySQL, показанным в таблице ниже:
Тип в mSQLТип в MySQL
CHAR(len)CHAR(len)
TEXT(len)TEXT(len). len максимальная длина. LIKE работает.
INTINT. С намного большим числом параметров!
REALREAL. Или FLOAT. Доступны версии с 4 или 8 байтами.
UINTINT UNSIGNED
DATEDATE. Использует формат ANSI SQL, а не собственный формат mSQL.
TIMETIME
MONEYDECIMAL(12,2). Значение с десятичной фиксированной точкой и двумя целыми числами.

Создание индексов:

MySQL
Индексы могут быть определены при создании таблицы инструкцией CREATE TABLE.
mSQL
Индексы должны быть созданы после того, как таблица была создана отдельными инструкциями CREATE INDEX.

Чтобы вставить уникальный идентификатор в таблицу:

MySQL
Используйте AUTO_INCREMENT как спецификатор типа столбца.
mSQL
Создайте SEQUENCE на таблице и выберите столбец _seq.

Чтобы получить уникальный идентификатор строки:

MySQL
Добавьте ключ PRIMARY KEY или UNIQUE к таблице и используйте его. Нововведение в Version 3.23.11: если PRIMARY или UNIQUE состоит только из одного столбца, и это имеет тип integer, можно также обратиться к нему как к _rowid.
mSQL
Используйте столбец _rowid. Заметьте, что _rowid может изменяться через какое-то время в зависимости от многих факторов.

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

MySQL
Добавьте столбец TIMESTAMP к таблице. Этот столбец будет автоматически установлен к текущей (актуальной) дате и времени для инструкций INSERT или UPDATE, если Вы не задаете столбцу значение, или если Вы задаете ему значение NULL.
mSQL
Используйте столбец _timestamp.

Сравнения значений NULL:

MySQL
MySQL следует стандарту ANSI SQL, и сравнение с NULL всегда вернет NULL.
mSQL
В mSQL, NULL=NULL вернет TRUE. Вы должны изменить =NULL на IS NULL и <>NULL на IS NOT NULL при переносе старого кода с mSQL на MySQL.

Сравнение строк:

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

Нечувствительный к регистру поиск:

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

Обработка конечных пробелов:

MySQL
Удаляет все пробелы в конце столбцов CHAR и VARCHAR. Если это поведение нежелательно, используйте столбцы типа TEXT, там пробелы остаются на месте.
mSQL
Сохраняет конечные пробелы.

Предложение WHERE:

MySQL
MySQL правильно располагает по приоритетам все (AND будет оценен перед OR). Чтобы получить поведение mSQL в MySQL, используйте круглые скобки (как показано в примере ниже).
mSQL
Оценивает все слева направо. Это означает, что некоторые логические вычисления более, чем с тремя параметрами не могут быть выражены никогда. Это также означает, что Вы должны изменить некоторые запросы, когда Вы мигрируете на MySQL. Это можно сделать легко, добавляя круглые скобки. Предположим, что Вы имеете следующий запрос mSQL:
mysql> SELECT * FROM table WHERE a=1 AND b=2 OR a=3 AND b=4;
Чтобы MySQL рассматривал его по методике, принятой в mSQL, Вы должны добавить скобок:
mysql> SELECT * FROM table WHERE (a=1 AND (b=2 OR (a=3 AND (b=4))));

Контроль доступа:

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

1.5.2 MySQL в сравнении с PostgreSQL

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

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

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

1.5.2.1 Стратегии разработки MySQL и PostgreSQL

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

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

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

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

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

1.5.2.2 Сравнение возможностей MySQL и PostgreSQL

На странице crash-me Вы можете найти список тех конструкций базы данных и ограничений, которые можно обнаружить автоматически программой. Обратите внимание, однако, что многие числовые ограничения могут быть изменены с параметрами запуска для соответствующей базы данных. Вышеупомянутая web-страница является чрезвычайно полезной, когда Вы хотите гарантировать, что Ваши прикладные программы работают с различными базами данных, или когда Вы хотите перенести Вашу прикладную программу из одной СУБД в другую.

MySQL предлагает следующие преимущества перед PostgreSQL:

  • MySQL вообще намного быстрее, чем PostgreSQL.
  • MySQL больше ориентирован на пользователя. Исторически сложилось так, что клиенты более стабильны, чем у PostgreSQL. MySQL намного больше использован в промышленных средах, чем PostgreSQL, обычно благодаря тому, что MySQL AB (а ранее TCX DataKonsult AB) обеспечил поддержку высшего качества для MySQL со дня первого выпуска пакета, в то время как до недавнего времени PostgreSQL был неподдерживаемым вообще.
  • MySQL работает лучше под Windows, чем PostgreSQL. MySQL выполняется как местная прикладная программа (сервис системы под NT/Win2000/WinXP), а вот PostgreSQL выполнен при помощи эмулятора cygwin. Бытует мнение, что PostgreSQL под Windows не так устройчив, но утверждать что-либо определенное тут пока рано.
  • MySQL имеет большее количество API к языкам и поддержан большим количеством существующих программ, чем PostgreSQL.
  • MySQL работает на тяжелых системах 24/7. В большинстве обстоятельств Вы никогда не должны выполнить никакие очистки на MySQL. PostgreSQL все же не поддерживает системы 24/7 потому, что Вы должны выполнить VACUUM() время от времени, чтобы восстановить место после команд UPDATE и DELETE и выполнять анализ статистики, который является критическим, чтобы получить хорошую эффективность PostgreSQL. VACUUM() также необходим после добавления многих новых строк к таблице. На занятой системе с большим количеством изменений, VACUUM() должен быть выполнен очень часто, в самых плохих случаях даже много раз в день. В течение работы VACUUM(), который может занять часы, если база данных большая, никто ничего с базой данных сделать не может. Группа разработки PostgreSQL имеет намерение исправить это безобразие, но это будет не так-то просто!
  • Работающая и проверенная репликация. Проверена на сайтах:
  • В дистрибутив MySQL входят два пакета тестирования: mysql-test-run и crash-me. Система теста активно модифицируется с кодом, чтобы проверить каждое новое свойство и почти все повторимые ошибки. Авторы проверяют MySQL ими на большом количестве платформ перед каждым выпуском. Эти тесты более сложны, чем все, что мне доводилось видеть на PostgreSQL, и они гарантируют, что MySQL надежен.
  • MySQL поддерживает большее количество стандартных функций ODBC, чем PostgreSQL.
  • MySQL имеет намного более сложную поддержку ALTER TABLE.
  • MySQL имеет поддержку для таблиц без транзакций для прикладных программ, которые нуждаются во всем быстродействии, которое они могут получить. Таблицы могут быть расположены в памяти, иметь типы HEAP или MyISAM. Подробности в разделе "7 Типы таблиц MySQL".
  • MySQL имеет поддержку для двух различных драйверов таблицы, которые поддерживают транзакции, BerkeleyDB и InnoDB. Поскольку каждый драйвер транзакции выполняется по-разному при различных условиях, это дает автору прикладной программы большее количество параметров, чтобы найти оптимальное решение.
  • Таблицы MERGE дают Вам уникальный способ немедленно делать просмотр набора идентичных таблиц и использовать их как одну. Это идеально для систем, где Вы имеете журналы, которые Вы упорядочиваете, например, раз в месяц. Подробности в разделе "7.2 Таблицы MERGE ".
  • Можно сжать таблицы только для чтения, но все еще иметь прямой доступ к строкам таблиц. Это очень полезно, когда Вы архивируете данные.
  • MySQL имеет внутреннюю поддержку для полнотекстового поиска.
  • Вы можете обращаться ко многим базам данных из того же самого подключения (зависит, конечно, от Ваших привилегий).
  • MySQL изначально написан как многопоточная программа, а вот PostgreSQL применяет процессы. Переключение контекста и доступ к общим областям памяти намного быстрее между потоками, чем между отдельными процессами, это дает MySQL большое преимущество быстродействия в многопользовательских прикладных программах, а также делает проще для MySQL работу в системах с поддержкой схемы SMP (symmetric multiprocessor).
  • MySQL имеет намного более сложную систему привилегий, чем PostgreSQL. В то время как PostgreSQL поддерживает только привилегии пользователя INSERT, SELECT и UPDATE/DELETE на базе данных или таблице, MySQL позволяет Вам определять набор различных привилегий на уровнях базы данных, таблицы и столбца. MySQL также позволяет определять привилегию на комбинациях пользователей и хостов.
  • MySQL поддерживает сжатый протокол клиент-сервер, который улучшает эффективность на медленных каналах связи.
  • MySQL понимает понятие "драйвер таблицы". Более того, это единственная реляционная база данных, сформированная на этом понятии. Это позволяет различным типам таблицы низкого уровня меняться в сервере SQL, и при этом каждый конкретный тип таблицы может быть отдельно оптимизирован для различных характеристик эффективности.
  • Все типы таблиц MySQL (за исключением InnoDB) выполнены как файлы (одна таблица на файл), что сильно облегчает проблемы копирования, перемещения, резервирования и даже создания символических связей между таблицами и базами данных (даже при выключенном сервере).
  • Инструментальные средства для ремонта и оптимизации наиболее общего типа таблиц MyISAM. Инструмент для ремонта необходим только когда происходит физическое искажение файла данных, обычно из-за аппаратного сбоя. Это позволяет восстановить большинство данных.
  • Обновление MySQL безболезненно. Когда Вы наращиваете вычислительные возможности MySQL, Вы не нуждаетесь в резервировании и восстановлении данных, которое Вы должны делать с большинством обновлений PostgreSQL.

Недостатки MySQL в сравнении с PostgreSQL:

  • Поддержка транзакций в MySQL еще не проверена так, как в PostgreSQL.
  • Так как MySQL применяет потоки, которые еще не отлажены толком на многих операционных системах, надо либо пользоваться готовыми дистрибутивами с http://www.mysql.com/downloads, либо тщательно следовать инструкциям на http://www.mysql.com/doc/I/n/Installing_source.html, чтобы получить оптимальный двоичный код, который работает во всех случаях.
  • Блокировка таблицы в нетранзакционных таблицах MyISAM во многих случаях быстрее, чем блокировки страницы, блокировки строки или versioning. Недостаток состоит в том, что, если каждый клиент не принимает во внимание, как работает блокировка таблицы, одиночный долго работающий запрос может блокировать таблицу для модификаций в течение длительного времени. Этого можно избежать при проектировании прикладной программы. Если это невозможно, рекомендуется перейти на использование транзакционных таблиц.
  • С помощью UDF (user defined functions) можно расширять MySQL с помощью обычных или агрегируемых функций SQL, но это еще не так просто и гибко, как в PostgreSQL.
  • Модификации, которые работают с несколькими таблицами, в MySQL сложнее. Это будет исправлено в MySQL 4.0 через многотабличную версию UPDATE, а в MySQL 4.1 появятся вложенные выборы (subselects). В MySQL 4.0 можно использовать многотабличное удаление, чтобы удалить данные из многих таблиц сразу в то же самое время.

PostgreSQL в настоящее время предлагает следующие преимущества над MySQL:

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

ВозможностьВерсия MySQL
Вложенные выборки4.1
Внешние ключи4.0 и 4.1
Просмотр (Views)4.2
Хранимые процедуры4.1
Расширяемые системные типыНе планируется
Unions4.0
Полные объединения4.0 или 4.1
Триггеры4.1
Constrainst4.1
Курсоры4.1 или 4.2
Расширяемые типы индексов, например, R-деревьяR-деревья планируются в версии не ниже 4.2
Таблицы с наследованиемНе планируются

Другие резоны применения PostgreSQL:

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

Недостатки PostgreSQL в сравнении с MySQL:

  • VACUUM() делает PostgreSQL непригодным, чтобы использовать его в среде 24/7.
  • Только транзакционные таблицы.
  • Намного более медленные операции INSERT, DELETE и UPDATE.

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

1.5.2.3 Сравнение производительности MySQL и PostgreSQL

На сегодняшний день есть только один эталоныый тест, который можно применить для оценки производительности MySQL, PostgreSQL и других баз данных. Его можно скачать с http://www.mysql.com/information/benchmarks.html.

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

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

При работе PostgreSQL с --fast вызывается VACUUM() после каждого сложного вызова UPDATE и DROP TABLE, чтобы сделать базу данных компактней для следующих вызовов SELECT. Время работы вызова VACUUM() измеряется отдельно от времени теста.

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

Некоторые замечания по ходу тестов:

Очень легко сделать такой тест, который покажет отличные результаты на ЛЮБОЙ базе данных. Для этого всего-то надо использовать те возможности, в которых испытуемая база данных сильна, а конкуренты слабы. Такие места есть везде, в любой системе.

Этим способом можно показать, что MySQL быстрее PostgreSQL в 36 раз (проверено лично). Но такой результат нельзя рассматривать как честный. Более того, есть тесты, в которых PostgreSQL отстает от MySQL более, чем в 2000 раз. Это происходит на тех задачах, где PostgreSQL слабее MySQL. Если замерить производительность на них и сравнить с производительностью на задачах, дающих фору MySQL, примерно столько и выйдет.

Все это сказано для того, чтобы исключить сомнения в честности тестирования. Да, есть способы доказать превосходство любой СУБД над любой другой, но здесь сравнивали честно. MySQL делает много оптимизаций, которые по каким-либо причинам не делает PostgreSQL. Это тоже верно, SQL-оптимизатор очень сложный модуль, его можно оптимизировать годами.

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

Есть один тест, разработанный Great Bridge, прочитать данные о нем можно на: http://www.greatbridge.com/about/press.php?content_id=4.

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

ОБРАТИТЕ ВНИМАНИЕ: Разработчики PostgreSQL тут не при чем! Группа авторов этого пакета решительно осудила разработку Great Bridge, так что обвинять их просто не в чем.

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

  • Тесты были выполнены с дорогим коммерческим инструментом, который делает невозможным для небольшой компании проверить эталонные тесты, или даже проверить то, как эталонные тесты были действительно выполнены. Инструмент не предназначен для тестирования баз данных вообще. Он ориентирован на тестирование прикладной программы и установки.
  • Great Bridge признал, что они оптимизировали базу данных PostgreSQL перед тестом с помощью вызова VACUUM() и настроили запуск тестов, чего они не сделали ни для одной из других включаемых баз данных. При этом авторы такого теста говорят о том, что этот процесс оптимизирует индексы и немного освобождает дисковое пространство. Оптимизированные индексы немного увеличивают эффективность. Но разработчиками MySQL было показано, что разница в скорости работы множественных выборок на базе после применения вакуумирования (VACUUM()) и до него отличается примерно в 10 раз.
  • Результаты теста были также странными. Документация теста AS3AP упоминает, что тест делает выборки, простые объединения, проектирования, агрегаты, одиночные и оптовые модификации. PostgreSQL хорош при выполнении SELECT и JOIN (особенно после вызова VACUUM()), но никуда не годится на INSERT или UPDATE. Эталонные тесты указывают, что только SELECT были выполнены (или очень немного модификаций). Это могло бы легко объяснять их хорошие результаты для PostgreSQL в этом тесте. Плохие результаты для MySQL будут очевидны ниже в этом документе.
  • Тестеры выполняли так называемый эталонный тест под Windows против Linux-машины с ODBC, которую никакой нормальный пользователь базы данных не будет когда-либо делать при управлении тяжелой многопользовательской прикладной программой. Это больше проверило драйвер ODBC и протокол Windows, используемый для связи между клиентурой и сервером, чем саму базу данных.
  • При управлении базами данных Oracle и MS-SQL (Great Bridge косвенно указал базы данных, которые они использовали в тесте) не использовался местный протокол, вместо него поставили ODBC. Любой, кто когда-либо использовал Oracle знает, что вся реальная прикладная программа использует местный интерфейс вместо ODBC. Выполнение теста через ODBC вместе с требованием, чтобы результаты отражали работу системы в реальной ситуации не имеют с честностью ничего общего. Следовало бы сделать два теста: с применением ODBC и без него, да еще и правильно все базы настроить.
  • Тестеры обращаются к тестам TPC-C, но они не упоминают где-нибудь, что это не настоящий тест TPC-C. Все тесты TPC-C должны проводиться только в соответствии с правилами, одобренными TPC Council (http://www.tpc.org). Great Bridge не делал этого. Мало того, что была нарушена марка производителя, так еще и дискредитировали эталонные тесты. Набор правил TPC Council очень строг, чтобы гарантировать, что никто не может производить неправильные результаты или делать невыполнимые инструкции. Очевидно, Great Bridge не был заинтересован выполнением этих норм.
  • После первого теста авторы MySQL сообщили Great Bridge о некоторых из наиболее очевидных ошибок, которые они сделали с MySQL:
    • Работали с версией отладки ODBC-драйвера.
    • Работали на Linux-системе, которая не была оптимизирована для потоков.
    • Использовали старую версию MySQL.
    • Не запустили MySQL с правильными параметрами для тяжелого многопользовательского режима (заданная по умолчанию установка применяется для минимального использования ресурсов).
    Great Bridge выполнил новый тест с оптимизированным ODBC-драйвером и с лучшими параметрами запуска для MySQL, но отказался применить модифицированную библиотеку glibc или стандартный двоичный дистрибутив, скомпонованный статически с этой библиотекой (применяется на 80% систем). Зато не предпринималось никаких попыток оптимизировать другие базы данных для нормальной работы. Great Bridge не связывалась с Oracle или Microsoft, это известно совершенно точно.
  • Эталонный тест был оплачен Great Bridge, и они решили издавать только выбранные результаты (вместо того, чтобы издать все).

Tim Perdue, длительное время любитель PostgreSQL и неохотный пользователь MySQL издал сравнение на http://www.phpbuilder.com/columns/tim20001112.php3.

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

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

Другая возможная проблема: старая версия glibc. Tim сам собирал пакет, а не использовал готовый дистрибутив с сайта разработчиков.

На все просьбы авторов пакета показать данные, на которых выполнялся тест, и выяснить, что пошло не так, ответа так и не последовало.

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

Заключение:

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

Более подробно о наборе тестов рассказано в разделе "5.1.4 Набор тестов MySQL Benchmark Suite".

1.6 MySQL и будущее (TODO)

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

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

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

1.6.1 Что нового должно появиться в версии 4.0

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

  • Новый формат файла определения (файлы .frm). Это даст возможность не исчерпать биты при добавлении большего количества параметров таблицы. Старый формат пока поддерживается. Все недавно созданные таблицы, однако, уже используют новый формат. Новый формат файла даст возможность добавить новые типы столбца, большее количество параметров для ключей и поддержку FOREIGN KEY.
  • mysqld в виде библиотеки. Это будет иметь тот же самый интерфейс как стандартный клиент MySQL (с дополнительной функцией, чтобы только установить параметры запуска) но будет быстрее (никакой TCP/IP или сокетной поддержки), меньше и намного проще в использовании для встроенных приложений и систем. Каждый будет способен определить во время компоновки форму использования (клиент-сервер или стационарное приложение), только определяя, которую библиотеку компоновать с программой. Такой mysqld будет поддерживать все стандартные свойства MySQL и можно использовать это в поточном клиенте, чтобы выполнить различные запросы в отдельных потоках системы.
  • Репликация должна работать с RAND() и переменными пользователя @var.
  • Интерактивная копия с очень низким снижением эффективности. Интерактивная копия облегчит добавление новой подчиненной системы. Планируется разрешить DELETE на таблицах MyISAM, чтобы использовать кэш записи. Чтобы сделать это, авторы должны модифицировать кэш записи потоков при изменении файла .MYD.
  • Лучшая репликация.
  • Большее количество функций для полнотекстового поиска.
  • Трансляция наборов символов и поддержка для совместного применения нескольких разных наборов символов.
  • Позволить пользователям менять параметры запуска без перезагрузки сервера.
  • Помощь для всех команд с клиента.
  • Защищенное соединение (по SSL).
  • SHOW COLUMNS FROM table_name (используется клиентом mysql, чтобы позволить расширения имен столбца) не должен открывать таблицу, а только файл определения. Это требует меньшего количества памяти и работает намного быстрее.
  • Новый кэш ключей.
  • При использовании SET CHARACTER SET надо транслировать весь запрос целиком, а не только строки из него. Это даст возможность пользователям свободно применять все транслируемые символы в именах базы данных, таблицы и столбцов.
  • Нужен сменный интерфейс для gethostbyaddr_r() так, чтобы можно было менять ip_to_hostname(), чтобы не блокировать другие потоки при выполнении поиска в DNS.
  • Надо добавить метод record_in_range() в таблицы MERGE, чтобы быть способным выбрать правильный индекс, когда имеется много индексов. Авторы должны также расширить интерфейс информации, чтобы получить распределение ключей для каждого индекса при выполнении analyze на всех подтаблицах.
  • SET SQL_DEFAULT_TABLE_TYPE=[MyISAM|INNODB|BDB|HEAP].

1.6.2 Возможности, планируемые в ближайшем будущем

  • Полностью безопасная репликация.
  • Подзапросы, например, такой: select id from t where grp in (select grp from g where u > 100)
  • Полученные таблицы.
    select a.col1, b.col2 from (select max(col1) as col1 from root_table) a,
    other_table b where a.col1=b.col1
    
    Это могло бы быть выполнено, автоматически создавая временные таблицы для полученных таблиц для продолжительности запроса.
  • Добавление инструкции PREPARE и посылки параметров для mysqld.
  • Надо расширить протокол клиент-сервер для передачи предупреждений.
  • Добавить опции протокола клиент-сервер, чтобы получить индикатор прогресса для длинных команд.
  • Добавить имя базы данных и реальное имя таблицы (в случае псевдонима) к структуре MYSQL_FIELD.
  • Не позволять выполнять больше, чем определенное число потоков для выполнения восстановления MyISAM.
  • Переделать INSERT ... SELECT для получения возможности опционального применения конкурентных вставок.
  • Реализовать RENAME DATABASE. Чтобы сделать это безопасным для всех драйверов таблицы, это должно работать следующим образом:
    • Создать новую базу данных.
    • Для каждой таблицы переименовать таблицу в другой базе данных, как это делается в команде RENAME.
    • Удалить старую базу данных.
  • Возвращать оригинальные типы полей при выполнении SELECT MIN(column) ... GROUP BY.
  • Много наборов результатов.
  • Переделать протокол связи так, чтобы позволить двоичную передачу значений. Чтобы делать это эффективно, нужно добавить API, чтобы позволить связывание пользовательских переменных.
  • Сделать возможным задание long_query_time с точностью до миллионных долей секунды.
  • Добавить настраиваемое приглашение командной строки клиента mysql с указанием используемой базы данных, даты, времени и т.д.
  • Добавить проверку диапазона в таблицы MERGE.
  • Скомпоновать код myisampack с сервером.
  • Портировать MySQL на BeOS.
  • Портировать клиенты MySQL на LynxOS.
  • Добавить временный кэш буфера ключей на время работы INSERT/DELETE/UPDATE так, чтобы можно было восстанавливаться, если индексный файл становится полным.
  • Если Вы выполняете ALTER TABLE на таблице, которая является ссылкой на другой диск, надо создавать временные таблицы на этом диске.
  • Реализовать тип DATE/DATETIME, который обрабатывает информацию часового пояса правильно, так, чтобы иметь дело с датами в различных часовых поясах было бы намного проще, чем сейчас.
  • FreeBSD и MIT-pthreads, бездействие потока тем не менее грузит CPU?
  • Проверить, не загружают ли блокированные потоки CPU.
  • Исправить configure так, чтобы можно компилировать все библиотеки (подобно MyISAM) без потоков.
  • Добавить опцию для периодического сброса страниц ключей для таблицы с отсроченными ключами, если они не использовались некоторое время.
  • Разрешить объединение на частях ключей (оптимизатор объединений).
  • INSERT SQL_CONCURRENT и mysqld --concurrent-insert должны выполнять вставки в конец файла, если файл блокирован на чтение.
  • Сделать опредление FOREIGN для ключей в файле .frm.
  • Вложенные вызовы DELETE.
  • Курсоры серверной стороны.
  • Проверить, работает ли 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, которая не содержит столбец, который не имеет значения DEFAULT.
  • Кэширование запросов и результатов. Это должно быть выполнено как отдельный модуль, который исследует каждый запрос, и если этот запрос находится в кэше, кэшируемый результат должен быть возвращен. При модификации таблицы из кэша должно быть удалено как можно меньше запросов. Это должно дать большое быстродействие на машинах с большой RAM, где запросы часто повторяются (подобно прикладным программам WWW). Возможно, стоит сделать так, чтобы кэшировать только запросы типа SELECT CACHED ....
  • Исправить libmysql.c, чтобы позволить две команды mysql_query() в строке без того, чтобы читать результаты или давать хорошее сообщение об ошибках.
  • Оптимизировать тип BIT, чтобы он занимал в самом деле 1 бит, (сейчас BIT занимает 1 символ).
  • Разобраться, почему MIT-pthreads ctime() не работает на целом ряде систем 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=concatenate(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 - Сообщение error/warning
    Может быть, стоит добавить и
    data_line     - Строка из файла данных
    
  • Добавить полную поддержку для VARCHAR (сейчас это уже поддержано для таблиц MyISAM).
  • Автоматический вывод из mysql в netscape.
  • LOCK DATABASES с разными опциями.
  • Изменить сортировку, чтобы распределить память в ``hunks'' для получения лучшего использования памяти.
  • Типы DECIMAL и NUMERIC не могут читать числа в экспоненциальной форме: Field_decimal::store(const char *from,uint len) должен быть переделан, чтобы это исправить.
  • Выправить mysql.cc, чтобы делать меньшее количество вызовов malloc(), когда имена полей хешированы.
  • Функции ADD_TO_SET(value,set) и REMOVE_FROM_SET(value,set)
  • Добавить использование t1 JOIN t2 ON ... и t1 JOIN t2 USING .... Сейчас Вы можете использовать его только с вызовом LEFT JOIN.
  • Добавить полную поддержку для типа unsigned long long.
  • Намного больше переменных для show status. Считать инструкции INSERT/DELETE/UPDATE. Учитывать чтения и обновления, выборки из одной таблицы и выборки с объединением, среднее число таблиц в выборе, количество запросов ORDER BY и GROUP BY.
  • Если Вы прерываете mysql в середине запроса, Вы должны открыть другое подключение и уничтожить старый запрос. Альтернативно попытка должна быть сделана, чтобы обнаружить это на сервере.
  • Добавьте интерфейс драйвера для информации таблицы, так что Вы можете использовать это как системную таблицу. Это было бы немного медленно, если Вы запросили информацию относительно всех таблиц, но очень гибко. SHOW INFO FROM tbl_name должно быть для базисной информации таблицы.
  • Добавить поддержку для UNICODE.
  • NATURAL JOIN и UNION JOIN
  • Позволить select a from crash_me left join crash_me2 using (a) . В этом случае a будет принято из таблицы crash_me.
  • Сделать так, чтобы ON и USING работали с типом объединения JOIN в оптимизаторе.
  • Oracle-подобный вызов CONNECT BY PRIOR ... для поиска в иерархических структурах и списках.
  • RENAME DATABASE
  • mysqladmin copy database new-database. Нужно добавить команду COPY к mysqld
  • Processlist должен показывать число работающих запросов и потоков.
  • SHOW HOSTS для печати информации относительно кэша hostname.
  • Опции 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, хранят старые значения, которые у них были перед началом модификации.
  • myisamchk, REPAIR и OPTIMIZE TABLE должны обрабатывать случаи, где файлы данных и/или индекса являются не файлами, а символическими ссылками.
  • Добавить моделирование pread()/pwrite() в Windows, чтобы задействовать параллельные вставки.
  • Сделать анализатор протоколов, который мог бы анализировать, какие таблицы вызываются чаще, как часто выполняются многотабличные объединения и т.д. Это должно помочь пользователям идентифицировать области или сделать проект таблицы, который мог бы быть оптимизирован, чтобы выполнить намного более эффективные запросы.
  • Добавить SUM(DISTINCT)
  • Добавить групповые функции ANY(), EVERY() и SOME(). В ANSI SQL они работают только на булевых столбцах, но можно расширять их, чтобы работать на любых столбцах/выражениях, применяя:
    value == 0 -> FALSE
    value <> 0 -> TRUE.
    
  • Исправить то, что тип для MAX(column) совпадает с типом самого столбца column.
    create table t1 (a DATE);
    insert into t1 values (now());
    create table t2 select max(a) from t1;
    show columns from t2;
    
  • Придумать хороший синтаксис для инструкции, которая UPDATE строку, если она существует, и INSERT новую строку, если такой строки пока нет. Вызов REPLACE примерно так работает с INSERT/DELETE.

1.6.3 Дела, которые должны быть выполнены позже

  • Реализовать функцию get_changed_tables(timeout,table1,table2, ...).
  • Атомные многотабличные модификации, например: update items, month set items.price=month.price where items.id=month.id;
  • Изменить чтение таблиц, чтобы использовать memmap когда возможно. Сейчас только сжатые таблицы используют memmap.
  • Добавить новую привилегию Show_priv для команд SHOW.
  • Сделать автоматический код timestamp лучше. Добавлять timestamp в файл регистрации модификации с помощью записи SET TIMESTAMP=#;.
  • Использовать в некоторых местах read/write mutex, чтобы получить большее количество быстродействия, чем есть сейчас.
  • Полная поддержка внешних ключей. Возможно, сначала следует сделать специальный процедурный язык.
  • Нужно реализовать простые просмотры (Simple views): сначала на одной таблице, позже любое выражение.
  • Автоматически закрывать таблицы, если таблица, временная таблица или временный файл получают ошибку 23 (недостаточно открытых файлов).
  • Когда найдено field=#, сменить все поля на #. Сейчас это выполнено только для некоторых простых случаев.
  • Сменить все выражения констант с расчетными выражениями, если возможно.
  • Оптимизировать ключ=выражение. Сейчас оптимизируются только ключ=поле или ключ=константа.
  • Объединить некоторые из функций копирования.
  • Переделать sql_yacc.yy к встроенному синтаксическому анализатору, чтобы уменьшить размер, и получить лучшие сообщения об ошибках.
  • Изменить синтаксический анализатор так, чтобы использовать только одно правило на разное число параметров для функции.
  • Использование полных имен вычисления в части order (для ACCESS97).
  • UNION, MINUS, INTERSECT и FULL OUTER JOIN. Сейчас работает только LEFT OUTER JOIN.
  • Разрешить применение UNIQUE на полях, которые могут быть NULL.
  • SQL_OPTION MAX_SELECT_TIME=#, чтобы поместить ограничение времени выполнения в запрос.
  • Сделать файл регистрации модификаций в конкретной базе данных.
  • Отрицательное значение LIMIT, чтобы восстановить (отыскать) данные с конца, также должно работать.
  • Предупреждения для клентских функций connect/read/write.
  • Пожалуйста, обратите внимание на изменения для safe_mysqld: согласно FSSTND (которому Debian пробует следовать), PID-файлы должны быть в каталоге /var/run/<progname>.pid, а файлы протоколов в /var/log. Было бы хорошо, если бы Вы могли помещать "DATADIR" в первое объявление "pidfile" и "log", так что размещение этих файлов может быть изменено одиночной инструкцией.
  • Разрешить клиенту запрашивать регистрацию.
  • Добавить использование zlib() для gzip-файлов, чтобы инструкция LOAD DATA INFILE работала с ними.
  • Исправить сортировку и группировку столбцов BLOB (частично уже решено).
  • Сохраненные процедуры. Сейчас не так уж и важно, поскольку сохраненные процедуры очень не стандартизированы. Другая проблема: сохраненные процедуры делают работу намного труднее для оптимизатора, и во многих случаях результат будет получен медленнее. С другой стороны, планируется добавить простой (атомный) язык модификаций, который может использоваться, чтобы писать циклы.
  • Начать использовать семафоры при подсчете потоков. Нужно сначала приделать библиотеку семафоров к MIT-pthreads.
  • Не назначать новое значение AUTO_INCREMENT, когда столбец выставляется в 0. Надо использовать NULL в таких случаях.
  • Добавить полную поддержку для JOIN с круглыми скобками.
  • Как вариант для одного потока/соединения, надо управлять набором потоков, чтобы обработать запросы.
  • Разрешить получать больше, чем одну блокировку с GET_LOCK. При выполнении этого, нужно также обработать возможные тупики, которые это изменение может представить.

Время дано согласно количеству работы, это не реальное время.

Поиск

 

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