Parâmetros de servidor no Banco de Dados do Azure para MySQL

  • Artigo

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

Este artigo fornece considerações e diretrizes para configurar parâmetros de servidor no Banco de Dados do Azure para MySQL.

O que são parâmetros de servidor?

O mecanismo MySQL fornece muitas variáveis de servidor diferentes e parâmetros que você usa para configurar e ajustar o comportamento do mecanismo. Alguns parâmetros podem ser definidos dinamicamente durante o tempo de execução, enquanto outros são estáticos e exigem uma reinicialização do servidor para serem aplicados.

O Banco de Dados do Azure para MySQL expõe a capacidade de alterar o valor de vários parâmetros do servidor MySQL usando o portal do Azure, a CLI do Azure e o PowerShell para atender às necessidades da sua carga de trabalho.

Parâmetros configuráveis do servidor

A lista de parâmetros de servidor suportados está em constante crescimento. No portal do Azure, use a guia Parâmetros do servidor para exibir a lista completa e configurar os valores dos parâmetros do servidor.

Consulte as seções a seguir para saber mais sobre os limites de vários parâmetros de servidor comumente atualizados. Os limites são determinados pela camada de preço e vCores do servidor.

Pools de threads

O MySQL tradicionalmente atribui um thread para cada conexão de cliente. À medida que o número de usuários simultâneos cresce, há uma queda correspondente no desempenho. Muitos threads ativos podem afetar o desempenho significativamente, devido ao aumento da alternância de contexto, contenção de threads e localização incorreta para caches de CPU.

Os pools de threads, um recurso do lado do servidor e distinto do pool de conexões, maximizam o desempenho introduzindo um pool dinâmico de threads de trabalho. Use esse recurso para limitar o número de threads ativos em execução no servidor e minimizar a rotatividade de threads. Isso ajuda a garantir que uma explosão de conexões não faça com que o servidor fique sem recursos ou memória. Os pools de threads são mais eficientes para consultas curtas e cargas de trabalho intensivas de CPU, como cargas de trabalho OLTP.

Para obter mais informações, consulte Apresentando pools de threads no Banco de Dados do Azure para MySQL.

Nota

Os pools de threads não são suportados para o MySQL 5.6.

Configurar o pool de threads

Para habilitar um pool de threads, atualize o thread_handling parâmetro server para pool-of-threads. Por padrão, esse parâmetro é definido como , o que significa que o one-thread-per-connectionMySQL cria um novo thread para cada nova conexão. Este é um parâmetro estático e requer uma reinicialização do servidor para ser aplicado.

Você também pode configurar o número máximo e mínimo de threads no pool definindo os seguintes parâmetros de servidor:

  • thread_pool_max_threads: Este valor limita o número de threads no pool.
  • thread_pool_min_threads: Este valor define o número de threads que são reservados, mesmo depois que as conexões são fechadas.

Para melhorar os problemas de desempenho de consultas curtas no pool de threads, você pode habilitar a execução em lote. Em vez de retornar ao pool de threads imediatamente após executar uma consulta, os threads permanecerão ativos por um curto período de tempo para aguardar a próxima consulta por meio dessa conexão. Em seguida, o thread executa a consulta rapidamente e, quando isso é concluído, o thread aguarda o próximo. Este processo continua até que o tempo total gasto exceda um limite.

Você determina o comportamento da execução em lote usando os seguintes parâmetros de servidor:

  • thread_pool_batch_wait_timeout: Este valor especifica o tempo que um thread aguarda o processamento de outra consulta.
  • thread_pool_batch_max_time: Esse valor determina o tempo máximo que um thread repetirá o ciclo de execução da consulta e aguardará a próxima consulta.

Importante

Não ligue o pool de threads na produção até testá-lo.

log_bin_trust_function_creators

No Banco de Dados do Azure para MySQL, os logs binários são sempre habilitados (o log_bin parâmetro é definido como ON). Se você quiser usar gatilhos, você receberá um erro semelhante ao seguinte: Você não tem o privilégio SUPER e o log binário está habilitado (você pode querer usar a variável menos segura log_bin_trust_function_creators ).

