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

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

Importante

O Banco de Dados do Azure para servidor único 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 o servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

Este artigo fornece diretrizes e considerações 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 vários parâmetros e variáveis de servidor diferentes que podem ser usados para configurar e ajustar o comportamento do mecanismo. Alguns parâmetros podem ser definidos dinamicamente durante o runtime, 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 de servidor do MySQL usando o portal do Azure, a CLI do Azure e o PowerShell de acordo com as necessidades da sua carga de trabalho.

Parâmetros de servidor configuráveis

A lista de parâmetros de servidor com suporte está em constante crescimento. No portal do Azure, use a guia de parâmetros do servidor para ver a lista completa e configurar os valores desses parâmetros.

Veja as seções a seguir para saber mais sobre os limites dos parâmetros de servidor atualizados mais frequentemente. Os limites são determinados pelo tipo de preço e pelos vCores do servidor.

Pools de threads

O MySQL tradicionalmente atribui um thread para cada conexão de cliente. À medida que aumenta o número de usuários simultâneos, há uma queda correspondente no desempenho. O excesso de threads ativos pode afetar o desempenho de maneira significativa, devido a maior alternância de contexto, contenção de thread e localidade inadequada para caches de CPU.

Os pools de threads, um recurso do lado do servidor e diferentes 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 intermitência de conexões não faça com que o servidor fique sem recursos ou sem memória. Os pools de threads são mais eficientes para consultas curtas e cargas de trabalho com uso intensivo de CPU, como cargas de trabalho OLTP.

Para obter mais informações, confira Introdução aos pools de threads no Banco de Dados do Azure para MySQL.

Observação

Não há suporte para pools de threads no MySQL 5.6.

Configurar o pool de threads

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

Também é possível 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 serão reservados mesmo depois que as conexões forem fechadas.

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

Determine 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 para que outra consulta seja processada.
• thread_pool_batch_max_time: esse valor determina o tempo máximo que um thread repete o ciclo de execução da consulta e aguarda a próxima consulta.

Importante

Não ative o pool de threads em produção até que você o tenha testado.

log_bin_trust_function_creators

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

O formato do log binário é sempre LINHA, e todas as conexões com o servidor sempre usam o 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 interrompido. Portanto, você pode 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 no armazenamento de uso geral v1 (com suporte para até 4 TB)

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Basic	1	872415232	134217728	872415232
Basic	2	2684354560	134217728	2684354560
Uso Geral	2	3758096384	134217728	3758096384
Uso Geral	4	8053063680	134217728	8053063680
Uso Geral	8	16106127360	134217728	16106127360
Uso Geral	16	32749125632	134217728	32749125632
Uso Geral	32	66035122176	134217728	66035122176
Uso Geral	64	132070244352	134217728	132070244352
Otimizado para memória	2	7516192768	134217728	7516192768
Otimizado para memória	4	16106127360	134217728	16106127360
Otimizado para memória	8	32212254720	134217728	32212254720
Otimizado para memória	16	65498251264	134217728	65498251264
Otimizado para memória	32	132070244352	134217728	132070244352

Servidores no armazenamento de uso geral v2 (com suporte para até 16 TB)

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Basic	1	872415232	134217728	872415232
Basic	2	2684354560	134217728	2684354560
Uso Geral	2	7516192768	134217728	7516192768
Uso Geral	4	16106127360	134217728	16106127360
Uso Geral	8	32212254720	134217728	32212254720
Uso Geral	16	65498251264	134217728	65498251264
Uso Geral	32	132070244352	134217728	132070244352
Uso Geral	64	264140488704	134217728	264140488704
Otimizado para memória	2	15032385536	134217728	15032385536
Otimizado para memória	4	32212254720	134217728	32212254720
Otimizado para memória	8	64424509440	134217728	64424509440
Otimizado para memória	16	130996502528	134217728	130996502528
Otimizado para memória	32	264140488704	134217728	264140488704

innodb_file_per_table

