Поделиться через

Параметры сервера в Базе данных Azure для MySQL (Гибкий сервер)

  • Статья

В этой статье приведены рекомендации и рекомендации по настройке параметров сервера в База данных Azure для MySQL — гибкий сервер.

Примечание.

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

Что такое параметры сервера?

Подсистема MySQL предоставляет множество параметров сервера (также называемых переменными), которые можно использовать для настройки и настройки поведения ядра. Некоторые параметры можно задать динамически во время выполнения. Другие являются статическими и требуют перезапуска сервера после их установки.

В База данных Azure для MySQL — гибкий сервер можно изменить значение различных параметров сервера MySQL с помощью параметров сервера Configure Server в База данных Azure для MySQL — гибкий сервер с помощью портал Azure и настройки параметров сервера в База данных Azure для MySQL — гибкий сервер с помощью Azure CLI для соответствия потребностям рабочей нагрузки.

Настраиваемые параметры сервера

Вы можете управлять конфигурацией гибкого сервера База данных Azure для MySQL с помощью параметров сервера. Параметры сервера настраиваются по умолчанию и рекомендуемыми значениями при создании сервера. В области параметров сервера в портал Azure отображаются изменяемые и неизменяемые параметры. Неизменяемые параметры сервера недоступны.

Список поддерживаемых параметров постоянно растет. Можно использовать портал Azure для периодического просмотра полного списка параметров сервера и настройки значений.

Если изменить параметр статического сервера с помощью портала, необходимо перезапустить сервер, чтобы изменения вступили в силу. Если вы используете сценарии автоматизации (с помощью таких средств, как шаблоны Azure Resource Manager, Terraform или Azure CLI), сценарий должен подготовиться для перезапуска службы, чтобы параметры вступили в силу, даже если вы изменяете конфигурацию в процессе создания.

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

В следующих разделах описываются ограничения часто обновляемых параметров сервера. Уровень вычислений и размер (виртуальные ядра) сервера определяют ограничения.

lower_case_table_names

Для MySQL версии 5.7 значение lower_case_table_names по умолчанию находится 1 в База данных Azure для MySQL — гибкий сервер. Несмотря на то что можно изменить поддерживаемое значение 2на , отмена обратно 2 на 1 не допускается. Чтобы помочь в изменении значения по умолчанию, создайте запрос в службу поддержки.

Для MySQL версии 8.0+ можно настроить lower_case_table_names только при инициализации сервера. Подробнее. lower_case_table_names Изменение параметра после инициализации сервера запрещено.

Поддерживаемые значения для MySQL версии 8.0 находятся 1 в 2 База данных Azure для MySQL — гибкий сервер. Значение по умолчанию — 1. Чтобы помочь в изменении значения по умолчанию во время создания сервера, создайте запрос в службу поддержки.

innodb_tmpdir

Параметр innodb_tmpdir в База данных Azure для MySQL — гибкий сервер используется для определения каталога для временных файлов сортировки, созданных во время перестроения в сетиALTER TABLE.

Значение innodb_tmpdir по умолчанию — /mnt/temp. Это расположение соответствует временному хранилищу (SSD) и доступно в гибибайтах (GiB) с каждым размером вычислительных ресурсов сервера. Это расположение идеально подходит для операций, для которых не требуется большое количество места.

Если требуется больше места, можно задать значение innodb_tmpdir /app/work/tmpdir. Этот параметр использует доступную емкость хранилища на База данных Azure для MySQL гибком сервере. Этот параметр может быть полезным для больших операций, требующих дополнительного временного хранилища.

Помните, что использование /app/work/tmpdir результатов в более медленной производительности по сравнению со значением временного хранилища (SSD) /mnt/temp по умолчанию. Выбор зависит от конкретных требований операций.

Информация, указанная для innodb_tmpdir этого, применима к параметрам innodb_temp_tablespaces_dir, tmpdir и slave_load_tmpdir где:

  • Общее значение /mnt/temp по умолчанию.
  • Альтернативный каталог /app/work/tmpdir доступен для настройки расширенного временного хранилища с компромиссом в производительности на основе конкретных операционных требований.

