Изменения в аутентификации паролей MySQL. Начиная с MySQL 8.4.0, устаревший mysql_native_password плагин аутентификации больше не включен по умолчанию. Для его включения запустите сервер с параметром --mysql-native-password=ON (добавлено в MySQL 8.4.0), или включите mysql_native_password=ON в разделе [mysqld] вашего файла конфигурации MySQL (добавлено в MySQL 8.4.0).

Для получения дополнительной информации об включении, использовании и отключении mysql_native_password см. Раздел 8.4.1.1, «Native Pluggable Authentication».

Изменения значений по умолчанию переменных системы InnoDB. Значения по умолчанию для ряда системных переменных сервера, относящихся к хранилищу InnoDB, были изменены в MySQL 8.4.0, как показано в следующей таблице:

Плагин Clone. Требование к версии плагина clone было смягчено, чтобы разрешить клонирование между разными выпусками в одной серии. Другими словами, должны совпадать только основные и второстепенные номера версии, в то время как раньше должен был совпадать и номер точки выпуска.

Например, теперь функциональность клонирования позволяет клонировать 8.4.0 в 8.4.14 и наоборот.

Аутентификация LDAP на основе SASL в Windows. В Microsoft Windows теперь поддерживается серверный плагин для аутентификации LDAP на основе SASL. Это означает, что клиенты Windows теперь могут использовать GSSAPI/Kerberos для аутентификации с помощью плагина authentication_ldap_sasl_client.

Для получения дополнительной информации см. Аутентификацию LDAP на основе SASL (без проксирования).

Репликация MySQL: изменение SOURCE_RETRY_COUNT. Значение по умолчанию для параметра SOURCE_RETRY_COUNT оператора CHANGE REPLICATION SOURCE TO было изменено на 10. Это означает, что, используя значения по умолчанию для этого параметра и для параметра SOURCE_CONNECT_RETRY (60), реплика ждет 60 секунд между попытками подключения и продолжает попытки подключения с такой скоростью в течение 10 минут, прежде чем отменить и переключиться на резервный сервер.

Это изменение также относится к значению по умолчанию устаревшего серверного параметра --master-retry-count. (Вместо этого следует использовать SOURCE_RETRY_COUNT.)

Для получения дополнительной информации см. Раздел 19.4.9.1, «Асинхронный переход на резервный источник подключения».

Репликация MySQL: метки GTID. Формат глобальных идентификаторов транзакций (GIDs), используемых в MySQL Репликации и Групповой репликации, был расширен для возможности идентификации групп транзакций, позволяя присваивать уникальное имя GTID, относящимся к определённой группе транзакций. Например, транзакции, содержащие операции с данными, можно легко отличить от тех, которые возникают из административных операций, просто сравнив их GTID.

Новый формат GTID — UUID:TAG:NUMBER, где TAG — строка длиной до 8 символов, что активируется установкой значения системной переменной gtid_next на AUTOMATIC:TAG, добавленной в этом релизе (см. описание переменной для формата тега и другой информации). Эта метка сохраняется для всех транзакций, исходящих из текущей сессии (если не изменена с помощью SET gtid_next), и применяется во время фиксации для таких транзакций или, при использовании Групповой репликации, во время сертификации. Также можно установить gtid_next на UUID:TAG:NUMBER, чтобы установить UUID отдельной транзакции в произвольное значение и присвоить ей пользовательскую метку. Присвоение UUID и NUMBER остаётся без изменений по сравнению с предыдущими релизами MySQL. В любом случае, пользователь несёт ответственность за обеспечение уникальности метки для данной топологии репликации.

Исходный формат UUID:NUMBER для GTID по-прежнему поддерживается без изменений, как реализовано в предыдущих версиях MySQL; изменения существующих настроек репликации, использующих GTID, не требуются.

