See Раздел 4.2.11, «Причины появления ошибок Access denied ('в доступе отказано')». See Раздел 4.2.6, «Как работает система привилегий».

Все изложенное в данном разделе относится также и к родственной ошибке Lost connection to server during query.

Наиболее часто ошибка MySQL server has gone away возникает в результате тайм-аута соединения и его закрытия сервером. По умолчанию сервер закрывает соединение по прошествии 8 часов бездействия. Можно изменить лимит времени, установив при запуске mysqld переменную wait_timeout.

Другой распространенной причиной получения ошибки MySQL server has gone away является выдача команды "закрытия" на соединении MySQL с последующей попыткой выполнить запрос на закрытом соединении.

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

Обычно в этом случае выдаются следующие коды ошибки (какой из них вы получите, зависит от ОС):

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

Проверить, что MySQL на ходу, можно, запустив mysqladmin version и изучив время работы (uptime). Если проблема в аварийном завершении mysqld, то необходимо сосредоточиться на поиске причины аварии. В этом случае следует сначала проверить, не будет ли уничтожен MySQL снова при повторном задании запроса (see Раздел A.4.1, «Что делать, если работа MySQL сопровождается постоянными сбоями»).

Эти ошибки будут также выдаваться при посылке серверу неверного или слишком длинного запроса. Если mysqld получает неправильный или слишком большой пакет, то сервер предполагает, что с клиентом что-то не так, и закрывает соединение. Если необходимо выполнять объемные запросы (например, при работе с большими столбцами типа BLOB), можно увеличить предельный размер запроса, запустив mysqld с опцией -O max_allowed_packet=# (по умолчанию 1 Mб). Дополнительная память выделяется по требованию, так что mysqld будет выделять больше памяти только в случае, когда выдан большой запрос или когда mysqld должен возвратить большую строку результата!

Вы также можете получить разрыв соединения, если вы отправили пакет больше 16Мб, если ваш клиент старше чем 4.0.8, а ваш сервер 4.0.8 или новее.

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

Обращайтесь к разделу See Раздел 1.8.1.2, «Как задавать вопросы и направлять сообщения об ошибках».

Клиент MySQL на Unix может соединиться с сервером mysqld двумя различными способами: используя либо Unix-сокеты, когда соединение происходит через файл в файловой системе (по умолчанию /tmp/mysqld.sock), либо TCP/IP с соединением через номер порта. Unix-сокеты обеспечивают большую скорость, чем TCP/IP, но могут применяться только при соединении с сервером на том же компьютере. Unix-сокеты используются, если не задано имя хоста или если задано специальное имя localhost.

В Windows, если сервер mysqld выполняется в 9x/Me, возможно соединение только через TCP/IP. Если сервер работает на NT/2000/XP и mysqld запущен с --enable-named-pipe, то можно также устанавливать соединение с помощью именованных каналов. Имя именованного канала - MySQL. Если имя хоста не указано при соединении с mysqld, то клиент MySQL сначала попробует подключиться к именованному каналу, а если этого сделать не удастся, то к порту TCP/IP. Можно предписать использование именованных каналов в Windows, используя . в качестве имени хоста.

Ошибка (2002) Can't connect to ... обычно говорит о том, что MySQL не запущен на данной системе или что при попытке соединиться с сервером mysqld используется неверный сокет-файл или порт TCP/IP.

Для начала проверьте (с помощью ps или диспетчера задач в Windows), выполняется ли на сервере процесс с именем mysqld! Если процесса mysqld нет, то его необходимо запустить (see Раздел 2.4.2, «Проблемы при запуске сервера MySQL»).

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

shell> mysqladmin version
shell> mysqladmin variables
shell> mysqladmin -h `hostname` version variables
shell> mysqladmin -h `hostname` --port=3306 version
shell> mysqladmin -h 'ip for your host' version
shell> mysqladmin --protocol=socket --socket=/tmp/mysql.sock version

Обратите внимание на то, что для hostname используются обратные кавычки вместо прямых; это задает подстановку вывода hostname (т.е. текущего имени хоста) в команду mysqladmin.

Ниже приводится несколько причин, которые могут вызывать ошибку Can't connect to local MySQL server:

Если получено сообщение об ошибке Can't connect to MySQL server on some_hostname, то чтобы выяснить, в чем проблема, можно попробовать выполнить следующие действия:

Ошибка, подобная следующей:

Host 'hostname' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts'

говорит о том, что от хоста hostname имело место большое количество (max_connect_errors) прерванных посредине запросов на соединение к mysqld. После max_connect_errors неудачных запросов mysqld делает предположение, что что-то не так (может, атака от кракера), и блокирует последующие соединения с узла до того момента, пока кто-нибудь не выполнит команду mysqladmin flush-hosts.

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

shell> safe_mysqld -O max_connect_errors=10000 &

Заметим, что если для некоторого хоста получено это сообщение об ошибке, то следует сначала проверить, все ли в порядке с TCP/IP-соединениями от этого хоста. Если TCP/IP-соединения не работают, то увеличивать значение переменной max_connect_errors бесполезно!

Получение ошибки Too many connections при попытке соединиться с MySQL означает, что уже есть max_connections клиентов, соединившихся с сервером mysqld.

Если есть потребность в большем количестве соединений, чем задано по умолчанию (100), то следует перезапустить mysqld с заданием большего значения для переменной max_connections.

Заметим, что фактически mysqld разрешает соединяться (max_connections+1) клиентам. Последнее соединение зарезервировано для пользователя с привилегией SUPER. Если не наделять этой привилегией обычных пользователей (они могут обойтись и без нее), то администратор, располагая этой привилегией, может войти и использовать SHOW PROCESSLIST для выяснения причин неполадок (see Раздел 4.5.6.6, «SHOW PROCESSLIST»).

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

Получение ошибки/предупреждения: Warning: Some non-transactional changed tables couldn't be rolled back при попытке сделать ROLLBACK означает, что для некоторых использованных в транзакции таблиц не поддерживаются транзакции. Команда ROLLBACK на эти нетранзакционные таблицы не подействует.

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

Чтобы проверить тип таблицы, следует выполнить:

SHOW TABLE STATUS LIKE 'table_name'. See Раздел 4.5.6.2, «SHOW TABLE STATUS».

Можно проверить, какие расширения поддерживает исполняемый файл mysqld, выполнив:

show variables like 'have_%'. See Раздел 4.5.6.4, «SHOW VARIABLES».

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

mysql: Out of memory at line 42, 'malloc.c'

mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)

ERROR 2008: MySQL client ran out of memory

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

Чтобы устранить данную проблему, сначала проверьте правильность запроса. Действительно ли есть необходимость в том, чтобы запрос возвращал так много строк? Если да, то можно использовать mysql --quick, где для извлечения результирующего множества применяется mysql_use_result(). При этом уменьшается загрузка клиента (но увеличивается загрузка сервера).

Когда клиент MySQL или сервер mysqld получают пакет с размерами, превышающими max_allowed_packet байтов, программа выдает ошибку Packet too large и закрывает соединение.

В MySQL 3.23 размер самого большого возможного пакета составляет 16 Mб (из-за ограничений клиент-серверного протокола). В MySQL 4.0.1 и выше размер пакета ограничивается только количеством имеющейся на сервере памяти (вплоть до теоретического максимума в 2 Гб).

Коммуникационный пакет - это одна команда SQL, посылаемая серверу, или одна строка, посылаемая клиенту.

Когда клиент MySQL или сервер mysqld получают пакет, размеры которого превышают max_allowed_packet байтов, программа выдает ошибку Packet too large и закрывает соединение. Если коммуникационный пакет слишком велик, то в некоторых клиентах может быть выдана ошибка Lost connection to MySQL server during query.

Отметим, что и клиент, и сервер имеют свои собственные переменные max_allowed_packet. Если требуется обрабатывать большие пакеты, то эту переменную необходимо увеличить как для клиента, так и для сервера.

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

Если используется клиент mysql, то можно задать больший буфер, запустив клиент посредством mysql --set-variable=max_allowed_packet=8M. Для других клиентов существуют собственные методы установки этой переменной. Обратите внимание, что начиная с 4.0 использование --set-variable не рекомендуется, используйте просто --max-allowed-packet=8M.

