Параметры сервера в базе данных Azure для MySQL
ОБЛАСТЬ ПРИМЕНЕНИЯ:
База данных Azure для MySQL — отдельный сервер
Важно!
База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"
В этой статье приведены советы и рекомендации по настройке параметров сервера в базе данных Azure для MySQL.
Что такое параметры сервера?
Ядро MySQL предоставляет множество различных переменных и параметров сервера, которые используются для изменения конфигурации и настройки поведения ядра. Некоторые параметры могут быть заданы динамически во время выполнения, а другие являются статическими, и для их применения требуется перезагрузка сервера.
База данных Azure для MySQL предоставляет возможность изменять значение различных параметров сервера MySQL с помощью портала Azure, Azure CLI и PowerShell в соответствии с потребностями рабочей нагрузки.
Настраиваемые параметры сервера
Список поддерживаемых параметров постоянно растет. Для просмотра полного списка и настройки значений параметров сервера используйте вкладку "Параметры сервера" на портале Azure.
Дополнительные сведения об ограничениях для нескольких часто настраиваемых параметров сервера см. в следующих разделах. Ограничения определяются ценовой категорией и числом виртуальных ядер сервера.
Пулы потоков
Как правило, MySQL назначает поток для каждого подключения клиента. По мере роста числа одновременных пользователей наблюдается соответствующее снижение производительности. Многие активные потоки могут значительно влиять на производительность за счет увеличения переключений контекста, состязаний потоков и неправильного местоположения кэшей ЦП.
Пулы потоков — это функция, которая работает на стороне сервера отдельно от пулов подключения. Она максимально повышает производительность за счет использования динамического пула и рабочих потоков. Эта функция используется для ограничения количества активных потоков, выполняемых на сервере, и сведения к минимуму оттока потока. Это помогает убедиться, что всплеск подключений не приводит к нехватке ресурсов или памяти сервера. Пулы потоков наиболее эффективны для коротких запросов и интенсивных рабочих нагрузок на ЦП, таких как рабочие нагрузки OLTP.
Дополнительные сведения см. в записи блога Вводные сведения о пулах потоков в Базе данных Azure для MySQL.
Примечание.
Пулы потоков не поддерживаются для MySQL 5.6.
Настройка пула потоков
Чтобы включить пул потоков, обновите параметр сервера thread_handling, указав значение pool-of-threads. По умолчанию для этого параметра задано значение one-thread-per-connection, означающее, что MySQL создает новый поток для каждого нового соединения. Это статический параметр, для применения которого требуется перезагрузка сервера.
Кроме того, можно настроить максимальное и минимальное количество потоков в пуле, установив следующие параметры сервера:
thread_pool_max_threads: это значение ограничивает количество потоков в пуле.thread_pool_min_threads: это значение задает количество зарезервированных потоков, даже после закрытия подключений.
Чтобы повысить производительность коротких запросов в пуле потоков, можно включить пакетное выполнение. Вместо немедленного возврата к пулу потоков после выполнения запроса потоки будут кратковременно поддерживаться в активном состоянии, пока не поступи следующий запрос в рамках этого подключения. Затем поток быстро выполняет запрос и по завершении выполнения ожидает следующего. Этот процесс будет продолжаться, пока общее время не превысит порог.
Поведение пакетного выполнения определяется с помощью следующих параметров сервера:
thread_pool_batch_wait_timeout: время, в течение которого поток ожидает обработки другого запроса.thread_pool_batch_max_time: максимальное время, в течение которого поток будет повторять цикл выполнения запроса и ожидает следующий запрос.
Важно!
Не включайте пул потоков в рабочей среде, пока он не будет протестирован.
log_bin_trust_function_creators
В Базе данных Azure для MySQL двоичные файлы журналов всегда включены (т.е. для параметра log_bin установлено значение ON). Если вы хотите использовать триггеры, вы получите ошибку, аналогичную следующей: у вас нет прав супер и двоичного ведения журнала включена (возможно, вы хотите использовать менее безопасную log_bin_trust_function_creators переменную).)
В качестве формата двоичного журнала всегда выбран вариант ROW, а для всех подключений к серверу двоичные журналы всегда ведутся на основе строк. Ведение двоичных журналов на основе строк помогает поддерживать безопасность. Оно не прерывается, поэтому можно спокойно установить для log_bin_trust_function_creators значение TRUE.
innodb_buffer_pool_size
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
Серверы в хранилище общего назначения версии 1 (поддерживается объем данных до 4 ТБ)
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение (байт) |
|---|---|---|---|---|
| Основное | 1 | 872415232 | 134217728 | 872415232 |
| Основное | 2 | 2684354560 | 134217728 | 2684354560 |
| Общего назначения | 2 | 3758096384 | 134217728 | 3758096384 |
| Общего назначения | 4 | 8053063680 | 134217728 | 8053063680 |
| Общего назначения | 8 | 16106127360 | 134217728 | 16106127360 |
| Общее назначение | 16 | 32749125632 | 134217728 | 32749125632 |
| Общее назначение | 32 | 66035122176 | 134217728 | 66035122176 |
| Общее назначение | 64 | 132070244352 | 134217728 | 132070244352 |
| С оптимизацией для операций в памяти | 2 | 7516192768 | 134217728 | 7516192768 |
| С оптимизацией для операций в памяти | 4 | 16106127360 | 134217728 | 16106127360 |
| С оптимизацией для операций в памяти | 8 | 32212254720 | 134217728 | 32212254720 |
| С оптимизацией для операций в памяти | 16 | 65498251264 | 134217728 | 65498251264 |
| С оптимизацией для операций в памяти | 32 | 132070244352 | 134217728 | 132070244352 |
Серверы в хранилище общего назначения версии 2 (поддерживается объем данных до 16 ТБ)
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение (байт) |
|---|---|---|---|---|
| Основное | 1 | 872415232 | 134217728 | 872415232 |
| Основное | 2 | 2684354560 | 134217728 | 2684354560 |
| Общего назначения | 2 | 7516192768 | 134217728 | 7516192768 |
| Общего назначения | 4 | 16106127360 | 134217728 | 16106127360 |
| Общего назначения | 8 | 32212254720 | 134217728 | 32212254720 |
| Общее назначение | 16 | 65498251264 | 134217728 | 65498251264 |
| Общее назначение | 32 | 132070244352 | 134217728 | 132070244352 |
| Общее назначение | 64 | 264140488704 | 134217728 | 264140488704 |
| С оптимизацией для операций в памяти | 2 | 15032385536 | 134217728 | 15032385536 |
| С оптимизацией для операций в памяти | 4 | 32212254720 | 134217728 | 32212254720 |
| С оптимизацией для операций в памяти | 8 | 64424509440 | 134217728 | 64424509440 |
| С оптимизацией для операций в памяти | 16 | 130996502528 | 134217728 | 130996502528 |
| С оптимизацией для операций в памяти | 32 | 264140488704 | 134217728 | 264140488704 |
innodb_file_per_table
MySQL хранит таблицу InnoDB в разных табличных пространствах в зависимости от конфигурации, которую вы указываете при создании таблицы. Табличное пространство системы — это область хранения для словаря данных InnoDB. Табличное пространство file-per-table содержит данные и индексы для одной таблицы InnoDB и хранится в файловой системе в собственном файле данных.
Для управления этим поведением используется параметр сервера innodb_file_per_table. Если задать для innodb_file_per_table значение OFF, InnoDB создаст таблицы в системном табличном пространстве. В противном случае InnoDB создает таблицы в табличных пространствах file-per-table.
Примечание.
Обновление innodb_file_per_table можно выполнять только в ценовых категориях "Общего назначения" и "Оптимизировано для операций в памяти" хранилища общего назначения версии 2 и хранилища общего назначения версии 1.
База данных Azure для MySQL поддерживает размер 4 ТБ (максимум) для одного файла данных в хранилище общего назначения версии 2. Если размер базы данных превышает 4 ТБ, следует создать таблицу в табличном пространстве innodb_file_per_table. Если размер одной таблицы превышает 4 ТБ, следует использовать таблицу секционирования.
join_buffer_size
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение (байт) |
|---|---|---|---|---|
| Основное | 1 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Основное | 2 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Общего назначения | 2 | 262144 | 128 | 268435455 |
| Общего назначения | 4 | 262144 | 128 | 536 870 912 |
| Общего назначения | 8 | 262144 | 128 | 1073741824 |
| Общее назначение | 16 | 262144 | 128 | 2147483648 |
| Общее назначение | 32 | 262144 | 128 | 4294967295 |
| Общее назначение | 64 | 262144 | 128 | 4294967295 |
| С оптимизацией для операций в памяти | 2 | 262144 | 128 | 536 870 912 |
| С оптимизацией для операций в памяти | 4 | 262144 | 128 | 1073741824 |
| С оптимизацией для операций в памяти | 8 | 262144 | 128 | 2147483648 |
| С оптимизацией для операций в памяти | 16 | 262144 | 128 | 4294967295 |
| С оптимизацией для операций в памяти | 32 | 262144 | 128 | 4294967295 |
max_connections
| Ценовая категория | Виртуальные ядра | Значение по умолчанию | Минимальное значение | Максимальное значение |
|---|---|---|---|---|
| Основное | 1 | 50 | 10 | 50 |
| Основное | 2 | 100 | 10 | 100 |
| Общего назначения | 2 | 300 | 10 | 600 |
| Общего назначения | 4 | 625 | 10 | 1250 |
| Общего назначения | 8 | 1250 | 10 | 2500 |
| Общее назначение | 16 | 2500 | 10 | 5000 |
| Общее назначение | 32 | 5000 | 10 | 10000 |
| Общее назначение | 64 | 10000 | 10 | 20000 |
| С оптимизацией для операций в памяти | 2 | 625 | 10 | 1250 |
| С оптимизацией для операций в памяти | 4 | 1250 | 10 | 2500 |
| С оптимизацией для операций в памяти | 8 | 2500 | 10 | 5000 |
| С оптимизацией для операций в памяти | 16 | 5000 | 10 | 10000 |
| С оптимизацией для операций в памяти | 32 | 10000 | 10 | 20000 |
Если число подключений превышает установленное ограничение, может произойти ошибка.
Совет
Для эффективного управления подключениями целесообразно использовать пул подключений, например ProxySQL. Дополнительные сведения о настройке ProxySQL см. в записи блога Балансировка нагрузки реплик чтения с использованием ProxySQL в Базе данных Azure для MySQL. Обратите внимание, что ProxySQL — это продукт сообщества разработчиков решений с открытым кодом. Это решение по мере возможности поддерживает корпорация Майкрософт.
max_heap_table_size
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение (байт) |
|---|---|---|---|---|
| Основное | 1 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Основное | 2 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Общего назначения | 2 | 16777216 | 16384 | 268435455 |
| Общего назначения | 4 | 16777216 | 16384 | 536 870 912 |
| Общего назначения | 8 | 16777216 | 16384 | 1073741824 |
| Общее назначение | 16 | 16777216 | 16384 | 2147483648 |
| Общее назначение | 32 | 16777216 | 16384 | 4294967295 |
| Общее назначение | 64 | 16777216 | 16384 | 4294967295 |
| С оптимизацией для операций в памяти | 2 | 16777216 | 16384 | 536 870 912 |
| С оптимизацией для операций в памяти | 4 | 16777216 | 16384 | 1073741824 |
| С оптимизацией для операций в памяти | 8 | 16777216 | 16384 | 2147483648 |
| С оптимизацией для операций в памяти | 16 | 16777216 | 16384 | 4294967295 |
| С оптимизацией для операций в памяти | 32 | 16777216 | 16384 | 4294967295 |
query_cache_size
По умолчанию кэш запросов отключен. Чтобы включить кэш запросов, настройте параметр query_cache_type.
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
Примечание.
Кэш запросов устарел в MySQL 5.7.20 и был удален в MySQL 8.0.
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение |
|---|---|---|---|---|
| Основное | 1 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Основное | 2 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Общего назначения | 2 | 0 | 0 | 16777216 |
| Общего назначения | 4 | 0 | 0 | 33554432 |
| Общего назначения | 8 | 0 | 0 | 67108864 |
| Общее назначение | 16 | 0 | 0 | 134217728 |
| Общее назначение | 32 | 0 | 0 | 134217728 |
| Общее назначение | 64 | 0 | 0 | 134217728 |
| С оптимизацией для операций в памяти | 2 | 0 | 0 | 33554432 |
| С оптимизацией для операций в памяти | 4 | 0 | 0 | 67108864 |
| С оптимизацией для операций в памяти | 8 | 0 | 0 | 134217728 |
| С оптимизацией для операций в памяти | 16 | 0 | 0 | 134217728 |
| С оптимизацией для операций в памяти | 32 | 0 | 0 | 134217728 |
lower_case_table_names
По умолчанию параметру lower_case_table_name присвоено значение 1. Его можно обновить в MySQL 5.6 и MySQL 5.7
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
Примечание.
В MySQL 8.0 для lower_case_table_name по умолчанию установлено значение 1. Его нельзя изменить.
innodb_strict_mode
Если поступает сообщение об ошибке, подобное Row size too large (> 8126), попробуйте отключить параметр innodb_strict_mode. innodb_strict_mode нельзя глобально изменить на уровне сервера. Если размер данных строки превышает 8 КБ, данные усекаются без уведомления об ошибке. Это может привести к потере данных. Целесообразно изменить схему в соответствии с предельным размером страницы.
Этот параметр можно задать на уровне сеанса с помощью init_connect . Сведения о том, как задать innodb_strict_mode на уровне сеанса, см. в разделе об отсутствии в списке параметра настройки.
Примечание.
При наличии сервера-реплики чтения установка для параметра innodb_strict_mode значения OFF на уровне сеанса на исходном сервере приведет к нарушению репликации. При наличии реплик чтения рекомендуем оставить параметр в состоянии ON.
sort_buffer_size
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение (байт) |
|---|---|---|---|---|
| Основное | 1 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Основное | 2 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Общего назначения | 2 | 524288 | 32768 | 4194304 |
| Общего назначения | 4 | 524288 | 32768 | 8388608 |
| Общего назначения | 8 | 524288 | 32768 | 16777216 |
| Общее назначение | 16 | 524288 | 32768 | 33554432 |
| Общее назначение | 32 | 524288 | 32768 | 33554432 |
| Общее назначение | 64 | 524288 | 32768 | 33554432 |
| С оптимизацией для операций в памяти | 2 | 524288 | 32768 | 8388608 |
| С оптимизацией для операций в памяти | 4 | 524288 | 32768 | 16777216 |
| С оптимизацией для операций в памяти | 8 | 524288 | 32768 | 33554432 |
| С оптимизацией для операций в памяти | 16 | 524288 | 32768 | 33554432 |
| С оптимизацией для операций в памяти | 32 | 524288 | 32768 | 33554432 |
tmp_table_size
Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.
| Ценовая категория | Виртуальные ядра | Значение по умолчанию (байт) | Минимальное значение (байт) | Максимальное значение (байт) |
|---|---|---|---|---|
| Основное | 1 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Основное | 2 | Не настраивается на уровне "Базовый" | Неприменимо | Неприменимо |
| Общего назначения | 2 | 16777216 | 1024 | 67108864 |
| Общего назначения | 4 | 16777216 | 1024 | 134217728 |
| Общего назначения | 8 | 16777216 | 1024 | 268435456 |
| Общее назначение | 16 | 16777216 | 1024 | 536 870 912 |
| Общее назначение | 32 | 16777216 | 1024 | 1073741824 |
| Общее назначение | 64 | 16777216 | 1024 | 1073741824 |
| С оптимизацией для операций в памяти | 2 | 16777216 | 1024 | 134217728 |
| С оптимизацией для операций в памяти | 4 | 16777216 | 1024 | 268435456 |
| С оптимизацией для операций в памяти | 8 | 16777216 | 1024 | 536 870 912 |
| С оптимизацией для операций в памяти | 16 | 16777216 | 1024 | 1073741824 |
| С оптимизацией для операций в памяти | 32 | 16777216 | 1024 | 1073741824 |
Прогрев буферного пула InnoDB
После перезапуска сервера Базы данных Azure для MySQL страницы данных, которые размещены на диске, загружаются по мере запроса таблиц. Это приводит к увеличению задержки и снижению производительности при первом выполнении запросов. Если рабочие нагрузки чувствительны к задержкам, возможно, такая пониженная производительность будет неприемлемой.
Вы можете выполнить прогрев буферного пула InnoDB, чтобы сократить период прогрева. В рамках этого процесса перезагружаются страницы диска, которые находились в буферном пуле перед перезагрузкой, вместо того чтобы ожидать, пока операции DML или SELECT достигнут соответствующих строк. Дополнительные сведения см. в статье Параметры сервера буферного пула InnoDB.
Однако повышение производительности происходит за счет более длительного времени запуска сервера. При включении этого параметра ожидается увеличение времени запуска сервера и перезапуска в зависимости от операций ввода-вывода в секунду, подготовленного на сервере. Целесообразно тестировать и отслеживать время перезапуска, чтобы обеспечить приемлемую производительность при запуске и перезапуске, так как сервер в это время недоступен. Не используйте этот параметр, если количество подготовленных операций ввода-вывода в секунду меньше 1000 операций ввода-вывода в секунду (иными словами, при подготовке хранилища меньше 335 ГБ).
Чтобы сохранить состояние буферного пула при завершении работы сервера, присвойте параметру сервера innodb_buffer_pool_dump_at_shutdown значение ON. Аналогичным образом задайте для параметра сервера innodb_buffer_pool_load_at_startup значение ON, чтобы восстановить состояние буферного пула при запуске сервера. Управлять влиянием на запуск или перезапуск можно путем уменьшения и точной настройки значения параметра сервера innodb_buffer_pool_dump_pct. По умолчанию этот параметр имеет значение 25.
Примечание.
Параметры "прогрева" буферного пула InnoDB поддерживаются только на серверах хранилищ общего назначения с хранилищем объемом до 16 ТБ. Дополнительные сведения см. в разделе Параметры хранилища Базы данных Azure для MySQL.
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 значение 0, которое является значением по умолчанию, очистка выполняется, как только освобождается двоичный журнал. Если задать для параметра binlog_expire_logs_seconds значение больше 0, двоичный журнал очищается только по истечении этого периода.
Для Базы данных Azure для MySQL управляемые функции, такие как резервное копирование и очистка двоичных файлов от копий для чтения, обрабатываются внутренним образом. При репликации данных из службы Базы данных Azure для MySQL установите этот параметр в первичном виде, чтобы избежать очистки двоичных журналов до того, как реплика считает изменения из первичной. Если задать для binlog_expire_logs_seconds большее значение, двоичные журналы не будут очищаться достаточно быстро. Это может привести к увеличению суммы счета за хранилище.
event_scheduler
В База данных Azure для MySQL event_schedule параметр сервера управляет созданием, планированием и выполнением событий, т. е. задачами, выполняемыми в соответствии с расписанием, и выполняется специальным потоком планировщика событий. event_scheduler Если для параметра задано значение ON, поток планировщика событий отображается как процесс управляющей программы в выходных данных SHOW PROCESSLIST. Вы можете создавать и планировать события с помощью следующего синтаксиса 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)
Чтобы настроить event_scheduler параметр сервера в База данных Azure для MySQL, выполните следующие действия.
В портал Azure перейдите к серверу, а затем в разделе Параметры выберите параметры сервера.
В колонке параметров сервера найдите
event_schedulerв раскрывающемся списке VALUE, выберите ON и нажмите кнопку "Сохранить".Примечание.
Изменение конфигурации параметров динамического сервера будет развернуто без перезапуска.
Затем, чтобы создать событие, подключитесь к серверу MySQL и выполните следующую команду 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());Чтобы просмотреть сведения о планировщике событий, выполните следующую инструкцию SQL:
SHOW EVENTS;Отображаются следующие результаты:
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)Через несколько минут запросите строки из таблицы, чтобы начать просмотр строк, вставляемых каждую минуту в соответствии с настроенным параметром
event_scheduler: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)Через час выполните инструкцию Select в таблице, чтобы просмотреть полный результат значений, вставленных в таблицу каждую минуту в течение часа, как
event_schedulerэто настроено в нашем случае.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)
Другие сценарии
Событие можно настроить на основе требований конкретного сценария. Ниже приведены несколько аналогичных примеров планирования инструкций SQL для выполнения в разных интервалах времени.
Выполните инструкцию 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>;
Ненастраиваемые параметры сервера
Следующие параметры сервера нельзя настроить в службе:
| Параметр | Фиксированное значение |
|---|---|
innodb_file_per_table на уровне "Базовый" |
ВЫКЛ. |
innodb_flush_log_at_trx_commit |
1 |
sync_binlog |
1 |
innodb_log_file_size |
256 МБ |
innodb_log_files_in_group |
2 |
Другим переменным, не указанным здесь, присваиваются значения по умолчанию MySQL. Сведения о версиях 8.0, 5.7 и 5.6 см. в документации по MySQL.
Следующие шаги
- См. статью Настройка параметров сервера с помощью портала Azure.
- См. статью Настройка параметров сервера с помощью Azure CLI.
- См. статью Настройка параметров сервера с помощью PowerShell.