Установка gtid_next на AUTOMATIC:TAG или UUID:TAG:NUMBER требует нового привилегия TRANSACTION_GTID_TAG, добавленного в этом релизе; это справедливо как для сервера происхождения, так и для PRIVILEGE_CHECKS_APPLIER для потока прикладного модуля репликации. Это также означает, что администратор теперь может ограничить использование SET @gtid_next=AUTOMATIC:TAG или UUID:TAG:NUMBER желаемым набором MySQL пользователей или ролей, так что только те пользователи, относящиеся к заданной области данных или операций, могут фиксировать новые транзакции с назначенными метками.

Встроенные функции GTID_SUBSET(), GTID_SUBTRACT() и WAIT_FOR_EXECUTED_GTID_SET() совместимы с помеченными GTID.

Дополнительную информацию см. в описаниях системной переменной gtid_next и привилегии TRANSACTION_GTID_TAG, а также в Разделе 19.1.4, «Изменение режима GTID на онлайн-серверах».

Репликация: SQL_AFTER_GTIDS и MTA. Опция оператора START REPLICA SQL_AFTER_GTIDS теперь совместима с многопоточным прикладным модулем. (Ранее, при включенном MTA и попытке использования этой опции, оператор выдавал предупреждение, и реплика переключалась на однопоточный режим.) Это означает, что реплика, которой нужно наверстать пропущенные транзакции, теперь может сделать это, не теряя преимущества производительности от многопоточности.

Дополнительную информацию см. в Разделе 15.4.2.4, «Оператор START REPLICA», а также в документации для системной переменной replica_parallel_workers. См. также Раздел 19.2.3.2, «Мониторинг потоков обработки репликации» и Раздел 25.7.11, «Репликация NDB кластера с использованием многопоточного прикладного модуля».

Обратная совместимость терминологии репликации. В этом релизе добавлена опция --output-as-version для mysqldump. Эта опция позволяет создать дамп с сервера MySQL 8.2 или более поздней версии, совместимый со старыми версиями MySQL; её значение, выбранное из перечисленных, определяет совместимость терминологии репликации в дампе:

Подробную информацию см. в описании этой опции.

Кроме того, добавлено новое значение к уже разрешённым для системной переменной terminology_use_previous. BEFORE_8_2_0 заставляет сервер выводить DISABLE ON SLAVE (теперь устаревшее) вместо DISABLE ON REPLICA в выводе оператора SHOW CREATE EVENT. Существующее значение BEFORE_8_0_26 теперь также имеет этот эффект помимо уже имеющихся.

Номер версии MySQL, используемый в комментариях, специфичных для версии, поддерживает главную версию, состоящую из одной или двух цифр; это означает, что вся версия может иметь длину пять или шесть цифр. Дополнительную информацию о том, как это изменение влияет на обработку комментариев, специфичных для версии в MySQL, см. в Разделе 11.7, «Комментарии».

group_replication_set_as_primary() и операторы DDL. Функция group_replication_set_as_primary() ожидает завершения текущих операторов DDL, таких как ALTER TABLE, при ожидании завершения всех транзакций перед выбором нового первичного сервера.

Дополнительную информацию см. в описании этой функции.

Отслеживание заявок DDL и DCL для group_replication_set_as_primary(). group_replication_set_as_primary() теперь ожидает завершения следующих заявок перед выбором нового первичного сервера:

Эти запросы дополняют запросы, добавленные в MySQL 8.1 или уже поддерживаемые в этом отношении. Для получения дополнительной информации, включая список всех таких запросов, поддерживаемых в MySQL 8.3, см. описание функции group_replication_set_as_primary().

Совместимость версий группы репликации. Совместимость версий серверов в группах расширена следующим образом:

Пошаговые понижения версий серверов в группах поддерживаются в серии MySQL 8.4 LTS. Например, член группы, работающий на MySQL 8.4.2, может быть понижен до MySQL 8.4.0.

Аналогично, межверсионное членство в группе также поддерживается в серии релизов 8.4. Например, сервер, работающий на MySQL 8.4.0, может присоединиться к группе, все члены которой в настоящее время работают на MySQL 8.4.2, как и сервер, работающий на MySQL 8.4.3.

Значения по умолчанию переменных группы репликации. Значения по умолчанию двух системных переменных сервера, относящихся к группе репликации, были изменены в MySQL 8.4:

Дополнительная информация представлена в Разделе 20.5.3.2, «Настройка гарантий согласованности транзакций», и Разделе 20.7.7, «Ответы на обнаружение сбоев и сетевые разделения», а также в описаниях перечисленных переменных.

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

Дополнительную информацию см. в Разделе 20.9.2, «Переменные состояния группы репликации».

В рамках этой работы в таблицу Performance Schema replication_group_communication_information был добавлен новый столбец MEMBER_FAILURE_SUSPICIONS_COUNT. Содержимое этого столбца отформатировано как массив JSON, ключами которого являются идентификаторы членов группы, а значениями — количество раз, когда член группы считался подозрительным. Дополнительную информацию см. в описании этой таблицы.

Привилегия FLUSH_PRIVILEGES. В MySQL 8.4.0 добавлена новая привилегия, специально для разрешения использования запросов FLUSH PRIVILEGES. В отличие от привилегии RELOAD, привилегия FLUSH_PRIVILEGES применяется только к запросам FLUSH PRIVILEGES.

В MySQL 8.4 привилегия RELOAD по-прежнему поддерживается в этом качестве для обеспечения обратной совместимости.

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

Если вы понижаете версию с MySQL 8.4 (или более поздней) до версии MySQL, которая не поддерживает привилегию FLUSH_PRIVILEGES, пользователь, которому ранее была предоставлена эта привилегия, не может выполнять запросы FLUSH PRIVILEGES, если у него нет привилегии RELOAD.

Привилегия OPTIMIZE_LOCAL_TABLE. MySQL 8.4.0 добавляет новую привилегию OPTIMIZE_LOCAL_TABLE. Пользователи должны иметь эту привилегию для выполнения запросов OPTIMIZE LOCAL TABLE и OPTIMIZE NO_WRITE_TO_BINLOG TABLE.

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

Система маскирования и деидентификации данных MySQL Enterprise. Компоненты маскирования данных получили возможность указывать отдельную схему для хранения связанной внутренней таблицы и функций маскирования. Ранее единственным вариантом хранения была схема mysql. Новая переменная только для чтения component_masking.masking_database позволяет задавать и сохранять имя альтернативной схемы при запуске сервера.

Сброс словарей маскирования данных. Компонент MySQL Enterprise Data Masking and De-Identification теперь включает возможность сброса данных на вторичном сервере или реплике в оперативную память. Это можно сделать двумя способами:

Дополнительную информацию см. в разделе 8.5, «MySQL Enterprise Data Masking and De-Identification», и описаниях этих элементов.

Автоматическое обновление гистограмм. MySQL 8.4.0 добавляет поддержку автоматического обновления гистограмм. Когда эта функция включена для данной гистограммы, она обновляется при каждом выполнении ANALYZE TABLE для таблицы, к которой она относится. Кроме того, автоматическое перерасчёт постоянных статистических данных компонентом InnoDB (см. раздел 17.8.10.1, «Настройка параметров постоянной статистики оптимизатора») также обновляет гистограмму. Обновление гистограмм продолжает использовать то же количество ячеек, что и первоначально было указано, если таковые имеются.

Вы можете включить эту функцию при указании гистограммы, включив опцию AUTO UPDATE для команды ANALYZE TABLE. Чтобы отключить её, используйте MANUAL UPDATE вместо этого. MANUAL UPDATE (без автоматических обновлений) — значение по умолчанию, если ни одна из опций не указана.

Дополнительную информацию см. в разделе «Анализ статистики гистограмм».

Добавленная системная переменная сервера tls-certificates-enforced-validation, которая позволяет DBA принудительно проверять сертификаты при запуске сервера или при использовании команды ALTER INSTANCE RELOAD TLS для перезагрузки сертификатов во время работы. При включённой проверке обнаружение недействительного сертификата останавливает запуск сервера при запуске, предотвращает загрузку недействительных сертификатов во время работы и выводит предупреждения. Дополнительную информацию см. в разделе «Настройка принудительной проверки сертификатов».

