Parámetros del servidor en Azure Database for MySQL

  • Artículo

SE APLICA A: Azure Database for MySQL: Servidor único

Importante

El servidor único de Azure Database for MySQL está en la ruta de retirada. Se recomienda encarecidamente actualizar al servidor flexible de Azure Database for MySQL. Para más información sobre la migración al servidor flexible de Azure Database for MySQL, consulte ¿Qué ocurre con Azure Database for MySQL con servidor único?

En este artículo se incluyen consideraciones e instrucciones para configurar parámetros del servidor en Azure Database for MySQL.

¿Cuáles son los parámetros del servidor?

El motor de MySQL proporciona muchas variables y parámetros del servidor diferentes que se pueden usar para configurar y ajustar el comportamiento del motor. Algunos parámetros se pueden establecer de forma dinámica en tiempo de ejecución, mientras que otros son estáticos y requieren un reinicio del servidor para su aplicación.

Azure Database for MySQL expone la capacidad de cambiar el valor de diversos parámetros del servidor MySQL mediante Azure Portal, la CLI de Azure y PowerShell para satisfacer las necesidades de la carga de trabajo.

Parámetros configurables del servidor

La lista de parámetros del servidor admitidos crece constantemente. Use la pestaña de parámetros del servidor de Azure Portal para ver la lista completa y configurar los valores de los parámetros del servidor.

Consulte las siguientes secciones para más información sobre los límites de varios parámetros del servidor actualizados habitualmente. Los límites vienen determinados por el plan de tarifa y los núcleos virtuales del servidor.

Agrupación de subprocesos

MySQL asigna tradicionalmente un subproceso para cada conexión de cliente. A medida que crece el número de usuarios simultáneos, hay una reducción correspondiente del rendimiento. Muchos subprocesos activos pueden afectar significativamente al rendimiento debido a un aumento del cambio de contexto, la contención de subprocesos y la localidad incorrecta de las memorias caché de la CPU.

Grupos de subprocesos, una característica del lado servidor y distinta de la agrupación de conexiones que maximiza el rendimiento mediante la introducción de un grupo dinámico de subprocesos de trabajo. Esta característica se usa para limitar el número de subprocesos activos que se ejecutan en el servidor y minimizar el abandono de subprocesos. Esto ayuda a garantizar que una ráfaga de conexiones no haga que el servidor se quede sin recursos o memoria. Los grupos de subprocesos son más eficaces para las consultas cortas y las cargas de trabajo de gran consumo de CPU, como las cargas de trabajo OLTP.

Para más información, consulte Introducción a los grupos de subprocesos en Azure Database for MySQL.

Nota:

Los grupos de subprocesos no son compatibles con MySQL 5.6.

Configuración del grupo de subprocesos

Para habilitar un grupo de subprocesos, actualice el parámetro del servidor thread_handling a pool-of-threads. De manera predeterminada, este parámetro se establece en one-thread-per-connection, lo que significa que MySQL crea un nuevo subproceso para cada nueva conexión. Este es un parámetro estático y requiere un reinicio del servidor para su aplicación.

También puede configurar el número máximo y mínimo de subprocesos del grupo mediante el establecimiento de los siguientes parámetros del servidor:

  • thread_pool_max_threads: este valor limita el número de subprocesos del grupo.
  • thread_pool_min_threads: este valor establece el número de subprocesos que se reservarán incluso después de cerrarse las conexiones.

Para mejorar los problemas de rendimiento de las consultas cortas en el grupo de subprocesos, puede habilitar la ejecución por lotes. En lugar de volver al grupo de subprocesos inmediatamente después de ejecutar una consulta, los subprocesos se mantendrán activos durante un breve período de tiempo para esperar a la siguiente consulta mediante esta conexión. A continuación, el subproceso ejecuta la consulta rápidamente y, cuando se completa, el subproceso espera a la siguiente. Este proceso continúa hasta que el tiempo total empleado supera un umbral.

El comportamiento de la ejecución por lotes se determina mediante los siguientes parámetros del servidor:

  • thread_pool_batch_wait_timeout: este valor especifica el tiempo que espera un subproceso para que se procese otra consulta.
  • thread_pool_batch_max_time: este valor determina el tiempo máximo que empleará un subproceso para repetir el ciclo de ejecución de la consulta y esperar a la siguiente consulta.

Importante

No active el grupo de subprocesos en producción hasta que lo haya probado.

