Несовместимое изменение: В MySQL 5.7.11 значение по умолчанию для --early-plugin-load является именем файла библиотеки плагина keyring_file, что приводит к его автоматической загрузке по умолчанию. В MySQL 5.7.12 и более поздних версиях значение по умолчанию для --early-plugin-load пустое; для загрузки плагина keyring_file необходимо явно указать опцию со значением, содержащим имя файла библиотеки плагина keyring_file.

Шифрование табличного пространства InnoDB требует, чтобы плагин keyring загружался до инициализации InnoDB, поэтому это изменение значения по умолчанию для --early-plugin-load вводит несовместимость для обновлений с 5.7.11 до 5.7.12 или выше. Администраторы, которые зашифровали InnoDB табличные пространства, должны предпринять явные действия для обеспечения дальнейшей загрузки плагина keyring: Запустите сервер с опцией --early-plugin-load, указывающей имя файла библиотеки плагина. Для дополнительной информации см. Раздел 6.4.4.1, «Установка плагина keyring».

Несовместимое изменение: В INFORMATION_SCHEMA есть таблицы, содержащие информацию о системных и статусных переменных (см. Раздел 24.3.11, «Таблицы INFORMATION_SCHEMA GLOBAL_VARIABLES и SESSION_VARIABLES» и Раздел 24.3.10, «Таблицы INFORMATION_SCHEMA GLOBAL_STATUS и SESSION_STATUS»). Начиная с MySQL 5.7.6, Performance Schema также содержит таблицы системных и статусных переменных (см. Раздел 25.12.13, «Таблицы переменных системы Performance Schema» и Раздел 25.12.14, «Таблицы статусных переменных Performance Schema»). Таблицы Performance Schema предназначены для замены таблиц INFORMATION_SCHEMA, которые устарели начиная с MySQL 5.7.6 и удалены в MySQL 8.0.

Советы по миграции от таблиц INFORMATION_SCHEMA к таблицам Performance Schema см. в Разделе 25.20, «Миграция к таблицам системных и статусных переменных Performance Schema». Для облегчения миграции можно использовать системную переменную show_compatibility_56, которая влияет на то, как информация о системных и статусных переменных предоставляется таблицами INFORMATION_SCHEMA и Performance Schema, а также операторами SHOW VARIABLES и SHOW STATUS. show_compatibility_56 включена по умолчанию в 5.7.6 и 5.7.7 и выключена по умолчанию в MySQL 5.7.8.

Подробности о влиянии show_compatibility_56 см. в Разделе 5.1.7, «Системные переменные сервера». Для лучшего понимания настоятельно рекомендуется ознакомиться также с этими разделами:

Несовместимое изменение: Начиная с MySQL 5.7.6, инициализация каталога данных создает только один учётную запись, 'root'@'localhost'. (См. Раздел 2.9.1, «Инициализация каталога данных».) Попытка подключения к хосту 127.0.0.1 обычно приводит к учётной записи localhost. Однако это не удаётся, если сервер запускается с включённой опцией skip_name_resolve. Если вы планируете это сделать, убедитесь, что существует учётная запись, которая может принять подключение. Например, чтобы подключиться как root используя --host=127.0.0.1 или --host=::1, создайте эти учётные записи:

CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY 'root-password';
CREATE USER 'root'@'::1' IDENTIFIED BY 'root-password';

Несовместимое изменение: Начиная с MySQL 5.7.6, для некоторых платформ Linux, при установке MySQL с помощью пакетов RPM и Debian, запуск и остановка сервера теперь управляются с помощью systemd, а не mysqld_safe, и mysqld_safe не установлен. Это может потребовать некоторой корректировки способа указания опций сервера. Подробности см. в Разделе 2.5.10, «Управление сервером MySQL с помощью systemd».

