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 servidor único do Banco de Dados do Azure para MySQL está no caminho da desativação. É altamente recomendável que você atualize para o servidor flexível do Banco de Dados do Azure para MySQL. Para obter mais informações sobre a migração para o servidor flexível do Banco de Dados do Azure para MySQL, confira O que está acontecendo com o Servidor Único do Banco de Dados do Azure para 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:
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:
No portal do Azure, navegue até o servidor e, em Configurações, selecione Parâmetros do servidor.
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.
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());
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)
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)
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.