log_bin_trust_function_creators

En Azure Database for MySQL, siempre están habilitados los registros binarios (el parámetro log_bin está establecido en ON). Si quiere usar desencadenadores, obtendrá un error similar al siguiente: No tiene el privilegio SUPER y el registro binario está habilitado (es posible que desee usar la variable menos segura log_bin_trust_function_creators).

El formato del registro binario siempre es ROW y todas las conexiones al servidor siempre usan el registro binario basado en filas. El registro binario basado en filas ayuda a mantener la seguridad y el registro binario no se puede interrumpir, por lo que puede establecer de forma segura log_bin_trust_function_creators en TRUE.

innodb_buffer_pool_size

Consulte la documentación de MySQL para más información acerca de este parámetro.

Servidores con almacenamiento de uso general v1 (admite hasta 4 TB)

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básico 1 872415232 134217728 872415232
Básico 2 2684354560 134217728 2684354560
De uso general 2 3758096384 134217728 3758096384
De uso general 4 8053063680 134217728 8053063680
De uso general 8 16106127360 134217728 16106127360
De uso general 16 32749125632 134217728 32749125632
De uso general 32 66035122176 134217728 66035122176
De uso general 64 132070244352 134217728 132070244352
Memoria optimizada 2 7516192768 134217728 7516192768
Memoria optimizada 4 16106127360 134217728 16106127360
Memoria optimizada 8 32212254720 134217728 32212254720
Memoria optimizada 16 65498251264 134217728 65498251264
Memoria optimizada 32 132070244352 134217728 132070244352

Servidores con almacenamiento de uso general v2 (admite hasta 16 TB)

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básico 1 872415232 134217728 872415232
Básico 2 2684354560 134217728 2684354560
De uso general 2 7516192768 134217728 7516192768
De uso general 4 16106127360 134217728 16106127360
De uso general 8 32212254720 134217728 32212254720
De uso general 16 65498251264 134217728 65498251264
De uso general 32 132070244352 134217728 132070244352
De uso general 64 264140488704 134217728 264140488704
Memoria optimizada 2 15032385536 134217728 15032385536
Memoria optimizada 4 32212254720 134217728 32212254720
Memoria optimizada 8 64424509440 134217728 64424509440
Memoria optimizada 16 130996502528 134217728 130996502528
Memoria optimizada 32 264140488704 134217728 264140488704

innodb_file_per_table

MySQL almacena la tabla InnoDB en distintos espacios de tablas en función de la configuración proporcionada durante la creación de la tabla. El espacio de tabla del sistema es el área de almacenamiento para el diccionario de datos de InnoDB. Un espacio de tabla de archivo por tabla contiene los datos e índices de una sola tabla InnoDB y se almacena en el sistema de archivos en su propio archivo de datos.

Este comportamiento se controla mediante el parámetro del servidor innodb_file_per_table. Si innodb_file_per_table se establece en OFF, InnoDB crea tablas en el espacio de tabla del sistema. De lo contrario, InnoDB crea tablas en los espacios de tabla de archivo por tabla.

Nota:

Solo puede actualizar innodb_file_per_table en los planes de tarifa De uso general y Optimizada para memoria en el almacenamiento de uso general v2 y el almacenamiento de uso general v1.

Azure Database for MySQL admite 4 TB (como máximo) en un solo archivo de datos en el almacenamiento de uso general v2. Si el tamaño de la base de datos es superior a 4 TB, debe crear la tabla en el espacio de tabla innodb_file_per_table. Si tiene una sola tabla de tamaño superior a 4 TB, debe usar la tabla de particiones.

join_buffer_size

Consulte la documentación de MySQL para más información acerca de este parámetro.

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básico 1 No se puede configurar en el nivel Básico N/D N/D
Básico 2 No se puede configurar en el nivel Básico N/D N/D
Uso general 2 262 144 128 268435455
Uso general 4 262 144 128 536870912
Uso general 8 262 144 128 1073741824
Uso general 16 262 144 128 2147483648
Uso general 32 262 144 128 4294967295
Uso general 64 262 144 128 4294967295
Memoria optimizada 2 262 144 128 536870912
Memoria optimizada 4 262 144 128 1073741824
Memoria optimizada 8 262 144 128 2147483648
Memoria optimizada 16 262 144 128 4294967295
Memoria optimizada 32 262 144 128 4294967295

max_connections

