Оптимизация подзапросов для IN не так эффективна, как для =.

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

Удаление ограничения FOREIGN KEY не работает в репликации, потому что ограничение может иметь другое имя на реплике.

REPLACE (и LOAD DATA с опцией REPLACE) не вызывает ON DELETE CASCADE.

DISTINCT с ORDER BY не работает внутри GROUP_CONCAT(), если вы не используете все и только те столбцы, которые находятся в списке DISTINCT.

При вставке большого целого значения (между 2⁶³ и 2⁶⁴−1) в столбец decimal или string, оно вставляется как отрицательное значение, так как число оценивается в контексте знакового целого числа.

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

Например:

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

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

Запрос оптимизируется по-разному на источнике и реплике только в том случае, если:

Эта проблема также может повлиять на восстановление базы данных с помощью mysqlbinlog|mysql.

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

Имена файлов журнала основаны на имени хоста сервера, если вы не укажете имя файла с опцией запуска. Чтобы сохранить те же имена файлов журнала, если вы измените имя своего хоста на другое, вы должны явно использовать такие опции, как --log-bin=old_host_name-bin. См. Раздел 7.1.7, «Опции команды сервера». В качестве альтернативы переименуйте старые файлы, чтобы отразить изменение имени вашего хоста. Если это двоичные журналы, вы должны отредактировать файл индекса двоичного журнала и исправить имена файлов двоичного журнала там тоже. (То же самое верно для релейных журналов на реплике.)

mysqlbinlog не удаляет временные файлы, оставшиеся после оператора LOAD DATA. См. Раздел 6.6.9, «mysqlbinlog — утилита для обработки двоичных журналов».

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

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

Сервер использует только первые max_sort_length байтов при сравнении значений данных. Это означает, что значения не могут надёжно использоваться в GROUP BY, ORDER BY или DISTINCT, если они отличаются только после первых max_sort_length байтов. Чтобы обойти это, увеличьте значение переменной. Значение по умолчанию для max_sort_length равно 1024 и может быть изменено во время запуска сервера или во время выполнения.

Численные вычисления выполняются с помощью BIGINT или DOUBLE (оба обычно имеют длину 64 бита). Какая точность получается, зависит от функции. Общее правило заключается в том, что битовые функции выполняются с точностью BIGINT, IF() и ELT() с точностью BIGINT или DOUBLE, а остальные — с точностью DOUBLE. Вы должны стараться избегать использования беззнаковых 64-битных значений, если они представляют собой значения, большие, чем 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;

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

Обратите внимание, что это происходит только для запросов, которые не имеют столбцов ORDER BY в результате.

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

Создание таблицы типа MERGE не проверяет, совместимы ли базовые таблицы с соответствующими типами.

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