log_bin_trust_function_creators

В База данных Azure для MySQL — гибкий сервер, двоичные журналы всегда включены (то есть log_bin задано значение ON). Параметр log_bin_trust_function_creators по умолчанию устанавливается ON на гибких серверах.

Формат двоичного ведения журнала всегда ROWдоступен, а подключения к серверу всегда используют двоичное ведение журнала на основе строк. При использовании двоичного ведения журнала на основе строк проблемы безопасности не существуют, и двоичное ведение журнала не может прерываться, поэтому вы можете безопасно разрешить log_bin_trust_function_creators оставаться как ON.

Если log_bin_trust_function_creators задано OFF значение, и вы пытаетесь создать триггеры, могут возникнуть ошибки, аналогичные: "У вас нет привилегий SUPER, а двоичное ведение журнала включено (может потребоваться использовать менее безопасную log_bin_trust_function_creators переменную)."

innodb_buffer_pool_size

Чтобы узнать о параметре innodb_buffer_pool_size , ознакомьтесь с документацией по MySQL.

Размер физической памяти в следующей таблице представляет доступную память случайного доступа (ОЗУ) в гигабайтах (ГБ) на гибком сервере База данных Azure для MySQL.

Объем вычислительных ресурсов Количество виртуальных ядер Размер физической памяти (ГБ) Значение по умолчанию (байт) Минимальное значение (байт) Максимальное значение (байт)
С увеличивающейся производительностью
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536 870 912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Общего назначения
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
Критически важный для бизнеса
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

innodb_file_per_table

MySQL сохраняет таблицу InnoDB в разных пространствах таблиц на основе конфигурации, предоставленной во время создания таблицы. Табличное пространство системы — это область хранения для словаря данных InnoDB. Пространство таблиц для каждого файла содержит данные и индексы для одной таблицы InnoDB, и она хранится в файловой системе в собственном файле данных. Параметр сервера innodb_file_per_table управляет этим поведением.

Если задать для innodb_file_per_table значение OFF, InnoDB создаст таблицы в системном табличном пространстве. В противном случае InnoDB создает таблицы в табличных пространствах file-per-table.

База данных Azure для MySQL — гибкий сервер поддерживает не более 8 терабайт (ТБ) в одном файле данных. Если размер базы данных превышает 8 ТБ, необходимо создать таблицу innodb_file_per_table в пространстве таблиц. Если размер одной таблицы превышает 8 ТБ, следует использовать таблицу секционирования.

innodb_log_file_size

Значением innodb_log_file_size является размер (в байтах) каждого файла журнала в группе журналов. Объединенный размер файлов журнала (innodb_log_file_size innodb_log_files_in_group * ) не может превышать максимальное значение, которое чуть меньше 512 ГБ.

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

Можно настроить innodb_log_size 256 мегабайт (МБ), 512 МБ, 1 ГБ или 2 ГБ для База данных Azure для MySQL — гибкий сервер. Параметр является статическим и требует перезагрузки.

Примечание.

Если вы изменили innodb_log_file_size параметр по умолчанию, проверьте, остается ли значение show global status like 'innodb_buffer_pool_pages_dirty' в 0 течение 30 секунд, чтобы избежать задержки перезапуска.

max_connections

Размер памяти сервера определяет значение max_connections. Размер физической памяти в следующей таблице представляет доступную ОЗУ в гигабайтах на гибком сервере База данных Azure для MySQL.

Объем вычислительных ресурсов Количество виртуальных ядер Размер физической памяти (ГБ) Default value Минимальное значение Максимальное значение
С увеличивающейся производительностью
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Общего назначения
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
Критически важный для бизнеса
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

Если подключения превышают предел, может появиться следующая ошибка: ERROR 1040 (08004): слишком много подключений.

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

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

Примечание.