Plan de tarifa Núcleos virtuales Valor predeterminado Valor mínimo Valor máximo
Básico 1 50 10 50
Básico 2 100 10 100
Uso general 2 300 10 600
Uso general 4 625 10 1250
Uso general 8 1250 10 2.500
Uso general 16 2.500 10 5000
Uso general 32 5000 10 10000
Uso general 64 10000 10 20000
Memoria optimizada 2 625 10 1250
Memoria optimizada 4 1250 10 2.500
Memoria optimizada 8 2.500 10 5000
Memoria optimizada 16 5000 10 10000
Memoria optimizada 32 10000 10 20000

Cuando el número de conexiones supera el límite, es posible que reciba un error.

Sugerencia

Para administrar las conexiones de forma eficaz, es una buena idea usar un agrupador de conexiones, como ProxySQL. Para obtener información sobre la configuración de ProxySQL, consulte la entrada de blog Equilibrio de carga de réplicas de lectura mediante ProxySQL en Azure Database for MySQL. Tenga en cuenta que ProxySQL es una herramienta de la comunidad de código abierto. Tiene soporte técnico de Microsoft dentro de lo posible.

max_heap_table_size

Consulte la documentación de MySQL para más información acerca de este parámetro.

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básico 1 No se puede configurar en el nivel Básico N/D N/D
Básico 2 No se puede configurar en el nivel Básico N/D N/D
Uso general 2 16777216 16384 268435455
Uso general 4 16777216 16384 536870912
Uso general 8 16777216 16384 1073741824
Uso general 16 16777216 16384 2147483648
Uso general 32 16777216 16384 4294967295
Uso general 64 16777216 16384 4294967295
Memoria optimizada 2 16777216 16384 536870912
Memoria optimizada 4 16777216 16384 1073741824
Memoria optimizada 8 16777216 16384 2147483648
Memoria optimizada 16 16777216 16384 4294967295
Memoria optimizada 32 16777216 16384 4294967295

query_cache_size

La caché de consulta está desactivada de forma predeterminada. Para habilitar la caché de consulta, configure el parámetro query_cache_type.

Consulte la documentación de MySQL para más información acerca de este parámetro.

Nota

La caché de consulta está en desuso desde MySQL 5.7.20 y se quitó en MySQL 8.0.

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo
Básico 1 No se puede configurar en el nivel Básico N/D N/D
Básico 2 No se puede configurar en el nivel Básico N/D N/D
Uso general 2 0 0 16777216
Uso general 4 0 0 33554432
Uso general 8 0 0 67108864
Uso general 16 0 0 134217728
Uso general 32 0 0 134217728
Uso general 64 0 0 134217728
Memoria optimizada 2 0 0 33554432
Memoria optimizada 4 0 0 67108864
Memoria optimizada 8 0 0 134217728
Memoria optimizada 16 0 0 134217728
Memoria optimizada 32 0 0 134217728

lower_case_table_names

De manera predeterminada, el parámetro lower_case_table_name está establecido en 1 y puede actualizar este parámetro en MySQL 5.6 y MySQL 5.7.

Consulte la documentación de MySQL para más información acerca de este parámetro.

Nota

En MySQL 8.0, lower_case_table_name está establecido en 1 de manera predeterminada y no se puede cambiar.

innodb_strict_mode

Si recibe un error similar a Row size too large (> 8126), considere la posibilidad de desactivar el parámetro innodb_strict_mode. No se puede modificar innodb_strict_mode globalmente en el nivel de servidor. Si el tamaño de los datos de la fila es mayor que 8000, los datos se truncan sin una notificación de error, lo que provoca una posible pérdida de datos. Es una buena idea modificar el esquema para ajustarlo al límite de tamaño de página.

Puede establecer este parámetro en el nivel de sesión mediante init_connect. Para establecer innodb_strict_mode en el nivel de sesión, consulte Ajustar parámetros que no aparecen en la lista.

Nota:

Si tiene un servidor de réplica de lectura, al establecer innodb_strict_mode en OFF en el nivel de sesión en un servidor de origen, se interrumpirá la replicación. Se recomienda mantener el parámetro establecido en ON si tiene réplicas de lectura.

sort_buffer_size

