Оптимизация подзапросов для 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. См. Раздел 5.1.6, «Параметры командной строки сервера». В качестве альтернативы переименуйте старые файлы, чтобы отразить изменение имени хоста. Если это двоичные журналы, вам также необходимо отредактировать файл индекса двоичного журнала и исправить там имена файлов двоичного журнала. (То же самое относится к релейным журналам на реплике.)

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

RENAME не работает с таблицами типа TEMPORARY или таблицами, используемыми в таблице 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. Следует избегать использования беззнаковых 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 индексы перед обычными индексами, чтобы как можно раньше обнаруживать дублирующие ключи.