ProxySQL — это средство сообщества с открытым исходным кодом. Корпорация Майкрософт поддерживает ее на основе лучших усилий. Чтобы получить поддержку рабочей среды с помощью авторитетных рекомендаций, обратитесь в службу поддержки продуктов ProxySQL.

innodb_strict_mode

Если вы получаете ошибку, аналогичную ошибке "Размер строки слишком большой (> 8126)," может потребоваться отключить innodb_strict_mode параметр сервера. Этот параметр нельзя изменить глобально на уровне сервера, так как если размер данных строки превышает 8 КБ, данные усечены без ошибки. Это усечение может привести к потенциальной потере данных. Рекомендуется изменить схему в соответствии с предельным размером страницы.

Этот параметр можно задать на уровне сеанса с помощью init_connect. Дополнительные сведения см. в разделе "Настройка неизменяемых параметров сервера".

Примечание.

Если у вас есть сервер реплики чтения, параметр innodb_strict_mode OFF на уровне сеанса на исходном сервере прерывает репликацию. При наличии реплик чтения рекомендуем оставить параметр в состоянии ON.

time_zone

При первоначальном развертывании База данных Azure для MySQL — гибкий экземпляр сервера включает системные таблицы для сведений часового пояса, но эти таблицы не заполняются. Таблицы часовых поясов можно заполнить, вызвав mysql.az_load_timezone хранимую процедуру из средства, например командной строки MySQL или MySQL Workbench. Вы также можете вызвать хранимую процедуру и задать глобальные или часовые пояса уровня сеанса с помощью портал Azure или Azure CLI.

binlog_expire_logs_seconds

В База данных Azure для MySQL — гибкий сервер binlog_expire_logs_seconds параметр указывает количество секунд, которое служба ожидает перед удалением двоичного файла журнала.

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

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

Если вы хотите сохранить двоичные журналы в течение длительного времени, можно настроить binlog_expire_logs_seconds параметр. Если binlog_expire_logs_seconds задано значение 0по умолчанию, двоичный журнал удаляется сразу после освобождения дескриптора. Если значение binlog_expire_logs_seconds больше 0, двоичный журнал удаляется после заданного количества секунд.

База данных Azure для MySQL — гибкий сервер обрабатывает управляемые функции, такие как резервное копирование и удаление реплики чтения двоичных файлов, внутренне. При репликации данных из База данных Azure для MySQL — гибкий сервер этот параметр необходимо задать в основном, чтобы избежать удаления двоичных журналов, прежде чем реплика считывает изменения в основном сервере. Если задано binlog_expire_logs_seconds более высокое значение, двоичные журналы не будут удалены в ближайшее время. Эта задержка может привести к увеличению выставления счетов за хранение.

event_scheduler

В База данных Azure для MySQL — гибкий сервер, event_scheduler параметр сервера управляет созданием, планированием и выполнением событий. То есть параметр управляет задачами, выполняемыми в соответствии с расписанием специальным потоком планировщика событий MySQL. event_scheduler Если для параметра задано значениеON, поток планировщика событий отображается как процесс управляющей программы в выходных SHOW PROCESSLISTданных.

Для серверов MySQL версии 5.7 параметр event_scheduler сервера автоматически отключается при инициировании резервного копирования , а параметр event_scheduler сервера возвращается после успешного завершения резервного копирования. В MySQL версии 8.0 для База данных Azure для MySQL — гибкий сервер event_scheduler остается небезопасным во время резервного копирования. Чтобы обеспечить более плавные операции, рекомендуется обновить серверы MySQL 5.7 до версии 8.0 с помощью обновления основной версии.

Вы можете создавать и планировать события с помощью следующего синтаксиса SQL:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT '<comment>'
DO
<your statement>;

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

Настройка параметра сервера event_scheduler

В следующем сценарии показан один из способов использования event_scheduler параметра в База данных Azure для MySQL — гибкий сервер.