Добавлены переменные состояния сервера для управления временем ожидания учётных записей MySQL, которые подключаются к серверу MySQL с помощью подключаемого модуля аутентификации LDAP, когда сервер LDAP недоступен или не отвечает. Значение тайм-аута по умолчанию стало 30 секунд для следующих переменных аутентификации LDAP на основе простого и SASL-аутентификации:

Тайм-ауты подключения и ответа можно настроить через системные переменные только на платформах Linux. Дополнительную информацию см. в разделе «Установка тайм-аутов для подключаемого модуля аутентификации LDAP».

Улучшена регистрация процесса завершения, добавлено сообщения о запуске и завершении работы сервера MySQL, плагинов и компонентов. Такие сообщения теперь также регистрируются при закрытии подключений. Эти дополнения должны облегчить отладку и устранение неполадок, особенно в случае, если сервер тратит слишком много времени на завершение работы.

Дополнительную информацию см. в разделе 7.4.2, «Журнал ошибок».

Добавления в сообщения о запуске и завершении работы сервера. В процессы запуска и завершения работы сервера добавлены следующие типы сообщений, как указано в этом списке:

Кроме того, если сервер был собран с использованием WITH_SYSTEMD, теперь сервер включает каждое сообщение systemd в журнале ошибок.

Добавлена команда SHOW PARSE_TREE, которая отображает JSON-форматированное дерево разбора для команды SELECT. Эта команда предназначена только для использования в целях тестирования и разработки, а не в производственной среде. Она доступна только в отладочных сборках, или если MySQL был собран из исходного кода с помощью опции CMake -DWITH_SHOW_PARSE_TREE, и не включена или не поддерживается в релизных сборках.

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

Дополнительную информацию см. в разделе 7.6.3, «MySQL Enterprise Thread Pool» и разделе 29.12.16, «Таблицы схемы производительности Thread Pool».

Использование таблицы Information Schema PROCESSLIST. Хотя таблица INFORMATION_SCHEMA.PROCESSLIST устарела в MySQL 8.0.35 и 8.2.0, интерес к отслеживанию её использования сохраняется. В этом релизе добавлены две системные переменные состояния, предоставляющие информацию об обращениях к таблице PROCESSLIST:

Оптимизация хеш-таблицы для операций с множествами. MySQL 8.2 улучшает производительность операторов, использующих операции с множествами EXCEPT и INTERSECT, при помощи новой оптимизации хеш-таблицы, которая автоматически включается для таких операторов и управляется переключателем оптимизатора hash_set_operations; для отключения этой оптимизации и использования старой оптимизации временных таблиц, используемой в предыдущих версиях MySQL, установите этот флаг в значение off.

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

Дополнительную информацию см. в разделе 10.9.2 «Переключаемые оптимизации».

Опция CMake WITH_LD. WITH_LD: Определяет, использовать ли компоновщик llvm lld или mold, в противном случае используется стандартный компоновщик. WITH_LD также заменяет опцию CMake, удаленную в MySQL 8.3.0.

Улучшения брандмауэра MySQL Enterprise. С момента выпуска MySQL 8.0 в брандмауэр MySQL Enterprise было внесено несколько улучшений. Они перечислены ниже:

Дополнительную информацию о хранимых процедурах брандмауэра см. в Хранимых процедурах брандмауэра MySQL Enterprise.

Подключаемая аутентификация. Добавлена поддержка аутентификации на сервере MySQL с помощью таких устройств, как смарт-карты, ключи безопасности и биометрические считыватели в контексте WebAuthn. Новый метод аутентификации WebAuthn основан на стандартах FIDO и FIDO2. Он использует пару плагинов, authentication_webauthn на стороне сервера и authentication_webauthn_client на стороне клиента. Плагин аутентификации WebAuthn на стороне сервера включен только в дистрибутивах MySQL Enterprise Edition.

Миграция хранилища ключей. Поддерживается миграция от компонента хранилища ключей к плагину хранилища ключей. Для выполнения такой миграции используйте серверный параметр --keyring-migration-from-component, введенный в MySQL 8.4.0, установив --keyring-migration-source в имя исходного компонента и --keyring-migration-destination - имя целевого плагина.