O formato de log binário é sempre ROW, e todas as conexões com o servidor sempreusam log binário baseado em linha. O log binário baseado em linha ajuda a manter a segurança, e o log binário não pode ser quebrado, para que você possa definir log_bin_trust_function_creators com segurança como TRUE.

innodb_buffer_pool_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Servidores em armazenamento de uso geral v1 (suportando até 4 TB)

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básica 5 872415232 134217728 872415232
Básica 2 2684354560 134217728 2684354560
Fins Gerais 2 3758096384 134217728 3758096384
Fins Gerais 4 8053063680 134217728 8053063680
Fins Gerais 8 16106127360 134217728 16106127360
Fins Gerais 16 32749125632 134217728 32749125632
Fins Gerais 32 66035122176 134217728 66035122176
Fins Gerais 64 132070244352 134217728 132070244352
Otimizada para Memória 2 7516192768 134217728 7516192768
Otimizada para Memória 4 16106127360 134217728 16106127360
Otimizada para Memória 8 32212254720 134217728 32212254720
Otimizada para Memória 16 65498251264 134217728 65498251264
Otimizada para Memória 32 132070244352 134217728 132070244352

Servidores em armazenamento de uso geral v2 (suportando até 16 TB)

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básica 5 872415232 134217728 872415232
Básica 2 2684354560 134217728 2684354560
Fins Gerais 2 7516192768 134217728 7516192768
Fins Gerais 4 16106127360 134217728 16106127360
Fins Gerais 8 32212254720 134217728 32212254720
Fins Gerais 16 65498251264 134217728 65498251264
Fins Gerais 32 132070244352 134217728 132070244352
Fins Gerais 64 264140488704 134217728 264140488704
Otimizada para Memória 2 15032385536 134217728 15032385536
Otimizada para Memória 4 32212254720 134217728 32212254720
Otimizada para Memória 8 64424509440 134217728 64424509440
Otimizada para Memória 16 130996502528 134217728 130996502528
Otimizada para Memória 32 264140488704 134217728 264140488704

innodb_file_per_table

O MySQL armazena a tabela em diferentes espaços de tabela, com base na configuração que você fornece durante a InnoDB criação da tabela. O espaço de tabela do sistema é a área de armazenamento para o dicionário de InnoDB dados. Um espaço de tabela de arquivo por tabela contém dados e índices para uma única InnoDB tabela e é armazenado no sistema de arquivos em seu próprio arquivo de dados.

Você controla esse comportamento usando o innodb_file_per_table parâmetro server. Configuração innodb_file_per_table para causas InnoDB para OFF criar tabelas no espaço de tabela do sistema. Caso contrário, InnoDB cria tabelas em espaços de tabela de arquivo por tabela.

Nota

Você só pode atualizar innodb_file_per_table os níveis de preços otimizados para fins gerais e memória no armazenamento de uso geral v2 e no armazenamento de uso geral v1.

O Banco de Dados do Azure para MySQL dá suporte a 4 TB (no maior) em um único arquivo de dados no armazenamento de uso geral v2. Se o tamanho do banco de dados for maior que 4 TB, você deverá criar a tabela no espaço de tabela innodb_file_per_table . Se você tiver um único tamanho de tabela maior que 4 TB, deverá usar a tabela de partição.

join_buffer_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básica 5 Não configurável na camada Básica N/A N/A
Básica 2 Não configurável na camada Básica N/A N/A
Fins Gerais 2 262144 128 268435455
Fins Gerais 4 262144 128 536870912
Fins Gerais 8 262144 128 1073741824
Fins Gerais 16 262144 128 2147483648
Fins Gerais 32 262144 128 4294967295
Fins Gerais 64 262144 128 4294967295
Otimizada para Memória 2 262144 128 536870912
Otimizada para Memória 4 262144 128 1073741824
Otimizada para Memória 8 262144 128 2147483648
Otimizada para Memória 16 262144 128 4294967295
Otimizada para Memória 32 262144 128 4294967295

max_connections