Несовместимое изменение: В MySQL 5.7.5 исполняемый бинарный файл mysql_install_db находится в каталоге установки bin, в то время как версия Perl находилась в каталоге установки scripts. При обновлении с более старой версии MySQL вы можете найти версию в обоих каталогах. Чтобы избежать путаницы, удалите версию в каталоге scripts. При свежих установках MySQL 5.7.5 или более поздних версий mysql_install_db находится только в каталоге bin, а каталог scripts больше не существует. Приложения, ожидающие найти mysql_install_db в каталоге scripts, должны быть обновлены для поиска по каталогу bin вместо этого.

Расположение mysql_install_db становится менее существенным начиная с MySQL 5.7.6, так как с этой версии оно устарело в пользу mysqld --initialize (или mysqld --initialize-insecure). См. Раздел 2.9.1, «Инициализация каталога данных».

Несовместимое изменение: Столбец Password системной таблицы mysql.user был удален в MySQL 5.7.6. Все учетные данные хранятся в столбце authentication_string, включая те, которые ранее хранились в столбце Password. Если вы выполняете обновление MySQL 5.7.6 или более поздней версии на месте, запустите mysql_upgrade, как указано в процедуре обновления на месте, чтобы перенести содержимое столбца Password в столбец authentication_string.

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

Как указано в процедуре логического обновления, загрузите файл дампа версии до 5.7.6 в сервер версии 5.7.6 (или более поздней) перед запуском mysql_upgrade.

Начиная с MySQL 5.7.24, версия библиотеки zlib, входящей в состав MySQL, была повышена с версии 1.2.3 до версии 1.2.11.

Функция zlib compressBound() в zlib 1.2.11 возвращает несколько более высокую оценку размера буфера, необходимого для сжатия заданной длины байтов, чем в zlib версии 1.2.3. Функция compressBound() вызывается функциями InnoDB, которые определяют максимальный размер строки, разрешённый при создании сжатых InnoDB таблиц или вставки строк в сжатые InnoDB таблицы. В результате операции CREATE TABLE ... ROW_FORMAT=COMPRESSED или INSERT со строками, размеры которых очень близки к максимальному размеру строки, которые были успешны в предыдущих выпусках, теперь могут завершиться неудачей.

Если у вас есть сжатые InnoDB таблицы с большими строками, рекомендуется протестировать операторы CREATE TABLE сжатых таблиц на тестовом экземпляре MySQL 5.7 перед обновлением.

Несовместимое изменение: Для упрощения обнаружения файловой системы InnoDB при восстановлении после сбоя в MySQL 5.7.5 были введены новые типы записей журнала редо. Это улучшение изменяет формат журнала редо. Перед выполнением обновления на месте выполните чистую остановку, используя значение innodb_fast_shutdown 0 или 1. Рекомендуется выполнить медленную остановку, используя innodb_fast_shutdown=0 при обновлении.

