PHP5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<announce-subscribe@lists.mysql.com> announce

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

<mysql-subscribe@lists.mysql.com> mysql

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

<mysql-digest-subscribe@lists.mysql.com> mysql-digest

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

<bugs-subscribe@lists.mysql.com> bugs

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

<bugs-digest-subscribe@lists.mysql.com> bugs-digest

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

<internals-subscribe@lists.mysql.com> internals

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

<internals-digest-subscribe@lists.mysql.com> internals-digest

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

<java-subscribe@lists.mysql.com> java

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

<java-digest-subscribe@lists.mysql.com> java-digest

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

<win32-subscribe@lists.mysql.com> win32

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

<win32-digest-subscribe@lists.mysql.com> win32-digest

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

<myodbc-subscribe@lists.mysql.com> myodbc

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

<myodbc-digest-subscribe@lists.mysql.com> myodbc-digest

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

<mysqlcc-subscribe@lists.mysql.com> mysqlcc

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

<mysqlcc-digest-subscribe@lists.mysql.com> mysqlcc-digest

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

<plusplus-subscribe@lists.mysql.com> plusplus

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

<plusplus-digest-subscribe@lists.mysql.com> plusplus-digest

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

<msql-mysql-modules-subscribe@lists.mysql.com> msql-mysql-modules

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

<msql-mysql-modules-digest-subscribe@lists.mysql.com> msql-mysql-modules-digest

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

<mysql-france-subscribe@yahoogroups.com> Французский список рассылки, <list@tinc.net> Корейский список рассылки

Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql your@e-mail.address.

<mysql-de-request@lists.4t2.com> Немецкий список рассылки

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

<mysql-br-request@listas.linkway.com.br> Португальский список рассылки

Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql-br your@e-mail.address.

<mysql-alta@elistas.net> Испанский список рассылки

Чтобы подписаться на этот список рассылки, отправьте сообщение subscribe mysql your@e-mail.address.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Циклы, для которых требуются транзакции, обычно могут кодироваться с помощью LOCK 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() (see Раздел 8.4.3.31, «mysql_insert_id()»).

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

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mysql> SELECT * FROM temporary_table, temporary_table AS t2;

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

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

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

и

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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