Escalão de preço vCore(s) Valor predefinido Valor mínimo Valor máximo
Básica 5 50 10 50
Básica 2 100 10 100
Fins Gerais 2 400 10 600
Fins Gerais 4 625 10 1250
Fins Gerais 8 1250 10 2500
Fins Gerais 16 2500 10 5000
Fins Gerais 32 5000 10 10000
Fins Gerais 64 10000 10 20 000
Otimizada para Memória 2 625 10 1250
Otimizada para Memória 4 1250 10 2500
Otimizada para Memória 8 2500 10 5000
Otimizada para Memória 16 5000 10 10000
Otimizada para Memória 32 10000 10 20 000

Quando o número de conexões excede o limite, você pode receber um erro.

Gorjeta

Para gerenciar conexões de forma eficiente, é uma boa ideia usar um pool de conexões, como o ProxySQL. Para saber mais sobre como configurar o ProxySQL, consulte a postagem do blog Réplicas de leitura de balanceamento de carga usando ProxySQL no Banco de Dados do Azure para MySQL. Observe que o ProxySQL é uma ferramenta de comunidade de código aberto. É suportado pela Microsoft com base no melhor esforço.

max_heap_table_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básica 5 Não configurável na camada Básica N/A N/A
Básica 2 Não configurável na camada Básica N/A N/A
Fins Gerais 2 16777216 16384 268435455
Fins Gerais 4 16777216 16384 536870912
Fins Gerais 8 16777216 16384 1073741824
Fins Gerais 16 16777216 16384 2147483648
Fins Gerais 32 16777216 16384 4294967295
Fins Gerais 64 16777216 16384 4294967295
Otimizada para Memória 2 16777216 16384 536870912
Otimizada para Memória 4 16777216 16384 1073741824
Otimizada para Memória 8 16777216 16384 2147483648
Otimizada para Memória 16 16777216 16384 4294967295
Otimizada para Memória 32 16777216 16384 4294967295

query_cache_size

O cache de consulta está desativado por padrão. Para habilitar o cache de consulta, configure o query_cache_type parâmetro.

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Nota

O cache de consultas foi preterido a partir do MySQL 5.7.20 e foi removido no MySQL 8.0.

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo
Básica 5 Não configurável na camada Básica N/A N/A
Básica 2 Não configurável na camada Básica N/A N/A
Fins Gerais 2 0 0 16777216
Fins Gerais 4 0 0 33554432
Fins Gerais 8 0 0 67108864
Fins Gerais 16 0 0 134217728
Fins Gerais 32 0 0 134217728
Fins Gerais 64 0 0 134217728
Otimizada para Memória 2 0 0 33554432
Otimizada para Memória 4 0 0 67108864
Otimizada para Memória 8 0 0 134217728
Otimizada para Memória 16 0 0 134217728
Otimizada para Memória 32 0 0 134217728

lower_case_table_names

O lower_case_table_name parâmetro é definido como 1 por padrão, e você pode atualizar esse parâmetro no MySQL 5.6 e MySQL 5.7.

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Nota

No MySQL 8.0, é definido como 1 por padrão, lower_case_table_name e você não pode alterá-lo.

innodb_strict_mode

Se você receber um erro semelhante ao Row size too large (> 8126), considere desativar o innodb_strict_mode parâmetro. Não é possível modificar innodb_strict_mode globalmente no nível do servidor. Se o tamanho dos dados da linha for maior que 8K, os dados serão truncados, sem uma notificação de erro, levando à perda potencial de dados. É uma boa ideia modificar o esquema para se ajustar ao limite de tamanho da página.

Você pode definir esse parâmetro em um nível de sessão, usando init_connect. Para definir innodb_strict_mode em um nível de sessão, consulte o parâmetro de configuração não listado.

Nota

Se você tiver um servidor de réplica de leitura, a configuração innodb_strict_mode como OFF no nível da sessão em um servidor de origem interromperá a replicação. Sugerimos manter o parâmetro definido para ON se você tiver réplicas de leitura.

sort_buffer_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básica 5 Não configurável na camada Básica N/A N/A
Básica 2 Não configurável na camada Básica N/A N/A
Fins Gerais 2 524288 32768 4194304
Fins Gerais 4 524288 32768 8388608
Fins Gerais 8 524288 32768 16777216
Fins Gerais 16 524288 32768 33554432
Fins Gerais 32 524288 32768 33554432
Fins Gerais 64 524288 32768 33554432
Otimizada para Memória 2 524288 32768 8388608
Otimizada para Memória 4 524288 32768 16777216
Otimizada para Memória 8 524288 32768 33554432
Otimizada para Memória 16 524288 32768 33554432
Otimizada para Memória 32 524288 32768 33554432