Дополнительную информацию см. в Миграции ключей с использованием сервера миграции.

MySQL Enterprise Audit. Добавлен скрипт audit_log_filter_uninstall.sql для упрощения удаления MySQL Enterprise Audit.

Новые ключевые слова. Ключевые слова, добавленные в MySQL 8.4 с момента выпуска MySQL 8.0. Зарезервированные ключевые слова помечены (R).

AUTO, BERNOULLI, GTIDS, LOG, MANUAL (R), PARALLEL (R), PARSE_TREE, QUALIFY (R), S3 и TABLESAMPLE (R).

Превентивная уборка мусора для группы репликации с приоритетом. Системная переменная, добавленная в MySQL 8.4.0 group_replication_preemptive_garbage_collection, позволяет выполнять превентивную очистку мусора для группы репликации, работающей в режиме одного первичного сервера, сохраняя только наборы записи для тех транзакций, которые еще не подтверждены. Это может сэкономить время и потребление памяти. Дополнительная системная переменная group_replication_preemptive_garbage_collection_rows_threshold (также представлена в MySQL 8.4.0) устанавливает нижний предел для количества строк сертификации, необходимого для запуска превентивной очистки мусора, если она включена; значение по умолчанию составляет 100000.

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

Изменить режим репликации группы между однопервичным и многопервичным режимами невозможно, когда group_replication_preemptive_garbage_collection включен.

См. раздел 20.7.9 «Мониторинг использования памяти репликации группы с помощью инструментария памяти Performance Schema» для получения информации об использовании памяти данным процессом.

Очищенное восстановление журнала репликации. В MySQL 8.4.0 и более поздних версиях можно восстановить журнал репликации, удалив все неполные транзакции. Журнал репликации теперь очищается при запуске сервера с параметром --relay-log-recovery=OFF (по умолчанию), что означает, что удаляются следующие элементы:

Дополнительную информацию см. в описании системной переменной сервера relay_log_recovery.

Файл истории обновления MySQL. В процессе установки в MySQL 8.4.0 и более поздних версиях в каталоге данных сервера создается или обновляется файл в формате JSON с именем mysql_upgrade_history. Этот файл содержит информацию о версии установленного сервера MySQL, времени его установки и о том, относится ли выпуск к серии LTS или Innovation.

Типичный файл mysql_upgrade_history может выглядеть так (форматирование скорректировано для лучшей читаемости):

{
  "file_format":"1",

  "upgrade_history":
  [
    {
      "date":"2024-03-15 22:02:35",
      "version":"8.4.0",
      "maturity":"LTS",
      "initialize":true
    },

    {
      "date":"2024-05-17 17:46:12",
      "version":"8.4.1",
      "maturity":"LTS",
      "initialize":false
    }
  ]

}

Кроме того, процесс установки теперь проверяет наличие файла mysql_upgrade_info (устаревший в MySQL 8.0 и больше не используется). Если он найден, файл удаляется.

Опция mysql client --system-command. Опция --system-command для клиента mysql, доступная в MySQL 8.4.3 и более поздних версиях, включает или отключает команду system.

Эта опция включена по умолчанию. Для отключения ее используйте --system-command=OFF или --skip-system-command, что приводит к отклонению команды system с ошибкой.

Удаленные параметры и переменные сервера. Ряд параметров и переменных сервера, поддерживаемых в предыдущих версиях MySQL, был удалён в MySQL 8.4. Попытка установить любой из них в MySQL 8.4 вызывает ошибку. Эти параметры и переменные перечислены здесь:

Устаревшие параметры и переменные репликации. Ряд параметров и переменных, относящихся к репликации MySQL, были устаревшими в предыдущих версиях MySQL и были удалены в MySQL 8.4. Попытка использовать любой из них теперь приводит к синтаксической ошибке на сервере. Эти параметры и переменные перечислены здесь:

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

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

Это имеет последствия для установки следующих системных переменных:

См. описания этих переменных для разрешённых значений в MySQL 8.4 и дополнительную информацию.