Для установки max_allowed_packet большего размера в mysqld можно также использовать файл опций. Например, если в таблице предполагается хранить значение типа MEDIUMBLOB максимальной длины, то нужно запускать сервер с опцией set-variable=max_allowed_packet=16M.

При использовании больших пакетов могут также возникать непредсказуемые проблемы, если вы работаете с большими значениями типа BLOB, и mysqld не был предоставлен доступ к достаточному объему памяти для обработки запроса. Если есть подозрение, что дело в этом, попробуйте добавить ulimit -d 256000 в начале скрипта safe_mysqld и перезапустить mysqld.

Начиная с MySQL 3.23.40 ошибка Aborted connection выдается только в случае, если mysqld запущен с --warnings.

В журнале ошибок могут присутствовать ошибки наподобие этой:

010301 14:38:23 Aborted connection 854 to db: 'users' user: 'josh'

(see Раздел 4.9.1, «Журнал ошибок»).

Такие ошибки сигнализируют об одной из следующих ситуаций:

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

Значение переменной сервера Aborted_connects увеличивается в следующих случаях:

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

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

Существует несколько случаев, когда выдается эта ошибка:

Получение для некоторых запросов ошибки вида:

Can't create/write to file '\\sqla3fe_0.ism'.

означает, что MySQL не может создать в заданном временном каталоге временный файл для результирующего набора (приведенное сообщение об ошибке типично для Windows, примерно такой же вид имеет сообщение об ошибке Unix). Чтобы решить проблему, запустите mysqld с --tmpdir=path или добавьте в своем файле опций:

[mysqld]
tmpdir=C:/temp

исходя из предположения, что каталог c:\\temp существует (see Раздел 4.1.2, «Файлы параметров my.cnf»).

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

shell> perror 28
Error code 28: No space left on device

Если получена ошибка Commands out of sync; you can't run this command now в клиентском коде, то клиентские функции вызываются в неправильном порядке!

Это может произойти, например, если используется mysql_use_result() и делается попытка выполнить новый запрос до того, как вызвана mysql_free_result(), или если клиент пытается выполнить два возвращающих данные запроса без обращения к mysql_use_result() либо mysql_store_result() в промежутке между ними.

Получение следующей ошибки:

Found wrong password for user: 'some_user@some_host'; ignoring user

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

Причины проблемы и способы ее решения могут быть следующими:

Получение ошибки Table 'xxx' doesn't exist или Can't find file: 'xxx' (errno: 2), означает, что в текущей базе данных не существует таблицы с именем xxx.

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

Проверить, какие таблицы имеются в текущей базе данных, можно с помощью SHOW TABLES. see Раздел 4.5.6, «Синтаксис команды SHOW».

Получение ошибки наподобие:

MySQL Connection Failed: Can't initialize character set xxx

Означает, что имеется одна из следующих ситуаций:

Получение от MySQL ERROR '...' not found (errno: 23), Can't open file: ... (errno: 24), или любой другой ошибки с номером 23 или 24 означает, что для MySQL выделено недостаточно файловых дескрипторов. Можно использовать утилиту perror для получения описания ошибки с определенным номером:

shell> perror 23
File table overflow
shell> perror 24
Too many open files
shell> perror 11
Resource temporarily unavailable

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

Чтобы предписать mysqld держать одновременно открытыми меньше файлов, можно уменьшить табличный кэш, задав safe_mysqld опцию -O table_cache=32 (значение по умолчанию 64). Уменьшение значения max_connections также уменьшит количество открытых файлов (по умолчанию значение переменной 90).

Чтобы изменить число доступных mysqld файловых дескрипторов, можно использовать опцию --open-files-limit=# в safe_mysqld или опцию -O open-files-limit=# в mysqld (see Раздел 4.5.6.4, «SHOW VARIABLES»). Проще всего это сделать путем добавления опции в файл опций (see Раздел 4.1.2, «Файлы параметров my.cnf»). Если используется ранняя версия mysqld, не поддерживающая эту возможность, можно отредактировать скрипт safe_mysqld. В скрипте есть закомментированная строка ulimit -n 256; можно, убрав символ ‘#’, раскомментировать эту строку и, заменив значение 256 другим, повлиять на количество доступных mysqld файловых дескрипторов.