O MySQL armazena a tabela InnoDB em espaços de tabela diferentes com base na configuração fornecida durante a criação da tabela. O espaço de tabela do sistema é a área de armazenamento do dicionário de dados InnoDB. Um espaço de tabela de arquivo por tabela contém dados e índices de uma só tabela InnoDB e é armazenado no sistema de arquivos em um arquivo de dados próprio.

Controle esse comportamento usando o parâmetro de servidor innodb_file_per_table. Se você definir innodb_file_per_table como OFF, isso fará com que o InnoDB crie tabelas no espaço de tabela do sistema. Caso contrário, o InnoDB criará tabelas em espaços de tabela de arquivo por tabela.

Observação

innodb_file_per_table só pode ser atualizado nos tipos de preços uso geral e otimizado para 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, no máximo, 4 TB em um arquivo de dados individual no armazenamento de uso geral v2. Se o banco de dados tiver mais de 4 TB, crie a tabela no espaço de tabela innodb_file_per_table. Se você tiver um tamanho de tabela individual maior que 4 TB, use a tabela de partição.

join_buffer_size

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

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Basic	1	Não configurável na camada básica	N/D	N/D
Basic	2	Não configurável na camada básica	N/D	N/D
Uso Geral	2	262144	128	268435455
Uso Geral	4	262144	128	536870912
Uso Geral	8	262144	128	1073741824
Uso Geral	16	262144	128	2147483648
Uso Geral	32	262144	128	4294967295
Uso Geral	64	262144	128	4294967295
Otimizado para memória	2	262144	128	536870912
Otimizado para memória	4	262144	128	1073741824
Otimizado para memória	8	262144	128	2147483648
Otimizado para memória	16	262144	128	4294967295
Otimizado para memória	32	262144	128	4294967295

max_connections

Tipo de preços	vCore(s)	Valor padrão	Valor mínimo	Valor máximo
Basic	1	50	10	50
Basic	2	100	10	100
Uso Geral	2	300	10	600
Uso Geral	4	625	10	1250
Uso Geral	8	1250	10	2500
Uso Geral	16	2500	10	5.000
Uso Geral	32	5.000	10	10000
Uso Geral	64	10000	10	20000
Otimizado para memória	2	625	10	1250
Otimizado para memória	4	1250	10	2500
Otimizado para memória	8	2500	10	5.000
Otimizado para memória	16	5.000	10	10000
Otimizado para memória	32	10000	10	20000

Quando o número de conexões exceder o limite, você poderá receber um erro.

Dica

Para gerenciar as conexões com eficiência, é uma boa ideia usar um pooler de conexão, como o ProxySQL. Para saber mais sobre como configurar o ProxySQL, confira a postagem no blog Balancear a carga de réplicas de leitura usando o ProxySQL no Banco de Dados do Azure para MySQL. Observe que o ProxySQL é uma ferramenta da comunidade de código aberto. A Microsoft dá suporte a ela com os melhores esforços.

max_heap_table_size

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

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Basic	1	Não configurável na camada básica	N/D	N/D
Basic	2	Não configurável na camada básica	N/D	N/D
Uso Geral	2	16777216	16384	268435455
Uso Geral	4	16777216	16384	536870912
Uso Geral	8	16777216	16384	1073741824
Uso Geral	16	16777216	16384	2147483648
Uso Geral	32	16777216	16384	4294967295
Uso Geral	64	16777216	16384	4294967295
Otimizado para memória	2	16777216	16384	536870912
Otimizado para memória	4	16777216	16384	1073741824
Otimizado para memória	8	16777216	16384	2147483648
Otimizado para memória	16	16777216	16384	4294967295
Otimizado para memória	32	16777216	16384	4294967295

query_cache_size

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

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

Observação