INFORMATION_SCHEMA.TABLESPACES. Таблица INFORMATION_SCHEMA.TABLESPACES, которая фактически не использовалась, была устаревшей в MySQL 8.0.22 и теперь удалена.

DROP TABLESPACE и ALTER TABLESPACE: Клауза ENGINE. Клауза ENGINE для операторов DROP TABLESPACE и ALTER TABLESPACE была устаревшей в MySQL 8.0. В MySQL 8.4 она больше не поддерживается и вызывает ошибку, если вы попытаетесь использовать её с DROP TABLESPACE или ALTER TABLESPACE ... DROP DATAFILE. ENGINE также больше не поддерживается для всех других вариантов ALTER TABLESPACE, за исключением двух перечисленных здесь случаев:

Для получения дополнительной информации см. документацию по этим операторам.

LOW_PRIORITY с LOCK TABLES ... WRITE. Клауза LOW_PRIORITY оператора LOCK TABLES ... WRITE не имела эффекта с MySQL 5.5 и была устаревшей в MySQL 5.6. Она больше не поддерживается в MySQL 8.4; включение её в LOCK TABLES теперь вызывает синтаксическую ошибку.

Форматирование EXPLAIN FORMAT=JSON версиями. Теперь можно выбирать между 2 версиями формата JSON вывода, используемого операторами EXPLAIN FORMAT=JSON, используя системную переменную сервера explain_json_format_version, введённую в этом выпуске. Установка этой переменной в 1 заставляет сервер использовать версию 1, которая является линейным форматом, который всегда использовался для вывода от таких операторов в MySQL 8.2 и ранее. Это значение и формат по умолчанию в MySQL 8.4. Установка explain_json_format_version в 2 заставляет использовать формат версии 2; этот формат JSON вывода основан на путях доступа и предназначен для лучшей совместимости с будущими версиями оптимизатора MySQL.

См. Получение информации о плане выполнения, для получения дополнительной информации и примеров.

Захват вывода EXPLAIN FORMAT=JSON. EXPLAIN FORMAT=JSON был расширен опцией INTO, которая предоставляет возможность сохранить вывод EXPLAIN в формате JSON в переменной пользователя, где с ним можно работать с помощью функций MySQL JSON, например, так:

mysql> EXPLAIN FORMAT=JSON INTO @myex SELECT name FROM a WHERE id = 2;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT JSON_EXTRACT(@myex, "$.query_block.table.key");
+------------------------------------------------+
| JSON_EXTRACT(@myex, "$.query_block.table.key") |
+------------------------------------------------+
| "PRIMARY"                                      |
+------------------------------------------------+
1 row in set (0.01 sec)

Эта опция может использоваться только в том случае, если оператор EXPLAIN также содержит FORMAT=JSON; в противном случае возникает синтаксическая ошибка. Это требование не зависит от значения explain_format.

INTO может быть использован со всеми объяснимыми операторами, за исключением EXPLAIN FOR CONNECTION. Он не может быть использован с EXPLAIN ANALYZE.

Для получения дополнительной информации и примеров см. Получение информации о плане выполнения.

EXPLAIN для схемы. Добавлен параметр FOR SCHEMA к оператору EXPLAIN. Синтаксис показан здесь, где stmt – это оператор, для которого требуется объяснение:

EXPLAIN [options] FOR SCHEMA schema_name stmt

Это приводит к тому, что stmt выполняется как будто в указанной схеме.

FOR DATABASE также поддерживается как синоним.

Эта опция несовместима с FOR CONNECTION.

См. Получение информации о плане выполнения для получения дополнительной информации.

Комментарии клиентов сохранены. В MySQL 8.0, удаление комментариев из клиента mysql было по умолчанию; по умолчанию было изменено на сохранение таких комментариев.

Чтобы включить удаление комментариев, как это выполнялось в MySQL 8.0 и ранее, запустите клиент mysql с --skip-comments.

AUTO_INCREMENT и столбцы с плавающей точкой. Использование модификатора AUTO_INCREMENT со столбцами FLOAT и DOUBLE в операциях CREATE TABLE и ALTER TABLE было устаревшим в MySQL 8.0; поддержка полностью удалена в MySQL 8.4, где возникает (Неверный спецификатор столбца для столбца).

