Compartilhar via

Parâmetros do servidor no Banco de Dados do Azure para MySQL – Servidor Flexível

  • Artigo

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

Observação

Esse artigo contém referências ao termo escravo, que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

O que são parâmetros de servidor?

O mecanismo MySQL fornece muitos parâmetros de servidor (também chamados de variáveis) que você pode usar para configurar e ajustar o comportamento do mecanismo. Alguns parâmetros podem ser definidos dinamicamente durante o tempo de execução. Outros são estáticos e exigem a reinicialização do servidor após serem definidos.

No Banco de Dados do Azure para MySQL - Servidor flexível, é possível alterar o valor de vários parâmetros do servidor do MySQL usando Configurar parâmetros do servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando o portal do Azure e Configurar parâmetros do servidor no Banco de Dados do Azure para MySQL - Servidor Flexível usando a CLI do Azure para atender às suas necessidades de carga de trabalho.

Parâmetros de servidor configuráveis

Você pode gerenciar a configuração de um Servidor Flexível do Banco de Dados do Azure para MySQL usando parâmetros de servidor. Os parâmetros do servidor são configurados com os valores padrão e recomendados quando você cria o servidor. O painel Parâmetros do servidor no portal do Azure mostra os parâmetros modificáveis ​​e não modificáveis. Os parâmetros do servidor não modificáveis ​​não estão disponíveis.

A lista de parâmetros de servidor com suporte está em constante crescimento. Você pode usar o portal do Azure para visualizar periodicamente a lista completa de parâmetros do servidor e configurar os valores.

Se você modificar um parâmetro estático do servidor usando o portal, será necessário reiniciar o servidor para que as alterações entrem em vigor. Se você estiver usando scripts de automação (por meio de ferramentas como modelos do Azure Resource Manager, Terraform ou CLI do Azure), seu script deverá ter uma provisão para reiniciar o serviço para que as configurações entrem em vigor, mesmo se você estiver alterando a configuração como parte da experiência de criação.

Se você quiser modificar um parâmetro de servidor não modificável para seu ambiente, publique uma ideia por meio do feedback da comunidade ou vote se o feedback já existir (o que pode nos ajudar a priorizar).

As seções a seguir descrevem os limites dos parâmetros do servidor comumente atualizados. A camada de computação e o tamanho (vCores) do servidor determinam os limites.

lower_case_table_names

Para o MySQL versão 5.7, o valor padrão de lower_case_table_names é 1 no Banco de Dados do Azure para MySQL - Servidor Flexível. Embora seja possível alterar o valor suportado para 2, reverter de 2 para 1 não é permitido. Para obter assistência na alteração do valor padrão, crie um tíquete de suporte.

Para MySQL versão 8.0+ você pode configurar lower_case_table_names somente quando estiver inicializando o servidor. Saiba mais. É proibido alterar a configuração lower_case_table_names após a inicialização do servidor.

Os valores suportados para o MySQL versão 8.0 são 1 e 2 no Banco de Dados do Azure para MySQL - Servidor Flexível. O valor padrão é 1. Para obter assistência na alteração do valor padrão durante a criação do servidor, crie um tíquete de suporte.

innodb_tmpdir

Use o parâmetro innodb_tmpdir no Banco de Dados do Azure para MySQL - Servidor Flexível para definir o diretório para arquivos de classificação temporários criados durante operações online ALTER TABLE que são reconstruídas.

O valor padrão de innodb_tmpdir é /mnt/temp. Esse local corresponde ao armazenamento temporário (SSD) e está disponível em gibibytes (GiB) com cada tamanho de computação do servidor. Esse local é ideal para operações que não exigem muito espaço.

Se precisar de mais espaço, você pode definir innodb_tmpdir como /app/work/tmpdir. Essa configuração utiliza a capacidade de armazenamento disponível no seu Servidor Flexível do Banco de Dados do Azure para MySQL. Essa configuração pode ser útil para operações maiores que exigem mais armazenamento temporário.

Tenha em mente que usar /app/work/tmpdir resulta em desempenho mais lento em comparação ao valor de armazenamento temporário (SSD) /mnt/temp padrão. Faça a escolha com base nos requisitos específicos das operações.

As informações fornecidas para innodb_tmpdir são aplicáveis ​​aos parâmetros innodb_temp_tablespaces_dir, tmpdir e slave_load_tmpdir onde:

  • O valor padrão /mnt/temp é comum.
  • O diretório alternativo /app/work/tmpdir está disponível para configurar armazenamento temporário aumentado, com uma compensação no desempenho com base em requisitos operacionais específicos.

log_bin_trust_function_creators

No Banco de Dados do Azure para MySQL - Servidor Flexível, os logs binários estão sempre habilitados (ou seja, log_bin é definido como ON). O parâmetro log_bin_trust_function_creators é definido como ON por padrão em servidor flexível.

O formato de registro binário é sempre ROW e as conexões com o servidor sempre usam registro binário baseado em linha. Com o registro binário baseado em linha, não existem problemas de segurança e o registro binário não pode ser interrompido, então você pode permitir com segurança que log_bin_trust_function_creators permaneça como ON.