tmp_table_size

Consulte a documentação do MySQL para saber mais sobre esse parâmetro.

Escalão de preço vCore(s) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Básica 5 Não configurável na camada Básica N/A N/A
Básica 2 Não configurável na camada Básica N/A N/A
Fins Gerais 2 16777216 1024 67108864
Fins Gerais 4 16777216 1024 134217728
Fins Gerais 8 16777216 1024 268435456
Fins Gerais 16 16777216 1024 536870912
Fins Gerais 32 16777216 1024 1073741824
Fins Gerais 64 16777216 1024 1073741824
Otimizada para Memória 2 16777216 1024 134217728
Otimizada para Memória 4 16777216 1024 268435456
Otimizada para Memória 8 16777216 1024 536870912
Otimizada para Memória 16 16777216 1024 1073741824
Otimizada para Memória 32 16777216 1024 1073741824

Aquecimento do pool de buffer InnoDB

Depois de reiniciar o Banco de Dados do Azure para MySQL, as páginas de dados que residem no disco são carregadas, à medida que as tabelas são consultadas. Isso leva a uma maior latência e a um desempenho mais lento para a primeira execução das consultas. Para cargas de trabalho sensíveis à latência, você pode achar esse desempenho mais lento inaceitável.

Você pode usar InnoDB o aquecimento do pool de buffer para encurtar o período de aquecimento. Esse processo recarrega páginas de disco que estavam no pool de buffers antes da reinicialização, em vez de aguardar as operações DML ou SELECT para acessar as linhas correspondentes. Para obter mais informações, consulte Parâmetros do servidor do pool de buffers InnoDB.

No entanto, o desempenho melhorado é feito à custa de um tempo de arranque mais longo para o servidor. Quando você habilita esse parâmetro, espera-se que os tempos de inicialização e reinicialização do servidor aumentem, dependendo das IOPS provisionadas no servidor. É uma boa ideia testar e monitorar o tempo de reinicialização, para garantir que o desempenho de inicialização ou reinicialização seja aceitável, porque o servidor não está disponível durante esse tempo. Não use esse parâmetro quando o número de IOPS provisionadas for inferior a 1000 IOPS (em outras palavras, quando o armazenamento provisionado for inferior a 335 GB).

Para salvar o estado do pool de buffers no desligamento do servidor, defina o parâmetro innodb_buffer_pool_dump_at_shutdown server como ON. Da mesma forma, defina o parâmetro innodb_buffer_pool_load_at_startup server para ON restaurar o estado do pool de buffers na inicialização do servidor. Você pode controlar o impacto na inicialização ou reinicialização reduzindo e ajustando o valor do parâmetro innodb_buffer_pool_dump_pctserver. Por padrão, esse parâmetro é definido como 25.

Nota

InnoDB Os parâmetros de aquecimento do pool de buffers são suportados apenas em servidores de armazenamento de uso geral com armazenamento de até 16 TB. Para obter mais informações, consulte Banco de Dados do Azure para opções de armazenamento MySQL.

time_zone

Após a implantação inicial, um servidor que executa o Banco de Dados do Azure para MySQL inclui tabelas de sistemas para informações de fuso horário, mas essas tabelas não são preenchidas. Você pode preencher as tabelas chamando o procedimento armazenado de ferramentas como a linha de comando MySQL ou o mysql.az_load_timezone MySQL Workbench. Para obter informações sobre como chamar os procedimentos armazenados e definir os fusos horários globais ou de nível de sessão, consulte Trabalhando com o parâmetro de fuso horário (portal do Azure) ou Trabalhando com o parâmetro de fuso horário (CLI do Azure).

binlog_expire_logs_seconds

No Banco de Dados do Azure para MySQL, esse parâmetro especifica o número de segundos que o serviço aguarda antes de limpar o arquivo de log binário.