Consulte la documentación de MySQL para más información acerca de este parámetro.

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básico 1 No se puede configurar en el nivel Básico N/D N/D
Básico 2 No se puede configurar en el nivel Básico N/D N/D
Uso general 2 524 288 32 768 4 194 304
Uso general 4 524 288 32 768 8388608
Uso general 8 524 288 32 768 16777216
Uso general 16 524 288 32 768 33554432
Uso general 32 524 288 32 768 33554432
Uso general 64 524 288 32 768 33554432
Memoria optimizada 2 524 288 32 768 8388608
Memoria optimizada 4 524 288 32 768 16777216
Memoria optimizada 8 524 288 32 768 33554432
Memoria optimizada 16 524 288 32 768 33554432
Memoria optimizada 32 524 288 32 768 33554432

tmp_table_size

Consulte la documentación de MySQL para más información acerca de este parámetro.

Plan de tarifa Núcleos virtuales Valor predeterminado (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básico 1 No se puede configurar en el nivel Básico N/D N/D
Básico 2 No se puede configurar en el nivel Básico N/D N/D
Uso general 2 16777216 1024 67108864
Uso general 4 16777216 1024 134217728
Uso general 8 16777216 1024 268435456
Uso general 16 16777216 1024 536870912
Uso general 32 16777216 1024 1073741824
Uso general 64 16777216 1024 1073741824
Memoria optimizada 2 16777216 1024 134217728
Memoria optimizada 4 16777216 1024 268435456
Memoria optimizada 8 16777216 1024 536870912
Memoria optimizada 16 16777216 1024 1073741824
Memoria optimizada 32 16777216 1024 1073741824

Preparación del grupo de búferes de InnoDB

Después de reiniciar Azure Database for MySQL, se cargan las páginas de datos que residen en el disco a medida que se consultan las tablas. Esto da lugar a una mayor latencia y un rendimiento más lento para la primera ejecución de las consultas. En el caso de las cargas de trabajo sensibles a la latencia, es posible que este rendimiento más lento no sea aceptable.

Puede usar la preparación del grupo de búferes de InnoDB para acortar el período de preparación. Este proceso vuelve a cargar las páginas de disco que estaban en el grupo de búferes antes del reinicio, en lugar de esperar a que las operaciones DML o SELECT accedan a las filas correspondientes. Para más información, consulte Parámetros del servidor del grupo de búferes de InnoDB.

Sin embargo, el rendimiento mejorado se produce a costa de un tiempo de inicio más largo para el servidor. Cuando se habilita este parámetro, se espera que el tiempo de inicio y reinicio del servidor aumente en función de las IOPS aprovisionadas en dicho servidor. Es una buena idea probar y supervisar el tiempo de reinicio para garantizar que el rendimiento de inicio y reinicio es aceptable, ya que el servidor no está disponible durante ese tiempo. No utilice este parámetro cuando el número de IOPS aprovisionadas sea inferior a 1000 IOPS (en otras palabras, cuando el almacenamiento aprovisionado sea inferior a 335 GB).

Para guardar el estado del grupo de búferes al cerrar el servidor, establezca el parámetro del servidor innodb_buffer_pool_dump_at_shutdown en ON. Del mismo modo, establezca el parámetro del servidor innodb_buffer_pool_load_at_startup en ON para restaurar el estado del grupo de búferes al iniciar el servidor. Puede controlar el impacto en el inicio o reinicio si reduce y ajusta el valor del parámetro del servidor innodb_buffer_pool_dump_pct. De manera predeterminada, este parámetro está establecido en 25.

Nota

Los parámetros de preparación del grupo de búferes de InnoDB solo se admiten en servidores con almacenamiento de uso general con un almacenamiento de hasta 16 TB. Para más información, consulte las opciones de almacenamiento de Azure Database for MySQL.

time_zone

Tras la implementación inicial, un servidor que ejecuta Azure Database for MySQL incluye tablas del sistema para la información de zona horaria, pero estas tablas no se rellenan. Puede rellenar las tablas llamando al procedimiento almacenado mysql.az_load_timezone desde herramientas como la línea de comandos de MySQL o MySQL Workbench. Para obtener información sobre cómo llamar a los procedimientos almacenados y establecer las zonas horarias globales o de nivel de sesión, consulte Trabajo con el parámetro de zona horaria (Azure Portal) o Trabajo con el parámetro de zona horaria (CLI de Azure).

binlog_expire_logs_seconds

En Azure Database for MySQL, este parámetro especifica el número de segundos que el servicio espera antes de purgar el archivo del registro binario.

El registro binario contiene eventos que describen los cambios de la base de datos, como las operaciones de creación de tablas o los cambios en los datos de la tabla. También contiene eventos para las instrucciones que pueden realizar cambios potencialmente. El registro binario se usa con dos finalidades principalmente: las operaciones de replicación y de recuperación de datos.

Normalmente, los registros binarios se purgan en cuanto el manipulador queda libre del servicio, de la copia de seguridad o del conjunto de réplicas. Si hay varias réplicas, los registros binarios esperan a que la réplica más lenta lea los cambios antes de purgarse. Si desea que los registros binarios se conserven más tiempo, puede configurar el parámetro binlog_expire_logs_seconds. Si establece binlog_expire_logs_seconds en 0, que es el valor predeterminado, se purga en cuanto se libera el manipulador del registro binario. Si establece binlog_expire_logs_seconds en un valor mayor que 0, el registro binario solo se purga después de ese período de tiempo.

En Azure Database for MySQL, las características administradas, como la copia de seguridad y la purga de réplicas de lectura de archivos binarios, se controlan internamente. Si se replican los datos fuera del servicio Azure Database for MySQL, este parámetro se debe establecer en el elemento primario para evitar la purga de los registros binarios antes de que la réplica lea los cambios del elemento primario. Si establece binlog_expire_logs_seconds en un valor superior, los registros binarios no se purgarán lo suficientemente pronto. Esto puede provocar un aumento en la facturación del almacenamiento.

event_scheduler

En Azure Database for MySQL, el parámetro de servidor event_schedule administra la creación, la programación y la ejecución de eventos, es decir, las tareas que se ejecutan según una programación y se ejecutan mediante un subproceso especial del programador de eventos. Cuando el parámetro event_scheduler se establece en ON, el subproceso del programador de eventos aparece como un proceso de demonio en la salida de MOSTRAR PROCESSLIST. Puedes crear y programar eventos mediante la siguiente sintaxis 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>;

Nota

Para obtener más información sobre cómo crear un evento, consulta la documentación de Event Scheduler de MySQL aquí:

Configuración del parámetro de servidor event_scheduler

En el escenario siguiente se muestra una manera de usar el parámetro event_scheduler en Azure Database for MySQL. Para demostrar el escenario, considera el ejemplo siguiente, una tabla sencilla:

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)