Перед обновлением до MySQL 8.4 из предыдущих версий, вы обязаны исправить любые таблицы, содержащие столбец FLOAT или DOUBLE со AUTO_INCREMENT, чтобы таблица больше не использовала ни один из них. В противном случае обновление не удастся.

Утилита mysql_ssl_rsa_setup. Утилита mysql_ssl_rsa_setup, устаревшая в MySQL 8.0.34, удалена. Для дистрибутивов MySQL, скомпилированных с использованием OpenSSL, сервер MySQL может автоматически генерировать отсутствующие SSL и RSA файлы при запуске. См. Раздел 8.3.3.1, «Создание сертификатов SSL и ключей RSA с помощью MySQL» для получения дополнительной информации.

Права MySQL. Добавлены права SET_ANY_DEFINER для создания объектов definer и ALLOW_NONEXISTENT_DEFINER для защиты от «одиноких» объектов. Вместе эти права сосуществуют с устаревшими правами.

Права SET_USER_ID. Права SET_USER_ID, устаревшие в MySQL 8.2.0, удалены. Использование в операциях GRANT теперь вызывает синтаксическую ошибку.

Вместо SET_USER_ID, вы можете использовать права SET_ANY_DEFINER для создания объектов definer и ALLOW_NONEXISTENT_DEFINER для защиты от «одиноких» объектов.

Оба права необходимы для создания «одиноких» SQL-объектов с помощью CREATE PROCEDURE, CREATE FUNCTION, CREATE TRIGGER, CREATE EVENT или CREATE VIEW.

Параметры сервера --abort-slave-event-count и --disconnect-slave-event-count. Параметры запуска сервера MySQL --abort-slave-event-count и --disconnect-slave-event-count, ранее используемые в тестировании, устарели в MySQL 8.0 и удалены в этом выпуске. Попытка запуска mysqld с любым из этих параметров теперь приводит к ошибке.

Утилита mysql_upgrade. Утилита mysql_upgrade, устаревшая в MySQL 8.0.16, удалена.

Утилита mysqlpump. Утилита mysqlpump вместе с её вспомогательными утилитами lz4_decompress и zlib_decompress, устаревшая в MySQL 8.0.34, была удалена. Вместо этого используйте mysqldump или ...

Устаревшие опции CMake. Следующие опции для компиляции сервера с помощью CMake были устаревшими и удалены:

Удаленные ключевые слова. Ключевые слова, удаленные в MySQL 8.4 начиная с MySQL 8.0. Зарезервированные ключевые слова помечены (R).

GET_MASTER_PUBLIC_KEY, MASTER_AUTO_POSITION, MASTER_BIND (R), MASTER_COMPRESSION_ALGORITHMS, MASTER_CONNECT_RETRY, MASTER_DELAY, MASTER_HEARTBEAT_PERIOD, MASTER_HOST, MASTER_LOG_FILE, MASTER_LOG_POS, MASTER_PASSWORD, MASTER_PORT, MASTER_PUBLIC_KEY_PATH, MASTER_RETRY_COUNT, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL, MASTER_SSL_CRLPATH, MASTER_SSL_KEY, MASTER_SSL_VERIFY_SERVER_CERT (R), MASTER_TLS_CIPHERSUITES, MASTER_TLS_VERSION, MASTER_USER и MASTER_ZSTD_COMPRESSION_LEVEL.

Префиксы индексов в ключе разбиения. Столбцы с префиксами индексов допускались в ключе разбиения для разбиеной таблицы в MySQL 8.0, и выводили предупреждение без каких-либо других эффектов при создании, изменении или обновлении разбиеной таблицы. Такие столбцы больше не разрешаются в разбиеномых таблицах, и использование таких столбцов в ключе разбиения приводит к отклонению операторов CREATE TABLE или ALTER TABLE в случае их появления с ошибкой.

Для получения дополнительной информации см. Префиксы индексов столбцов не поддерживаются для разбиения по ключу.