Se log_bin_trust_function_creators estiver definido como OFF e você tentar criar gatilhos, poderá receber erros semelhantes a: "Você não tem o privilégio SUPER e o registro binário está habilitado (talvez você queira usar a variável log_bin_trust_function_creators, menos segura)."

innodb_buffer_pool_size

Para saber mais sobre o parâmetro innodb_buffer_pool_size, revise a documentação do MySQL.

O tamanho da memória física na tabela a seguir representa a memória de acesso aleatório (RAM) disponível, em gigabytes (GB), no seu Servidor Flexível do Banco de Dados do Azure para MySQL.

Tamanho da computação vCores Tamanho da memória física (GB) Valor padrão (bytes) Valor mínimo (bytes) Valor máximo (bytes)
Com capacidade de intermitência
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Uso Geral
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
Comercialmente Crítico
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

innodb_file_per_table

O MySQL armazena a tabela InnoDB em diferentes tablespaces com base na configuração que você forneceu durante a criação da tabela. O espaço de tabela do sistema é a área de armazenamento do dicionário de dados InnoDB. Um tablespace de arquivo por tabela contém dados e índices para uma única tabela InnoDB e é armazenado no sistema de arquivos em seu próprio arquivo de dados. O parâmetro do servidor innodb_file_per_table controla esse comportamento.

Definir innodb_file_per_table como OFF faz com que o InnoDB crie tabelas no espaço de tabela do sistema. Caso contrário, o InnoDB cria tabelas em espaços de tabela de arquivo por tabela.

O Banco de Dados do Azure para MySQL - Servidor Flexível suporta no máximo 8 terabytes (TB) em um único arquivo de dados. Se o tamanho do seu banco de dados for maior que 8 TB, você deverá criar a tabela no tablespace innodb_file_per_table. Se você tiver um tamanho de tabela único maior que 8 TB, deverá usar a tabela de partição.

innodb_log_file_size

O valor de innodb_log_file_size é o tamanho (em bytes) de cada arquivo de log em um grupo de log. O tamanho combinado dos arquivos de log (innodb_log_file_size * innodb_log_files_in_group) não pode exceder um valor máximo ligeiramente inferior a 512 GB.

Um tamanho de arquivo de log maior é melhor para o desempenho, mas a desvantagem é que o tempo de recuperação após uma falha é alto. Você precisa equilibrar o tempo de recuperação para o evento raro de uma falha e maximizar a taxa de transferência durante as operações de pico. Um tamanho de arquivo de log maior também pode resultar em tempos de reinicialização mais longos.

Você pode configurar innodb_log_size para 256 megabytes (MB), 512 MB, 1 GB ou 2 GB para o Banco de Dados do Azure para MySQL - Servidor Flexível. O parâmetro é estático e requer uma reinicialização.

Observação

Se você alterou o parâmetro innodb_log_file_size do padrão, verifique se o valor de show global status like 'innodb_buffer_pool_pages_dirty' permanece em 0 por 30 segundos para evitar atraso na reinicialização.

max_connections

O tamanho da memória do servidor determina o valor de max_connections. O tamanho da memória física na tabela a seguir representa a RAM disponível, em gigabytes, no seu Servidor Flexível do Banco de Dados do Azure para MySQL.

Tamanho da computação vCores Tamanho da memória física (GB) Valor padrão Valor mínimo Valor máximo
Com capacidade de intermitência
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Uso Geral
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
Comercialmente Crítico
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

Quando as conexões excedem o limite, você pode receber o seguinte erro: "ERROR 1040 (08004): Muitas conexões."

Criar novas conexões de clientes com o MySQL leva tempo. Depois de estabelecer essas conexões, elas ocupam recursos do banco de dados, mesmo quando estão ociosas. A maioria dos aplicativos solicita muitas conexões de curta duração, o que agrega a essa situação. O resultado é menos recursos disponíveis para sua carga de trabalho real, levando à redução do desempenho.

Um pooler de conexões que diminui as conexões ociosas e reutiliza as conexões existentes ajuda a evitar esse problema. Para uma melhor experiência, recomendamos que você use um pooler de conexões como o ProxySQL para gerenciar conexões com eficiência. Para saber mais sobre como configurar o ProxySQL, vejaessa postagem do blog.

Observação

ProxySQL é uma ferramenta comunitária de código aberto. A Microsoft oferece suporte da melhor forma possível. Para obter suporte de produção com orientação confiável, entre em contato com Suporte ao produto ProxySQL.

innodb_strict_mode

Se você receber um erro semelhante a "Tamanho da linha muito grande (> 8126)", talvez seja necessário desativar o parâmetro innodb_strict_mode servidor. Esse parâmetro não pode ser modificado globalmente no nível do servidor porque se o tamanho dos dados da linha for maior que 8 K, os dados serão truncados sem erro. Esse truncamento pode levar à perda potencial de dados. É recomendável modificar o esquema para se ajustar ao limite do tamanho de página.

Você pode definir esse parâmetro no nível da sessão usando init_connect. Para obter mais informações, veja Configurando parâmetros de servidor não modificáveis.