O log binário contém eventos que descrevem alterações no banco de dados, como operações de criação de tabela ou alterações nos dados da tabela. Ele também contém eventos para instruções que podem potencialmente fazer alterações. O log binário é usado principalmente para duas finalidades, replicação e operações de recuperação de dados.

Normalmente, os logs binários são limpos assim que o identificador está livre do serviço, do backup ou do conjunto de réplicas. Se houver várias réplicas, os logs binários aguardam que a réplica mais lenta leia as alterações antes de serem limpas. Se desejar que os logs binários persistam por mais tempo, você pode configurar o parâmetro binlog_expire_logs_seconds. Se você definir binlog_expire_logs_seconds como 0, que é o valor padrão, ele será limpo assim que o identificador para o log binário for liberado. Se você definir binlog_expire_logs_seconds como maior que 0, o log binário só será limpo após esse período de tempo.

Para o Banco de Dados do Azure para MySQL, recursos gerenciados, como backup e limpeza de réplica de leitura de arquivos binários, são manipulados internamente. Ao replicar os dados do serviço Banco de Dados do Azure para MySQL, você deve definir esse parâmetro no primário para evitar a limpeza de logs binários antes que a réplica leia as alterações do primário. Se você definir o para um valor mais alto, os logs binários não serão limpos logo o binlog_expire_logs_seconds suficiente. Isso pode levar a um aumento no faturamento do armazenamento.

event_scheduler

No Banco de Dados do Azure para MySQL, o parâmetro de servidor gerencia a criação, o agendamento e a event_schedule execução de eventos, ou seja, tarefas que são executadas de acordo com uma programação e são executadas por um thread especial do agendador de eventos. Quando o parâmetro é definido como ON, o event_scheduler thread do agendador de eventos é listado como um processo de daemon na saída de SHOW PROCESSLIST. Você pode criar e agendar eventos usando a seguinte sintaxe 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 obter mais informações sobre como criar um evento, consulte a documentação do MySQL Event Scheduler aqui:

Configurando o parâmetro event_scheduler server

O cenário a seguir ilustra uma maneira de usar o event_scheduler parâmetro no Banco de Dados do Azure para MySQL. Para demonstrar o cenário, considere o seguinte exemplo, uma tabela simples:

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 o event_scheduler parâmetro server no Banco de Dados do Azure para MySQL, execute as seguintes etapas:

  1. No portal do Azure, navegue até o servidor e, em Configurações, selecione Parâmetros do servidor.

  2. Na folha Parâmetros do servidor, procure event_scheduler, na lista suspensa VALOR, selecione ATIVADO e, em seguida, selecione Salvar.

    Nota

    A alteração de configuração do parâmetro dinâmico do servidor será implantada sem uma reinicialização.

  3. Em seguida, para criar um evento, conecte-se ao servidor MySQL e execute o seguinte 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 exibir os detalhes do Agendador de Eventos, execute a seguinte instrução SQL:

    SHOW EVENTS;

    É apresentada a seguinte saída:

    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. Após alguns minutos, consulte as linhas da tabela para começar a visualizar as linhas inseridas a cada minuto de acordo com o event_scheduler parâmetro que você configurou:

    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. Após uma hora, execute uma instrução Select na tabela para visualizar o resultado completo dos valores inseridos na tabela a cada minuto durante uma hora, conforme configurado event_scheduler no nosso 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)

Outros cenários

Você pode configurar um evento com base nos requisitos do seu cenário específico. Seguem-se alguns exemplos semelhantes de agendamento de instruções SQL para execução em intervalos de tempo diferentes.

Execute uma instrução SQL agora e repita uma vez por dia sem fim

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

Execute uma instrução SQL a cada hora sem fim

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

Execute uma instrução SQL todos os dias sem fim

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 de servidor não configuráveis

Os seguintes parâmetros de servidor não são configuráveis no serviço:

Parâmetro Valor fixo
innodb_file_per_table no nível básico OFF
innodb_flush_log_at_trx_commit 1
sync_binlog 1
innodb_log_file_size 256MB
innodb_log_files_in_group 2

Outras variáveis não listadas aqui são definidas para os valores padrão do MySQL. Consulte os documentos do MySQL para as versões 8.0, 5.7 e 5.6.

Próximos passos