O cache de consulta foi preterido desde o MySQL 5.7.20 e foi removido no MySQL 8.0.

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo
Basic	1	Não configurável na camada básica	N/D	N/D
Basic	2	Não configurável na camada básica	N/D	N/D
Uso Geral	2	0	0	16777216
Uso Geral	4	0	0	33554432
Uso Geral	8	0	0	67108864
Uso Geral	16	0	0	134217728
Uso Geral	32	0	0	134217728
Uso Geral	64	0	0	134217728
Otimizado para memória	2	0	0	33554432
Otimizado para memória	4	0	0	67108864
Otimizado para memória	8	0	0	134217728
Otimizado para memória	16	0	0	134217728
Otimizado para memória	32	0	0	134217728

lower_case_table_names

Por padrão, o parâmetro lower_case_table_name está definido como 1 e pode ser atualizado no MySQL 5.6 e 5.7.

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

Observação

No MySQL 8,0, lower_case_table_name está definido como 1 por padrão e não pode ser alterado.

innodb_strict_mode

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

Defina 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, veja Como definir um parâmetro não listado.

Observação

Caso você tenha um servidor de réplica de leitura, a replicação é interrompida se innodb_strict_mode é definido como OFF no nível de sessão em um servidor de origem. Sugerimos manter o parâmetro definido como ON caso você tenha réplicas de leitura.

sort_buffer_size

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

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Basic	1	Não configurável na camada básica	N/D	N/D
Basic	2	Não configurável na camada básica	N/D	N/D
Uso Geral	2	524288	32768	4194304
Uso Geral	4	524288	32768	8388608
Uso Geral	8	524288	32768	16777216
Uso Geral	16	524288	32768	33554432
Uso Geral	32	524288	32768	33554432
Uso Geral	64	524288	32768	33554432
Otimizado para memória	2	524288	32768	8388608
Otimizado para memória	4	524288	32768	16777216
Otimizado para memória	8	524288	32768	33554432
Otimizado para memória	16	524288	32768	33554432
Otimizado para memória	32	524288	32768	33554432

tmp_table_size

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

Tipo de preços	vCore(s)	Valor padrão (bytes)	Valor mínimo (bytes)	Valor máximo (bytes)
Basic	1	Não configurável na camada básica	N/D	N/D
Basic	2	Não configurável na camada básica	N/D	N/D
Uso Geral	2	16777216	1024	67108864
Uso Geral	4	16777216	1024	134217728
Uso Geral	8	16777216	1024	268435456
Uso Geral	16	16777216	1024	536870912
Uso Geral	32	16777216	1024	1073741824
Uso Geral	64	16777216	1024	1073741824
Otimizado para memória	2	16777216	1024	134217728
Otimizado para memória	4	16777216	1024	268435456
Otimizado para memória	8	16777216	1024	536870912
Otimizado para memória	16	16777216	1024	1073741824
Otimizado para memória	32	16777216	1024	1073741824

Aquecimento do pool de buffers do InnoDB

Depois que você reiniciar o Banco de Dados do Azure para MySQL, as páginas de dados que residem no disco serão carregadas, conforme as tabelas forem consultadas. Isso resulta no aumento da latência e reduz o desempenho na primeira execução das consultas. Para cargas de trabalho que são sensíveis à latência, você pode achar esse desempenho mais lento inaceitável.

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

No entanto, observe que o melhor desempenho ocorre às custas de um tempo de inicialização mais longo do servidor. Quando você habilita esse parâmetro, é esperado que os tempos de inicialização e reinicialização do servidor aumentem de acordo com a IOPS provisionada no servidor. É uma boa ideia testar e monitorar o tempo de reinicialização para garantir que o desempenho de inicialização ou de reinicialização seja aceitável, pois o servidor ficará indisponível durante esse tempo. Não use esse parâmetro quando o número de IOPS provisionados for menor que 1000 IOPS (ou seja, quando o armazenamento provisionado for menor que 335 GB).

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

Observação

Só há suporte para os parâmetros de aquecimento do pool de buffers do InnoDB em servidores de armazenamento de uso geral com até 16 TB de armazenamento. Para obter mais informações, confira Opções de armazenamento do Banco de Dados do Azure para MySQL.

