C.5.8. Известные Проблемы в MySQL

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

Для получения информации о специфичных для платформы проблемах см. установку и инструкции портирования в Разделе 2.1, "Общее Руководство Установки", и MySQL Internals: Портирование на Другие Системы.

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

Подоптимизация запросов для IN не столь эффективно что касается =.
Даже если Вы используете lower_case_table_names=2 (который позволяет MySQL помнить случай, используемый для баз данных и имен таблиц), MySQL не помнит случай, используемый для имен базы данных для функции DATABASE() или в пределах различных журналов (на нечувствительных к регистру системах).
Отбрасывание a FOREIGN KEY ограничение не работает в репликации, потому что у ограничения может быть другое имя на ведомом устройстве.
REPLACE (и LOAD DATA с REPLACE опция), не инициировал ON DELETE CASCADE.
DISTINCT с ORDER BY не работает внутри GROUP_CONCAT() если Вы не используете все и только те столбцы, которые находятся в DISTINCT список.
Вставляя большое целочисленное значение (между ²⁶³ и ^264–1) в десятичное число или строковый столбец, это вставляется как отрицательная величина, потому что число оценивается в контексте целого числа со знаком.
С основанным на операторе двоичным журналированием ведущее устройство пишет выполняемые запросы в двоичный журнал. Это - очень быстрый, компактный, и эффективный метод журналирования, который работает отлично в большинстве случаев. Однако, для данных на ведущем устройстве и ведомом устройстве возможно стать отличающимся, если запрос разрабатывается таким способом, которым модификация данных недетерминирована (обычно не рекомендуемая практика, даже за пределами репликации).

Например:
- CREATE TABLE ... SELECT или INSERT ... SELECT операторы, которые вставляют нуль или NULL значения в AUTO_INCREMENT столбец.
- DELETE если Вы удаляете строки из таблицы, у которой есть внешние ключи с ON DELETE CASCADE свойства.
- REPLACE ... SELECT, INSERT IGNORE ... SELECT если у Вас есть двойные значения ключа во вставленных данных.
Если и только если предыдущие запросы имеют нет ORDER BY пункт, гарантирующий детерминированный порядок.

Например, для INSERT ... SELECT без ORDER BY, SELECT может возвратить строки в различном порядке (который заканчивается, подряд имея различные разряды, следовательно вкладывая различное число AUTO_INCREMENT столбец), в зависимости от выбора, сделанного оптимизаторами на ведущем устройстве и ведомом устройстве.

Запрос оптимизируется по-другому на ведущем устройстве и ведомом устройстве только если:
- Таблица сохранена, используя различный механизм хранения на ведущем устройстве чем на ведомом устройстве. (Возможно использовать различные механизмы хранения на ведущем устройстве и ведомом устройстве. Например, можно использовать InnoDB на ведущем устройстве, но MyISAM на ведомом устройстве, если у ведомого устройства есть менее доступное дисковое пространство.)
- Буферные размеры MySQL (key_buffer_size, и так далее), отличаются на ведущем устройстве и ведомом устройстве.
- Ведущее устройство и ведомое устройство выполняют различные версии MySQL, и код оптимизатора отличается между этими версиями.
Эта проблема может также влиять на восстановление базы данных, используя mysqlbinlog|mysql.

Самый легкий способ избежать этой проблемы состоит в том, чтобы добавить ORDER BY пункт к вышеупомянутым недетерминированным запросам, чтобы гарантировать, что строки всегда сохранены или изменяются в том же самом порядке. Используя основанный на строке или смешанный формат журналирования также избегает проблемы.
Имена файла журнала основаны на имени хоста сервера, если Вы не определяете имя файла с опцией запуска. Чтобы сохранить те же самые имена файла журнала, если Вы изменяете свое имя хоста на что-то еще, следует явно использовать опции такой как --log-bin=old_host_name-bin. См. Раздел 5.1.3, "Опции Команды Сервера". Альтернативно, переименуйте старые файлы, чтобы отразить Ваше изменение имени хоста. Если они - двоичные журналы, следует отредактировать двоичный индексный файл журнала и фиксировать двоичные имена файла журнала там также. (То же самое является истиной для реле, входит в систему ведомый сервер.)
mysqlbinlog не удаляет временные файлы, оставленные после a LOAD DATA INFILE оператор. См. Раздел 4.6.8, "mysqlbinlog — Утилита для Обработки Двоичных Файлов журнала".
RENAME не работает с TEMPORARY таблицы или таблицы используются в a MERGE таблица.
При использовании SET CHARACTER SET, невозможно использовать преобразованные символы в базе данных, таблице, и именах столбцов.
Невозможно использовать"_"или"%"с ESCAPE в LIKE ... ESCAPE.
Только первое max_sort_length байты используются, сравнивая значения данных. Это означает, что значения не могут достоверно использоваться в GROUP BY, ORDER BY или DISTINCT если они не отличны в первом max_sort_length байты. Чтобы работать вокруг этого, увеличьте значение переменной. Значение по умолчанию max_sort_length 1024 и может быть изменен во время запуска сервера или во времени выполнения.
Числовые вычисления делаются с BIGINT или DOUBLE (оба обычно 64 бита длиной). Какая точность, которую Вы получаете, зависит от функции. Общее правило состоит в том, что разрядные функции выполняются с BIGINT точность, IF() и ELT() с BIGINT или DOUBLE точность, и остальные с DOUBLE точность. Следует попытаться избегать использования длинных длинных значений без знака, если они разрешают быть больше чем 63 бита (9223372036854775807) для чего-нибудь кроме битовых полей.
У Вас могут быть 255 ENUM и SET столбцы в одной таблице.
В MIN(), MAX(), и другие агрегатные функции, MySQL в настоящий момент сравнивается ENUM и SET столбцы их строковым значением, а не относительной позицией строки в наборе.
В UPDATE оператор, столбцы обновляются слева направо. Если Вы обращаетесь к обновленному столбцу, Вы получаете обновленное значение вместо исходного значения. Например, следующие инкременты оператора KEY 2, нет 1:
```
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
```
Можно сослаться на многократные временные таблицы в том же самом запросе, но невозможно сослаться ни на какую данную временную таблицу не раз. Например, следующее не работает:
```
mysql> SELECT * FROM temp_table,
                    temp_table AS t2;ERROR 1137: Can't reopen table: 'temp_table'
```
Оптимизатор может обработать 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 Server 3.23.x, можно получить две идентичных строки в наборе результатов (потому что значения в скрытом id столбец может отличаться).

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