Чтобы продемонстрировать сценарий, рассмотрим следующий пример простой таблицы:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
| +-----------+-------------+------+-----+---------+----------------+ |
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
| +-----------+-------------+------+-----+---------+----------------+ |
| 3 rows in set (0.23 sec) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```sql

    CREATE EVENT test_event_01
    ON SCHEDULE EVERY 1 MINUTE
    STARTS CURRENT_TIMESTAMP
    ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
    COMMENT 'Inserting record into the table tab1 with current timestamp'
    DO
    INSERT INTO tab1(id,createdAt,createdBy)
    VALUES('',NOW(),CURRENT_USER());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    mysql> show events;
    +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
    | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation |
    | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ |
    | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci |
    | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ |
    | 1 row in set (0.23 sec) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    mysql> select * from tab1;
    +----+---------------------+-------------+
    | id | CreatedAt | CreatedBy |
    | +----+---------------------+-------------+ |
    | 1 | 2023-04-05 14:47:04 | azureuser@% |
    | 2 | 2023-04-05 14:48:04 | azureuser@% |
    | 3 | 2023-04-05 14:49:04 | azureuser@% |
    | 4 | 2023-04-05 14:50:04 | azureuser@% |
    | +----+---------------------+-------------+ |
    | 4 rows in set (0.23 sec) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    mysql> select * from tab1;
    +----+---------------------+-------------+
    | id | CreatedAt | CreatedBy |
    | +----+---------------------+-------------+ |
    | 1 | 2023-04-05 14:47:04 | azureuser@% |
    | 2 | 2023-04-05 14:48:04 | azureuser@% |
    | 3 | 2023-04-05 14:49:04 | azureuser@% |
    | 4 | 2023-04-05 14:50:04 | azureuser@% |
    | 5 | 2023-04-05 14:51:04 | azureuser@% |
    | 6 | 2023-04-05 14:52:04 | azureuser@% |
    | ..< 50 lines trimmed to compact output >.. |
    | 56 | 2023-04-05 15:42:04 | azureuser@% |
    | 57 | 2023-04-05 15:43:04 | azureuser@% |
    | 58 | 2023-04-05 15:44:04 | azureuser@% |
    | 59 | 2023-04-05 15:45:04 | azureuser@% |
    | 60 | 2023-04-05 15:46:04 | azureuser@% |
    | 61 | 2023-04-05 15:47:04 | azureuser@% |
    | +----+---------------------+-------------+ |
    | 61 rows in set (0.23 sec) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

```sql
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Выполнение инструкции SQL каждый час без конца:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Для выполнения инструкции SQL каждый день без конца:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

Ограничения

Для серверов с высокой доступностью, настроенных при отработки отказа, возможно event_scheduler , что для параметра сервера задано значение OFF. Если это происходит, когда отработка отказа завершена, настройте параметр, чтобы задать значение ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table — это параметр сервера в MySQL, указывающий имя таблицы, содержащей настраиваемые стоп-слова для полнотекстового поиска InnoDB. Таблица должна находиться в той же базе данных, что и полнотекстовая индексированная таблица, а ее первый столбец должен иметь тип VARCHAR. В База данных Azure для MySQL — гибкий сервер, параметр sql_generate_invisible_primary_key=ON по умолчанию приводит ко всем таблицам без явного первичного ключа автоматически включать невидимый первичный ключ. Это поведение конфликтует с требованиями для innodb_ft_user_stopword_table, так как невидимый первичный ключ становится первым столбцом таблицы, предотвращая его функционирование в соответствии с требованиями во время полнотекстового поиска. Чтобы устранить эту проблему, необходимо задать sql_generate_invisible_primary_key=OFF в том же сеансе перед созданием настраиваемой таблицы стоп-слов. Например:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Это гарантирует, что таблица стоп-слов соответствует требованиям MySQL и позволяет пользовательским стоп-словам правильно работать.

Параметры сервера, не изменяемые

В области параметров сервера в портал Azure отображаются изменяемые и неизменяемые параметры сервера. Неизменяемые параметры сервера недоступны. Параметр сервера без изменения можно настроить на уровне сеанса с помощью init_connect портал Azure или Azure CLI.

Связанный контент