Para configurar el parámetro de servidor event_scheduler en Azure Database for MySQL, realiza los pasos siguientes:

  1. En Azure Portal, ve al servidor y, después, en Configuración, selecciona Parámetros del servidor.

  2. En la hoja Parámetros del servidor, busca event_scheduler en la lista desplegable VALUE, selecciona ON y, a continuación, selecciona Guardar.

    Nota

    El cambio de configuración de parámetros del servidor dinámico se implementará sin reiniciar.

  3. A continuación, para crear un evento, conéctate al servidor MySQL y ejecuta el siguiente comando 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());

  4. Para ver los detalles de Event Scheduler, ejecute la siguiente instrucción SQL:

    SHOW EVENTS;

    Se mostrará lo siguiente:

    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)

  5. Después de unos minutos, consulte las filas de la tabla para empezar a ver las filas insertadas cada minuto según el parámetro event_scheduler que configuró:

    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)

  6. Después de una hora, ejecute una instrucción Select en la tabla para ver el resultado completo de los valores insertados en la tabla cada minuto durante una hora, ya que event_scheduler se configura en nuestro caso.

    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)

Otros escenarios

Puede configurar un evento en función de los requisitos de su escenario específico. A continuación se muestran algunos ejemplos similares de programación de instrucciones SQL para ejecutarse a intervalos de tiempo diferentes.

Ejecución de una instrucción SQL ahora y repetición una vez al día sin fin

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

Ejecución de una instrucción SQL cada hora sin fin

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

Ejecución de una instrucción SQL cada día sin fin

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>;

Parámetros no configurables del servidor

Los siguientes parámetros del servidor no se pueden configurar en el servicio:

Parámetro Valor fijo
innodb_file_per_table en el nivel básico Apagado
innodb_flush_log_at_trx_commit 1
sync_binlog 1
innodb_log_file_size 256 MB
innodb_log_files_in_group 2

Otras variables que no se muestran aquí se establecen en los valores predeterminados de MySQL. Consulte la documentación de MySQL para las versiones 8.0, 5.7 y 5.6.

Pasos siguientes