Несовместимое изменение: Журналы отката MySQL 5.7.8 и 5.7.9 могут содержать недостаточную информацию о пространственных столбцах, что может привести к сбою обновления (Ошибка #21508582). Перед выполнением обновления на месте с MySQL 5.7.8 или 5.7.9 на 5.7.10 или выше, выполните медленную остановку, используя innodb_fast_shutdown=0 для очистки журналов отката. Рекомендуется выполнить медленную остановку, используя innodb_fast_shutdown=0 при обновлении.

Несовместимое изменение: Журналы отката MySQL 5.7.8 могут содержать недостаточную информацию о виртуальных столбцах и индексах виртуальных столбцов, что может привести к сбою обновления (Ошибка #21869656). Перед выполнением обновления на месте с MySQL 5.7.8 на MySQL 5.7.9 или выше, выполните медленную остановку, используя innodb_fast_shutdown=0 для очистки журналов отката. Рекомендуется выполнить медленную остановку, используя innodb_fast_shutdown=0 при обновлении.

Несовместимое изменение: Начиная с MySQL 5.7.9, заголовок журнала редо первого файла журнала редо (ib_logfile0) включает идентификатор версии формата и текстовую строку, которая идентифицирует версию MySQL, которая создала файлы журнала редо. Это улучшение изменяет формат журнала редо, требуя, чтобы MySQL был остановлен в безопасном режиме, используя значение innodb_fast_shutdown 0 или 1 перед выполнением обновления на месте до MySQL 5.7.9 или более поздней версии. Рекомендуется выполнить медленную остановку, используя innodb_fast_shutdown=0 при обновлении.

В MySQL 5.7.9, DYNAMIC заменяет COMPACT в качестве неявного значения по умолчанию для формата строк для таблиц InnoDB. Новая конфигурационная опция innodb_default_row_format определяет формат строк по умолчанию. Разрешенные значения включают DYNAMIC (значение по умолчанию), COMPACT и REDUNDANT.

После обновления до 5.7.9 все новые таблицы, которые вы создаете, используют формат строки, определенный в innodb_default_row_format, если вы явно не определите формат строки (ROW_FORMAT).

Для существующих таблиц, которые не явно определяют параметр ROW_FORMAT или которые используют ROW_FORMAT=DEFAULT, любая операция, которая перестраивает таблицу, также безмолвно меняет формат строк таблицы на формат, определяемый innodb_default_row_format. В противном случае существующие таблицы сохраняют текущее значение формата строк. Более подробную информацию см. в разделе Определение формата строк таблицы.

Начиная с MySQL 5.7.6, хранилище InnoDB использует собственный встроенный ( «родной») обработчик разбиения для любых новых разнесенных таблиц, созданных с помощью InnoDB. Разнесенные таблицы InnoDB, созданные в предыдущих версиях MySQL, не обновляются автоматически. Вы можете легко обновить такие таблицы для использования родного разбиения InnoDB в MySQL 5.7.9 или более поздней версии, используя любой из следующих методов:

Несовместимое изменение: Функция GET_LOCK() была переимплементирована в MySQL 5.7.5 с использованием подсистемы блокировок метаданных (MDL) и её возможности были расширены:

Для получения дополнительной информации см. Раздел 12.14, «Функции блокировки».

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

Однако в MySQL 5.7 до MySQL 5.7.11, и для таких операторов, как DELETE или UPDATE, которые изменяют таблицы, использование стратегии слияния для производной таблицы, которая ранее материализовывалась, может привести к ошибке:

mysql> DELETE FROM t1
    -> WHERE id IN (SELECT id
    ->              FROM (SELECT t1.id
    ->                    FROM t1 INNER JOIN t2 USING (id)
    ->                    WHERE t2.status = 0) AS t);
ERROR 1093 (HY000): You can't specify target table 't1'
for update in FROM clause

Ошибка возникает, когда слияние производной таблицы в внешний блок запроса приводит к оператору, который как выбирает из, так и изменяет таблицу. (Материализация не вызывает проблемы, потому что, по сути, она преобразует производную таблицу в отдельную таблицу.) Решение для предотвращения этой ошибки заключалось в отключении флага derived_merge переменной системы optimizer_switch перед выполнением оператора:

SET optimizer_switch = 'derived_merge=off';

Флаг derived_merge контролирует, пытается ли оптимизатор слить подзапросы и представления в ключе FROM во внешний блок запроса, предполагая, что ни одна другая инструкция не препятствует слиянию. По умолчанию флаг on для включения слияния. Установка флага на значение off предотвращает слияние и избегает описанной выше ошибки. Для получения дополнительной информации, см. Раздел 8.2.2.4, «Оптимизация производных таблиц и ссылок на представления с помощью слияния или материализации».

Некоторые ключевые слова могут быть зарезервированы в MySQL 5.7, которые не были зарезервированы в MySQL 5.6. См. Раздел 9.3, «Ключевые слова и зарезервированные слова». Это может привести к тому, что слова, ранее использовавшиеся в качестве идентификаторов, станут незаконными. Для исправления затронутых операторов используйте цитирование идентификаторов. См. Раздел 9.2, «Имена объектов схемы».

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

В операторах UNION, чтобы применить ORDER BY или LIMIT к отдельному SELECT, поместите ключевую фразу внутри скобок, которые заключают SELECT:

(SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);

Предыдущие версии MySQL могут допускать такие операторы без скобок. В MySQL 5.7 требование скобок является обязательным.