При помощи ulimit (и open-files-limit) можно увеличить количество файловых дескрипторов только до предела, установленного в операционной системе. Существует также "жесткий" предел, который может быть переопределен только при запуске safe_mysqld или mysqld от имени пользователя root (но помните, что в этом случае также следует использовать опцию --user=...). Если необходимо увеличить предел ОС по количеству доступных отдельному процессу файловых дескрипторов, обращайтесь к документации по своей операционной системе.

Обратите внимание: при использовании tcsh ulimit работать не будет! Кроме того, tcsh будет сообщать неверные значения при запросе текущих пределов! В этом случае необходимо запускать safe_mysqld с использованием sh!

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

/tmp/ccFKsdPa.o: In function `main':
/tmp/ccFKsdPa.o(.text+0xb): undefined reference to `mysql_init'
/tmp/ccFKsdPa.o(.text+0x31): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x57): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x69): undefined reference to `mysql_error'
/tmp/ccFKsdPa.o(.text+0x9a): undefined reference to `mysql_close'

то их можно устранить, добавив -Lpath-to-the-mysql-library -lmysqlclient в самом конце используемой команды линкования.

Если выдаются ошибки undefined reference для функции uncompress или compress, добавьте в самом конце команды линкования -lz и повторите попытку!

Если получены ошибки undefined reference для функций, которые должны присутствовать в системе, таких как connect, то сверьтесь по странице руководства для данной функции, какие библиотеки необходимо добавить в команде линкования!

Получение ошибок undefined reference для функций, отсутствующих в используемой системе, наподобие следующего:

mf_format.o(.text+0x201): undefined reference to `__lxstat'

обычно означает, что библиотека скомпилирована в системе, которая не на 100% совместима с системой пользователя. В этом случае необходимо загрузить последнюю поставку с исходными текстами MySQL и откомпилировать библиотеку самостоятельно (see Раздел 2.3, «Установка исходного дистрибутива MySQL»).

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

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

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

Сервер mysqld может запускаться и работать от любого пользователя. Чтобы настроить mysqld для работы под Unix-пользователем user_name, необходимо выполнить следующие действия:

К этому моменту процесс mysqld должен без помех работать под Unix-пользователем user_name. Однако содержимое таблиц привилегий не изменяется. По умолчанию (сразу после выполнения скрипта инсталляции таблиц привилегий mysql_install_db) MySQL-пользователь root является единственным пользователем с правами на доступ к базе данных mysql, а также на создание и удаление баз данных. Если вы не меняли этих полномочий, они по-прежнему действительны. То, что вы вошли в систему как Unix-пользователь, отличный от root, не может вам помешать получить доступ к MySQL в качестве MySQL-пользователя root; просто задайте клиентской программе опцию -u root.

Отметим, что работа с MySQL в качестве MySQL-пользователя root посредством указания -u root в командной строке не имеет ничего общего с выполнением MySQL под Unix-пользователем root, или вообще под каким бы то ни было Unix-пользователем. Привилегии доступа и имена пользователей MySQL никак не связаны с именами Unix-пользователей. Единственная связь с именами Unix-пользователей заключается в том, что если при запуске клиентской программы не задана опция -u, то клиент попытается соединиться, используя в качестве имени MySQL-пользователя имя Unix-аккаунта.

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

Если существуют проблемы с правами доступа к файлам, например, если mysql при создании таблицы выдает следующее сообщение об ошибке:

ERROR: Can't find file: 'path/with/filename.frm' (Errcode: 13)

то, возможно, при запуске сервера mysqld неправильно устанавливается переменная окружения UMASK. По умолчанию значение umask 0660. Его можно изменить, запуская safe_mysqld следующим образом:

shell> UMASK=384 # = 600 in octal
shell> export UMASK
shell> /path/to/safe_mysqld &

По умолчанию MySQL создает каталоги баз данных и RAID-каталоги с правами доступа 0700. Такое поведение можно изменить, установив переменную UMASK_DIR. Если установить эту переменную, то при создании новых каталогов используется комбинация UMASK и UMASK_DIR. Например, если требуется, чтобы доступ ко всем новым каталогам получала группа, то можно выполнить:

shell> UMASK_DIR=504 # = 770 in octal
shell> export UMASK_DIR
shell> /path/to/safe_mysqld &

В версии MySQL 3.23.25 и выше MySQL предполагает, что значения для UMASK и UMASK_DIR, начинающиеся с нуля, восьмеричные.

see Приложение F, Переменные окружения.

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

Сначала надо попробовать локализовать проблему. Определите, что происходит: то ли демон mysqld прекращает работу, то ли проблема связана с клиентом. Узнать, сколько времени сервер mysqld уже работает, можно, выполнив mysqladmin version. Если mysqld прекратил выполнение, то для выяснения причин можно изучить файл mysql-data-directory/`hostname`.err (see Раздел 4.9.1, «Журнал ошибок»).

Причиной многих аварий MySQL являются поврежденные индексные файлы или файлы данных. MySQL обновляет данные на диске, используя системный вызов write(), после каждой команды SQL и до того, как клиент будет уведомлен о результате (однако при выполнении с delay_key_write это не так: записываются только данные). Отсюда следует, что данные не пострадают даже в случае аварийного завершения mysqld, поскольку ОС позаботится о том, чтобы те данные, которые не сброшены, были записаны на диск. Можно заставить MySQL сбрасывать все на диск после каждой SQL-команды, запустив mysqld с --flush.

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

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

Если для MySQL пароль пользователя root никогда не устанавливался, то для соединения с сервером в качестве пользователя root пароль не потребуется. Рекомендуется всегда устанавливать пароль для каждого пользователя (see Раздел 4.2.2, «Как обезопасить MySQL от хакеров»).

Если вы забыли установленный для root пароль, то новый пароль можно задать при помощи следующей процедуры:

Есть и другой способ установки нового пароля - с помощью клиента mysql:

Когда возникает ситуация переполнения диска, MySQL реагирует следующим образом:

Для снижения остроты проблемы можно принять следующие меры:

Исключение составляет использование REPAIR или OPTIMIZE, а также случай, когда индексы создаются в пакете после команды LOAD DATA INFILE или ALTER TABLE.

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

Переменная окружения TMPDIR содержит полное имя каталога, в котором в MySQL хранит временные файлы. Если TMPDIR не установлена, то MySQL использует каталог, заданный в системе по умолчанию (обычно это /tmp или /usr/tmp). Если файловая система, в которой находится каталог временных файлов, слишком мала, то следует, отредактировав safe_mysqld, присвоить TMPDIR значение, указывающее на каталог в "более просторной" файловой системе! Временный каталог можно также задавать с помощью опции --tmpdir к mysqld.

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

При сортировке (ORDER BY или GROUP BY) MySQL обычно использует один или два временных файла. Максимальный размер требующегося для этого пространства на диске составляет:

(размер сортируемых данных + sizeof(указатель базы данных))
* количество совпавших записей
* 2

sizeof(указатель базы данных) обычно равен 4, но со временем для очень больших таблиц может увеличиться.

Для некоторых запросов SELECT MySQL также создает временные SQL-таблицы. Они не скрытые и имеют имена вида SQL_*.

ALTER TABLE создает временную таблицу в одном каталоге с исходной таблицей.

Если вы используете версию 4.1 или более новую - вы можете распределять нагрузку между несколькими физическими дисками путем установления --tmpdir в список путей, разделенных двоеточием : (точкой с запятой ; - под Winodws). Они будут использоваться в ротации. Замечание: эти пути должны представлять различные физические диски, а не различные разделы одного и того же диска.

Если возникают проблемы с тем, что кто угодно может удалить коммуникационный сокет MySQL /tmp/mysql.sock, то в большинстве версий Unix можно защитить содержимое /tmp, установив на каталоге ``липучий'' (sticky) бит. Войдите в систему как пользователь root и выполните следующую команду:

shell> chmod +t /tmp

Это защитит ваш каталог /tmp: теперь удалять в нем файлы смогут только их владельцы или суперпользователь (root).

Проверить, установлен ли ``липучий'' (sticky) бит, можно, выполнив ls -ld /tmp. Если последним битом прав является t, то бит установлен.

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

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

shell> mysqladmin --socket=/path/to/socket version

Если есть проблема с тем, что SELECT NOW() возвращает значения GMT, а не местное время, то необходимо установить переменную окружения TZ равной местному часовому поясу. Это должно быть сделано для окружения, в котором работает сервер, например, в safe_mysqld или mysql.server (see Приложение F, Переменные окружения).

По умолчанию поиск в MySQL является независимым от регистра символов (хотя существуют некоторые кодировки, которые всегда чувствительны к регистру, такие как czech). Это означает, что при поиске с помощью col_name LIKE 'a%' будут выданы все значения столбца, начинающиеся на A или a. Если необходимо выполнить тот же поиск с учетом регистра, для проверки префикса следует использовать что-то вроде INSTR(col_name, "A")=1 или STRCMP(col_name, "A") = 0, если значение в столбце точно равно A.

Простые операции сравнения (>=, >, =, <, <=, сортировка и группировка) основываются на "сорте" каждого символа. Символы одного сорта (такие как E, e и E) обрабатываются как одинаковые символы!

В старых версиях MySQL сравнения по LIKE выполнялись над символами, переведенными в верхний регистр (E == e, но E <> E). В новых версиях MySQL LIKE работает точно так же, как другие операторы сравнения.

Если необходимо, чтобы столбец всегда обрабатывался в с учетом регистра, объявите его с типом BINARY (see Раздел 6.5.3, «Синтаксис оператора CREATE TABLE»).

Если вы используете китайские данные в так называемой кодировке big5, то имеет смысл объявить все символьные столбцы как BINARY. Сортировка таких столбцов будет работать, поскольку порядок сортировки символов в кодировке big5 основывается на порядке кодов ASCII.

Значения типа DATE имеют формат YYYY-MM-DD; согласно стандарту ANSI SQL, никакой другой формат не допускается. Пользователь должен применять этот формат в выражениях UPDATE и в определении WHERE операторов SELECT. Например:

mysql> SELECT * FROM tbl_name WHERE date >= '1997-05-05';

Из соображений удобства MySQL автоматически преобразовывает дату в число, если дата используется в числовом контексте (и наоборот). Благодаря своей ``разумности'' MySQL допускает также ``мягкую'' строковую форму при обновлении и в определении WHERE, сравнивающем дату со столбцом типа TIMESTAMP, DATE или DATETIME ("мягкая" форма означает, что для разделения составляющих даты можно использовать любой знак пунктуации; например, 1998-08-15 и 1998#08#15 эквивалентны). MySQL может также преобразовывать в даты строки, не содержащие разделителей (наподобие 19980815), при условии, что представляемая строкой дата не лишена смысла.

Специальная дата 0000-00-00 может записываться и извлекаться в виде 0000-00-00. При использовании даты 0000-00-00 из MyODBC она будет автоматически преобразована в NULL в версии MyODBC 2.50.12 и выше, так как ODBC не обеспечивает обработку такого рода дат.

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

mysql> INSERT INTO tbl_name (idate) VALUES (19970505);
mysql> INSERT INTO tbl_name (idate) VALUES ('19970505');
mysql> INSERT INTO tbl_name (idate) VALUES ('97-05-05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997.05.05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997 05 05');
mysql> INSERT INTO tbl_name (idate) VALUES ('0000-00-00');
mysql> SELECT idate FROM tbl_name WHERE idate >= '1997-05-05';
mysql> SELECT idate FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT MOD(idate,100) FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT idate FROM tbl_name WHERE idate >= '19970505';

Однако приведенные ниже команды работать не будут:

mysql> SELECT idate FROM tbl_name WHERE STRCMP(idate,'19970505')=0;

STRCMP() - строковая функция, следовательно, она преобразует idate в строку и сравнивает строки. Функция не станет преобразовывать 19970505 в дату и сравнивать даты.

Заметим, что MySQL осуществляет очень ограниченную проверку правильности дат, поэтому такая некорректная дата, как 1998-2-31, будет занесена в базу.

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

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

Концепция NULL-значения часто вводит в заблуждение новичков в SQL, которые считают, что NULL - то же, что и пустая строка "". Это ошибка! Например, следующие команды совершенно различны:

mysql> INSERT INTO my_table (phone) VALUES (NULL);
mysql> INSERT INTO my_table (phone) VALUES ("");

Обе команды вставляют значение в столбец phone, но первая - значение NULL, а вторая - пустую строку. Смысл первого можно передать как ``номер телефона неизвестен'', смысл второго - ``у нее нет телефона''.

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

mysql> SELECT NULL,1+NULL,CONCAT('Invisible',NULL);

Если в столбце нужно найти значения NULL, то нельзя использовать условие =NULL. Следующая команда не возвращает ни одной строки, поскольку для любого выражения expr = NULL ЛОЖНО:

mysql> SELECT * FROM my_table WHERE phone = NULL;

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

mysql> SELECT * FROM my_table WHERE phone IS NULL;
mysql> SELECT * FROM my_table WHERE phone = "";

Заметим, что добавлять индекс по столбцу, в котором допускаются значения NULL, можно только в случае, если вы работаете с версией MySQL 3.23.2 или выше, а используемый тип таблиц - MyISAM или InnoDB. В более ранних версиях или для других типов таблиц необходимо объявлять такие столбцы с атрибутом NOT NULL. Это также подразумевает, что тогда нельзя вставлять NULL в индексированный столбец.

При чтении данных с помощью LOAD DATA INFILE пустые поля обновляются значениями ''. Если необходимо поместить в столбец значение NULL, то в текстовом файле следует использовать \N. Также при некоторых обстоятельствах можно использовать слово-литерал NULL (see Раздел 6.4.9, «Синтаксис оператора LOAD DATA INFILE»).

При использовании ORDER BY значения NULL выдаются первыми. В версиях предшествующих 4.0.2, при сортировке в убывающем порядке при помощи DESC, значения NULL также выдаются последними. При использовании GROUP BY все значения NULL считаются равными.

Для обработки NULL предназначены операторы IS NULL и IS NOT NULL, а также функция IFNULL().

Для некоторых типов столбцов значения NULL обрабатываются специальным образом. Если NULL вставляется в первый в таблице столбец типа TIMESTAMP, то в него помещается значение текущей даты и времени. При вставке NULL в AUTO_INCREMENT-столбец вставляется следующее число последовательности.

Псевдонимы можно использовать для ссылки на столбец в GROUP BY, ORDER BY или в части HAVING, а также для лучшего именования столбцов:

SELECT SQRT(a*b) as rt FROM table_name GROUP BY rt HAVING rt > 0;
SELECT id,COUNT(*) AS cnt FROM table_name GROUP BY id HAVING cnt > 0;
SELECT id AS "Customer identity" FROM table_name;

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

SELECT id,COUNT(*) AS cnt FROM table_name WHERE cnt > 0 GROUP BY id;

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

Поскольку MySQL до 4.1.0 не поддерживает вложенных запросов, а также использование более одной таблицы в команде DELETE (до версии 4.0), то для удаления строк из 2 взаимосвязанных таблиц следует использовать следующий подход:

где selected_rows - количество строк, выбранных по запросу в п.1.

Если общее количество символов в запросе с related_column больше 1048576 (значение max_allowed_packet по умолчанию), то следует разбить запрос на меньшие части и выполнить несколько команд DELETE. Если related_column является индексом/индексирован, то самый быстрый DELETE получится при удалении 100-1000 идентификаторов related_column за запрос. Если related_column не индекс, то скорость не зависит от количества аргументов в операторе IN.

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

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

Поля типов FLOAT, DOUBLE и DECIMAL следующие.

CREATE TABLE t1 (i INT, d1 DECIMAL(9,2), d2 DECIMAL(9,2));
INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),
(2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),
(2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),
(4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),
(5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),
(6, 0.00, 0.00), (6, -51.40, 0.00);

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b
    -> FROM t1 GROUP BY i HAVING a <> b;
+------+--------+-------+
| i    | a      | b     |
+------+--------+-------+
|    1 |  21.40 | 21.40 |
|    2 |  76.80 | 76.80 |
|    3 |   7.40 |  7.40 |
|    4 |  15.40 | 15.40 |
|    5 |   7.20 |  7.20 |
|    6 | -51.40 |  0.00 |
+------+--------+-------+

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

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

mysql> SELECT i, ROUND(SUM(d1), 2) AS a, ROUND(SUM(d2), 2) AS b
    -> FROM t1 GROUP BY i HAVING a <> b;
+------+--------+-------+
| i    | a      | b     |
+------+--------+-------+
|    1 |  21.40 | 21.40 |
|    2 |  76.80 | 76.80 |
|    3 |   7.40 |  7.40 |
|    4 |  15.40 | 15.40 |
|    5 |   7.20 |  7.20 |
|    6 | -51.40 |  0.00 |
+------+--------+-------+

Вот как выглядят числа в столбце 'a':

mysql> SELECT i, ROUND(SUM(d1), 2)*1.0000000000000000 AS a,
    -> ROUND(SUM(d2), 2) AS b FROM t1 GROUP BY i HAVING a <> b;
+------+----------------------+-------+
| i    | a                    | b     |
+------+----------------------+-------+
|    1 |  21.3999999999999986 | 21.40 |
|    2 |  76.7999999999999972 | 76.80 |
|    3 |   7.4000000000000004 |  7.40 |
|    4 |  15.4000000000000004 | 15.40 |
|    5 |   7.2000000000000002 |  7.20 |
|    6 | -51.3999999999999986 |  0.00 |
+------+----------------------+-------+

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

ПРЕДУПРЕЖДЕНИЕ: НИКОГДА НЕ ПОЛАГАЙТЕСЬ НА ДАННЫЙ МЕТОД В СВОЕМ ПРИЛОЖЕНИИ, ЭТО ПРИМЕР ТОГО, КАКИЕ МЕТОДЫ НЕ СЛЕДУЕТ ИСПОЛЬЗОВАТЬ!!!

mysql> SELECT i, ROUND(SUM(d1), 2)*1 AS a, ROUND(SUM(d2), 2)*1 AS b
    -> FROM t1 GROUP BY i HAVING a <> b;
+------+--------+------+
| i    | a      | b    |
+------+--------+------+
|    6 | -51.40 | 0.00 |
+------+--------+------+

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

Правильный способ сравнения чисел с плавающей запятой заключается в том, чтобы сначала определиться с допустимым отклонением одного числа от другого, а затем при сравнении учитывать этот допуск. Например, если мы договоримся, что числа должны считаться одинаковыми, если они равны с точностью до одной десятитысячной (0,0001), то сравнение должно проводиться следующим образом:

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
    -> GROUP BY i HAVING ABS(a - b) > 0.0001;
+------+--------+------+
| i    | a      | b    |
+------+--------+------+
|    6 | -51.40 | 0.00 |
+------+--------+------+
1 row in set (0.00 sec)

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

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
    -> GROUP BY i HAVING ABS(a - b) < 0.0001;
+------+-------+-------+
| i    | a     | b     |
+------+-------+-------+
|    1 | 21.40 | 21.40 |
|    2 | 76.80 | 76.80 |
|    3 |  7.40 |  7.40 |
|    4 | 15.40 | 15.40 |
|    5 |  7.20 |  7.20 |
+------+-------+-------+

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

Если работа ALTER TABLE прекращается с ошибкой, подобной приведенной ниже:

Error on rename of './database/name.frm' to './database/B-a.frm' (Errcode: 17)

то проблема может быть связана с тем, что MySQL аварийно завершился на предыдущей команде ALTER TABLE и осталась старая таблица с именем A-что_нибудь или B-что_нибудь. В этом случае перейдите в каталог данных MySQL и удалите все файлы, имена которых начинаются с A- или B- (их можно и не удалять, а куда-либо переместить).

ALTER TABLE работает следующим образом:

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

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

SELECT col_name1, col_name2, col_name3 FROM tbl_name;

возвратит столбцы в порядке col_name1, col_name2, col_name3, тогда как:

SELECT col_name1, col_name3, col_name2 FROM tbl_name;

возвратит столбцы в порядке col_name1, col_name3, col_name2.

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

Если порядок столбцов все-таки требуется изменить, то сделать это можно следующим образом:

Ниже перечислены ограничения, относящиеся к временным таблицам.