time_zone

Após a implantação inicial, um servidor que executa o Banco de Dados do Azure para MySQL inclui tabelas do sistema para informações de fuso horário, embora essas tabelas não estejam preenchidas. Você pode preencher as tabelas chamando o procedimento armazenado mysql.az_load_timezone em ferramentas como a linha de comando do MySQL ou o 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, confira Como trabalhar com o parâmetro de fuso horário (portal do Azure) ou Como trabalhar 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 os eventos que descrevem as alterações no banco de dados, como operações de criação de tabela ou alterações em dados de tabela. Ele também contém eventos para instruções que podem fazer alterações. O log binário é usado principalmente para duas finalidades: operações de replicação e de recuperação de dados.

Normalmente, os logs binários são limpos assim que o identificador fica livre do serviço, de backup ou do conjunto de réplicas. Se houver várias réplicas, os logs binários aguardam a réplica mais lenta ler as alterações antes de ser limpa. Caso deseje que os logs binários persistam mais, configure 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 do log binário for liberado. Se você definir binlog_expire_logs_seconds com um valor maior que 0, o log binário só será limpo após esse período.

Para o Banco de Dados do Azure para MySQL, os recursos gerenciados como backup e limpeza de réplica de leitura de arquivos binários são processados internamente. Quando você replica os dados para fora do serviço Banco de Dados do Azure para MySQL, defina esse parâmetro no primário para evitar a limpeza dos logs binários antes que a réplica leia as alterações do primário. Se você definir o binlog_expire_logs_seconds com um valor mais alto, os logs binários não serão limpos em tempo hábil. Isso pode resultar em um aumento na fatura de armazenamento.

event_scheduler

No Banco de Dados do Azure para MySQL, o parâmetro de servidor event_schedule gerencia a criação, o agendamento e a execução de eventos, ou seja, tarefas executadas de acordo com um agendamento, e elas são executadas por um thread do agendador de eventos especial. Quando o parâmetro event_scheduler é definido como ON, o 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>;

Observação

Para obter mais informações sobre como criar um evento, confira a documentação do Event Scheduler do MySQL aqui:

• MySQL :: Manual de Referência do MySQL 5.7 :: 23.4 Usando o Event Scheduler
• MySQL :: Manual de Referência do MySQL 8.0 :: 25.4 Usando o Event Scheduler

Configurando o parâmetro de servidor event_scheduler

O cenário a seguir ilustra uma maneira de usar o parâmetro event_scheduler no Banco de Dados do Azure para MySQL. Para demonstrar o cenário, considere o exemplo a seguir, 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 parâmetro de servidor event_scheduler 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 VALUE, selecione ON e, em seguida, escolha Salvar.

   Observação

   A alteração de configuração do parâmetro de servidor dinâmico 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;
   

   O seguinte resultado é exibido:

   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 exibir as linhas inseridas a cada minuto de acordo com o parâmetro event_scheduler configurado:

   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 exibir o resultado completo dos valores inseridos na tabela a cada minuto durante uma hora, pois o event_scheduler é configurado em 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 de seu cenário específico. A seguir, alguns exemplos semelhantes de agendamento de instruções SQL para execução em intervalos de tempo diferentes.

Executar uma instrução SQL agora e repetir 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>;

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

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

Executar 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 na camada básica	OFF
innodb_flush_log_at_trx_commit	1
sync_binlog	1
innodb_log_file_size	256 MB
innodb_log_files_in_group	2

Outras variáveis não listadas aqui são definidas com os valores padrão do MySQL. Veja a documentação do MySQL das versões 8.0, 5.7 e 5.6.

Próximas etapas

• Saiba como configurar parâmetros de servidor usando o portal do Azure
• Saiba como configurar parâmetros de servidor usando a CLI do Azure
• Saiba como configurar parâmetros de servidor usando o PowerShell