Observação

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

time_zone

Na implantação inicial, uma instância do Banco de Dados do Azure para MySQL - Servidor Flexível inclui tabelas do sistema para informações de fuso horário, mas essas tabelas não são preenchidas. Você pode preencher as tabelas de fuso horário chamando o procedimento armazenado mysql.az_load_timezone de uma ferramenta como a linha de comando do MySQL ou o MySQL Workbench. Você também pode chamar o procedimento armazenado e definir os fusos horários globais ou de nível de sessão usando o portal do Azure ou o CLI do Azure.

binlog_expire_logs_seconds

No Banco de Dados do Azure para MySQL - Servidor Flexível, o parâmetro binlog_expire_logs_seconds especifica o número de segundos que o serviço aguarda antes de excluir 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. O log binário também contém eventos para instruções que potencialmente poderiam ter feito alterações. O log binário é usado principalmente para duas finalidades: operações de replicação e recuperação de dados.

Normalmente, os logs binários são excluídos assim que o identificador é liberado do serviço, backup ou 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 excluídas.

Se você quiser persistir logs binários por um período maior, você pode configurar o parâmetro binlog_expire_logs_seconds. Se binlog_expire_logs_seconds for definido como o valor padrão de 0, um log binário será excluído assim que o identificador para ele for liberado. Se o valor de binlog_expire_logs_seconds for maior que 0, o log binário será excluído após o número de segundos configurado.

O Banco de Dados do Azure para MySQL - Servidor Flexível manipula recursos gerenciados, como backup e exclusão de réplicas de leitura de arquivos binários, internamente. Ao replicar os dados do Banco de Dados do Azure para MySQL - Servidor Flexível, esse parâmetro precisa ser definido no primário para evitar a exclusão de logs binários antes que a réplica leia as alterações no primário. Se você definir binlog_expire_logs_seconds para um valor mais alto, os logs binários não serão excluídos em tempo hábil. Esse atraso pode levar a um aumento na fatura de armazenamento.

event_scheduler

No Banco de Dados do Azure para MySQL - Servidor Flexível, o parâmetro event_scheduler servidor gerencia a criação, o agendamento e a execução de eventos. Ou seja, o parâmetro gerencia tarefas que são executadas de acordo com uma programação por um thread especial do MySQL Event Scheduler. Quando o parâmetro event_scheduler é definido como ON, o thread do Event Scheduler é listado como um processo daemon na saída de SHOW PROCESSLIST.

Para servidores MySQL versão 5.7, o parâmetro do servidor event_scheduler é desativado automaticamente quando o backup é iniciado e o parâmetro do servidor event_scheduler é ativado novamente após a conclusão bem-sucedida do backup. No MySQL versão 8.0 para Banco de Dados do Azure para MySQL – Servidor Flexível, event_scheduler permanece inalterado durante os backups. Para garantir operações mais suaves, é recomendável atualizar seus servidores MySQL 5.7 para a versão 8.0 usando uma atualização de versão principal.

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

Para obter mais informações sobre como criar um evento, consulte a seguinte documentação sobre o Event Scheduler no manual de referência do MySQL:

Configurar 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 - Servidor Flexível.

Para demonstrar o cenário, considere o seguinte exemplo de 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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```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());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    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) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    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) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    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) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

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

Para executar uma instrução SQL a cada hora sem fim:

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

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

Limitações

Para servidores com alta disponibilidade configurada, quando ocorre failover, é possível que o parâmetro event_scheduler server esteja definido como OFF. Se isso ocorrer, quando o failover for concluído, configure o parâmetro para definir o valor como ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table é um parâmetro de servidor no MySQL que especifica o nome da tabela que contém palavras irrelevantes personalizadas para a Pesquisa de Texto Completo do InnoDB. A tabela deve estar no mesmo banco de dados que a tabela indexada de texto completo e sua primeira coluna deve ser do tipo VARCHAR. No Banco de Dados do Azure para MySQL - Servidor Flexível, a configuração padrão de sql_generate_invisible_primary_key=ON faz com que todas as tabelas sem uma chave primária explícita incluam automaticamente uma chave primária invisível. Esse comportamento está em conflito com os requisitos de innodb_ft_user_stopword_table, pois a chave primária invisível se torna a primeira coluna da tabela, impedindo que ela funcione conforme pretendido durante a Pesquisa de Texto Completo. Para resolver esse problema, você deve definir sql_generate_invisible_primary_key=OFF na mesma sessão antes de criar a tabela de palavras irrelevantes personalizada. Por exemplo:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Isso garante que a tabela de palavras irrelevantes atenda aos requisitos do MySQL e permite que as palavras irrelevantes personalizadas funcionem corretamente.

Parâmetros de servidor não modificáveis

O painel Parâmetros do servidor no portal do Azure mostra os parâmetros do servidor modificáveis ​​e não modificáveis. Os parâmetros do servidor não modificáveis ​​não estão disponíveis. Você pode configurar um parâmetro de servidor não modificável no nível da sessão usando init_connectno portal do Azure ou a CLI do Azure.

Conteúdo relacionado