Comandos FLUSH do MySQL: Referência Completa para Administradores de Banco de Dados

A instrução `FLUSH` do MySQL força o servidor a recarregar caches internos, fechar e reabrir ficheiros de log, redefinir contadores de estado e sincronizar o estado em memória com as estruturas em disco — tudo sem necessitar de reiniciar o servidor. Isto torna-o uma das famílias de comandos operacionalmente mais críticas disponíveis para um administrador de base de dados.

Compreender cada variante, o seu âmbito preciso e os seus efeitos secundários não é conhecimento opcional em ambientes de produção. O uso indevido de `FLUSH TABLES WITH READ LOCK` num sistema OLTP ocupado, por exemplo, pode causar bloqueios de escrita em toda a aplicação com duração de minutos. Esta referência abrange todas as variantes significativas de `FLUSH`, incluindo diferenças de comportamento entre MySQL 5.7 e 8.x, implicações específicas do InnoDB, riscos de replicação e requisitos de privilégios.

Por que os Comandos FLUSH São Importantes em Produção

O servidor MySQL mantém inúmeras estruturas em memória para acelerar operações: o cache de ligações de host, caches de tabelas de concessão, descritores de tabelas abertas, caches de resultados de consultas e pools de buffers do motor de armazenamento. Estes caches são autoritativos durante o tempo de execução. Quando um administrador faz alterações fora de banda — editando tabelas de concessão diretamente com `INSERT`/`UPDATE`, rodando ficheiros de log ao nível do SO, ou movendo ficheiros `.ibd` — a visão em memória do servidor torna-se desatualizada. Os comandos `FLUSH` reconciliam essa divergência.

Categorias operacionais chave onde `FLUSH` é indispensável:

• Propagação de privilégios sem reiniciar `mysqld`
• Backups online consistentes usando snapshots baseados em bloqueio
• Rotação de logs integrada com `logrotate` ou scripts personalizados
• Resets de linha de base de desempenho antes de benchmarking
• Invalidação do cache de host após alterações na topologia de rede
• Aplicação de durabilidade do motor de armazenamento antes de janelas de manutenção

Privilégios Necessários

A maioria das variantes de `FLUSH` requer o privilégio `RELOAD`. `FLUSH TABLES WITH READ LOCK` requer adicionalmente `LOCK TABLES`. No MySQL 8.0+, foram introduzidos privilégios dinâmicos de granularidade fina (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`), permitindo um controlo de acesso mais granular sem conceder o amplo privilégio `RELOAD`. Aplique sempre o princípio do menor privilégio ao atribuí-los a contas de aplicação ou monitorização.

Referência Completa: Comandos MySQL FLUSH

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Este comando recarrega as tabelas de concessão em memória a partir da base de dados do sistema `mysql` (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`). O servidor lê estas tabelas no arranque e coloca-as em cache. Qualquer DML direto (`INSERT`, `UPDATE`, `DELETE`) contra essas tabelas ignora o mecanismo normal de `GRANT`/`REVOKE`, deixando o cache desatualizado até que `FLUSH PRIVILEGES` seja executado.

Quando usar:

• Após editar manualmente tabelas de concessão com SQL bruto em vez de instruções `GRANT`/`REVOKE`
• Após importar um mysqldump que inclui inserções diretas em `mysql.user`
• Após restaurar um backup parcial do esquema `mysql`

Nuance crítica: Quando utiliza as instruções `GRANT`, `REVOKE`, `CREATE USER` ou `DROP USER`, o MySQL recarrega automaticamente as tabelas de concessão. `FLUSH PRIVILEGES` só é necessário quando ignora completamente essas instruções. Executá-lo desnecessariamente é inofensivo, mas adiciona um breve bloqueio no cache da tabela de concessão.

Nota de replicação: `FLUSH PRIVILEGES` é escrito no log binário e replicado para as réplicas por padrão. Este é geralmente o comportamento desejado ao gerir utilizadores numa topologia de replicação.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Este comando fecha todos os descritores de ficheiros de tabelas atualmente abertos e remove-os do cache de definição de tabelas (TDC). No próximo acesso, o MySQL reabre os ficheiros de tabela a partir do disco. Isto é essencial após qualquer manipulação de ficheiros fora de banda.

Quando usar:

• Após copiar ou substituir ficheiros `.frm`, `.ibd` ou `.MYD`/`.MYI` ao nível do SO
• Para libertar memória do cache de tabelas em servidores com um valor `table_open_cache` muito grande
• Como pré-requisito antes de usar `IMPORT TABLESPACE` em operações de tablespace transportável do InnoDB

Consideração de desempenho: Num servidor com milhares de tabelas abertas, `FLUSH TABLES` adquire brevemente um bloqueio global. Em sistemas de alta concorrência, isto pode causar um pico de latência notável. Prefira a forma específica de tabela (`FLUSH TABLES tbl1, tbl2`) para minimizar o impacto.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Esta é uma das variantes de `FLUSH` mais poderosas e potencialmente disruptivas. Fecha todas as tabelas abertas, limpa o cache de consultas e adquire um bloqueio de leitura global que impede quaisquer operações de escrita em todas as bases de dados. O bloqueio persiste até que `UNLOCK TABLES` seja emitido ou a sessão termine.

Quando usar:

• Antes de realizar um backup físico com ferramentas como `mysqldump –single-transaction` (para bases de dados exclusivamente InnoDB, isto é desnecessário — veja abaixo)
• Antes de usar `mysqlpump` ou `xtrabackup` em ambientes não-InnoDB
• Para criar um snapshot consistente em ponto no tempo entre motores de armazenamento mistos (InnoDB + MyISAM)

Armadilha crítica — bases de dados exclusivamente InnoDB: Para bases de dados que usam exclusivamente tabelas InnoDB, `FTWRL` quase nunca é necessário. `mysqldump –single-transaction` abre uma transação de leitura repetível que fornece um snapshot consistente sem bloquear escritas. Usar `FTWRL` neste cenário causa bloqueios de escrita desnecessários.

Risco de replicação: Se `FTWRL` for executado numa réplica, bloqueia o thread de aplicação SQL, fazendo com que o atraso de replicação se acumule durante a duração do bloqueio. Monitorize sempre `Seconds_Behind_Master` após libertar o bloqueio.

Interação com bloqueio de metadados: No MySQL 5.7+, `FTWRL` aguarda que todas as transações ativas sejam concluídas antes de adquirir o bloqueio global. Num servidor ocupado com transações de longa duração, esta espera pode ser indefinida. Use `SHOW PROCESSLIST` para identificar transações bloqueantes antes de executar `FTWRL`.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

O MySQL mantém um cache de host que regista o histórico de tentativas de ligação, incluindo contagens de autenticações falhadas. Quando um host acumula mais de `max_connect_errors` ligações falhadas consecutivas, o MySQL bloqueia todas as ligações subsequentes desse host até que a entrada do cache seja limpa.

Quando usar:

• Quando um host cliente legítimo está bloqueado por exceder `max_connect_errors`
• Após resolver um problema de rede que causou falhas repetidas de ligação TCP
• Após alterar registos DNS que afetam a forma como o servidor resolve nomes de host de clientes

Alternativa no MySQL 8.0: No MySQL 8.0+, também pode truncar diretamente a tabela do cache de host:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Isto alcança o mesmo resultado e é mais transparente em scripts automatizados.

Configuração proativa: Em vez de depender de `FLUSH HOSTS` de forma reativa, defina `max_connect_errors` para um valor mais alto (por exemplo, `10000`) ou defina `host_cache_size = 0` para desativar completamente o cache de host em redes internas de confiança.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Redefine a maioria das variáveis de estado de sessão e globais para zero. Isto inclui contadores como `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` e centenas de outros expostos via `SHOW STATUS` ou `performance_schema`.

Quando usar:

• Imediatamente antes de um benchmark controlado para estabelecer uma linha de base de medição limpa
• Após uma alteração de configuração (por exemplo, ajustar `innodb_buffer_pool_size`) para isolar o efeito nas métricas de I/O
• Ao criar scripts de testes de regressão de desempenho que comparam deltas de contadores antes/depois

Limitação importante: `FLUSH STATUS` não redefine todos os contadores. Variáveis como `Uptime`, `Uptime_since_flush_status` e certas métricas internas do InnoDB não são afetadas. Para monitorização abrangente, use diretamente as tabelas `performance_schema`, que oferecem granularidade por thread e por evento que `FLUSH STATUS` não consegue fornecer.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` fecha e reabre todos os ficheiros de log do servidor. O MySQL 5.7.2+ introduziu a capacidade de limpar tipos de log específicos individualmente, o que é muito preferível em produção.

Quando usar:

• Como parte de um script post-rotate do `logrotate` para sinalizar ao MySQL que abra um novo ficheiro de log após o antigo ter sido rodado
• Para forçar um novo ficheiro de log binário (equivalente a `FLUSH BINARY LOGS`), que incrementa o número de sequência do log binário
• Antes de arquivar logs antigos para garantir que todas as escritas pendentes são descarregadas para disco

Especificidades do log binário: `FLUSH BINARY LOGS` cria um novo ficheiro de log binário e escreve um `Rotate_event` no ficheiro antigo. Esta é a forma correta de segmentar logs binários para arquivamento de recuperação em ponto no tempo (PITR). O ficheiro de log binário atual e a posição podem ser confirmados com `SHOW MASTER STATUS` (MySQL 5.7) ou `SHOW BINARY LOG STATUS` (MySQL 8.4+).

Exemplo de integração com logrotate:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Aviso de descontinuação: O cache de consultas do MySQL foi descontinuado no MySQL 5.7.20 e removido completamente no MySQL 8.0. Se estiver a executar MySQL 8.0 ou posterior, este comando não existe.

Para ambientes MySQL 5.6/5.7 onde o cache de consultas ainda está ativo:

• `FLUSH QUERY CACHE` desfragmenta a memória do cache de consultas sem remover os resultados em cache
• `RESET QUERY CACHE` remove completamente todos os resultados de consultas em cache

Quando usar (apenas MySQL 5.6/5.7):

• Após uma grande modificação de dados em lote que invalida uma parte significativa dos resultados em cache
• Quando `Qcache_free_blocks` é alto em relação a `Qcache_total_blocks`, indicando fragmentação
• Antes de desativar o cache de consultas (`SET GLOBAL query_cache_size = 0`) para libertar memória de forma limpa

Alternativa moderna: No MySQL 8.0+, use o aquecimento do pool de buffers InnoDB (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) e `performance_schema` para análise ao nível de consultas.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

Redefine os contadores de recursos por utilizador rastreados pela limitação de taxa integrada do MySQL. Estes contadores aplicam limites definidos nas instruções `CREATE USER` ou `GRANT`:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Quando usar:

• Quando um utilizador esgotou a sua quota de consultas por hora e precisa de acesso imediato restaurado antes que o contador seja redefinido naturalmente no próximo limite de hora
• Após aumentar os limites de recursos de um utilizador e querer que os novos limites entrem em vigor imediatamente
• Durante desenvolvimento/teste para redefinir quotas entre execuções de teste

Nota: Este comando redefine contadores para todos os utilizadores simultaneamente. Não existe granularidade por utilizador ao nível de `FLUSH`. Se precisar de redefinir os contadores de um único utilizador, a única opção é modificar a sua conta com `ALTER USER` e depois emitir `FLUSH USER_RESOURCES`.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Força todos os motores de armazenamento a descarregar os seus buffers de escrita pendentes para os respetivos ficheiros de log. Para o InnoDB, isto significa descarregar o buffer do redo log (`innodb_log_buffer_size`) para os ficheiros de redo log do InnoDB em disco.

Quando usar:

• Antes de realizar um backup a frio dos ficheiros de dados InnoDB para garantir a consistência do redo log
• Durante a resolução de problemas do motor de armazenamento para descartar inconsistências de dados relacionadas com buffers
• Como parte de uma lista de verificação pré-manutenção antes de parar o serviço MySQL

Contexto de durabilidade InnoDB: A definição `innodb_flush_log_at_trx_commit` do InnoDB controla a agressividade com que o redo log é descarregado em cada commit de transação. `FLUSH ENGINE LOGS` é uma substituição manual que força um descarte independentemente dessa definição. Isto é útil em cenários onde precisa de um ponto de verificação de durabilidade garantido sem confirmar uma transação.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

Recarrega o ficheiro de chave de encriptação DES especificado pela opção de arranque do servidor `–des-key-file`. Este ficheiro de chave era usado pelas funções `DES_ENCRYPT()` e `DES_DECRYPT()`.

Aviso de descontinuação: As funções `DES_ENCRYPT()` e `DES_DECRYPT()` foram descontinuadas no MySQL 5.7.6 e removidas no MySQL 8.0. Este comando é, portanto, apenas relevante em instalações legadas MySQL 5.6/5.7.

Alternativa moderna de encriptação: Use a encriptação nativa de dados em repouso do MySQL (encriptação de tablespace InnoDB via `ALTER TABLE … ENCRYPTION='Y'`) combinada com plugins MySQL Keyring (`keyring_file`, `keyring_okv`, `keyring_aws`) para requisitos de encriptação em produção.

Tabela de Comparação de Comandos FLUSH

Replicação e FLUSH: O Que É Replicado

Nem todos os comandos `FLUSH` são replicados para servidores réplica. Compreender esta distinção é crítico em topologias de HA e replicação:

Replicado por padrão:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (escrito como `Rotate_event` no log binário)
• `FLUSH USER_RESOURCES`

Não replicado (local de sessão ou explicitamente excluído):

• `FLUSH TABLES WITH READ LOCK` — nunca escrito no log binário
• `FLUSH STATUS` — afeta apenas os contadores do servidor local
• `FLUSH HOSTS` — apenas cache de host local
• `FLUSH ENGINE LOGS` — apenas estado do motor local

Para impedir que um comando `FLUSH` específico seja replicado mesmo quando normalmente o seria, use o modificador `LOCAL` ou `NO_WRITE_TO_BINLOG`:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Isto é útil ao gerir privilégios de forma independente numa réplica (por exemplo, adicionando utilizadores de monitorização que não devem existir no primário).

Automatizar Operações FLUSH com mysqladmin

Muitas operações `FLUSH` podem ser acionadas a partir da shell sem abrir uma sessão de cliente MySQL, o que é útil em tarefas cron e scripts de manutenção:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

Para ambientes de produção, armazene as credenciais em `~/.my.cnf` com `chmod 600` em vez de passar `-p` interativamente, ou use o mecanismo `–login-path` do MySQL com `mysql_config_editor`.

Considerações sobre o Ambiente de Alojamento

A capacidade de executar comandos `FLUSH` depende muito do ambiente de alojamento e do nível de acesso à base de dados concedido. Num plano de Alojamento VPS, normalmente tem acesso root completo à instância MySQL, o que significa que pode executar qualquer variante de `FLUSH`, modificar `my.cnf` e gerir a rotação de logs diretamente. Este é o ambiente mínimo recomendado para qualquer trabalho sério de administração de bases de dados.

No Alojamento Web Partilhado, o acesso à base de dados é geralmente restrito a um utilizador sem privilégios sem o privilégio `RELOAD`, tornando a maioria dos comandos `FLUSH` indisponíveis. Se a sua aplicação requer gestão de privilégios, controlo de rotação de logs ou snapshots consistentes para backup, um ambiente partilhado será um bloqueador absoluto.

Para cargas de trabalho de base de dados de alto rendimento — particularmente aquelas que envolvem operações `FLUSH ENGINE LOGS` frequentes ou grandes pools de buffers InnoDB — os Servidores Dedicados fornecem o rendimento de I/O e a largura de banda de memória necessários para tornar estas operações não disruptivas. Um `FLUSH TABLES WITH READ LOCK` num servidor com 256 GB de dados no pool de buffers demora visivelmente mais do que num servidor com armazenamento NVMe rápido e canais de I/O dedicados.

Se estiver a gerir uma instância MySQL juntamente com um painel de controlo web, o VPS com cPanel fornece um ambiente gerido onde algumas operações `FLUSH` (particularmente rotação de logs e recargas de privilégios) são tratadas automaticamente pela camada de gestão de bases de dados do painel de controlo, reduzindo a necessidade de intervenção manual.

Para aplicações suportadas por bases de dados que requerem um ecossistema completo de painel de controlo, rever os Painéis de Controlo VPS disponíveis ajudará a identificar qual o painel que melhor se integra com o seu fluxo de trabalho de administração MySQL.

Lista de Verificação de Pontos-Chave

Use esta matriz de decisão antes de executar qualquer comando `FLUSH` em produção:

• Antes de `FLUSH TABLES WITH READ LOCK`: Confirme que não existem transações de longa duração ativas (`SHOW PROCESSLIST`). Verifique se a sua base de dados é exclusivamente InnoDB — se sim, use `–single-transaction` em alternativa.
• Antes de `FLUSH PRIVILEGES`: Confirme que está a usar DML bruto nas tabelas de concessão. Se usou `GRANT`/`REVOKE`, este comando é redundante.
• Antes de `FLUSH LOGS`: Certifique-se de que o seu script de rotação de logs já moveu/renomeou o ficheiro de log antigo antes de sinalizar ao MySQL para o reabrir.
• Antes de `FLUSH HOSTS`: Identifique primeiro a causa raiz das falhas de ligação. Limpar o cache de host sem corrigir o problema subjacente resultará no bloqueio do host novamente.
• No MySQL 8.0+: Remova quaisquer chamadas `FLUSH QUERY CACHE` ou `FLUSH DES_KEY_FILE` dos scripts — estes comandos não existem e causarão erros.
• Em topologias de replicação: Use `FLUSH LOCAL` ou `FLUSH NO_WRITE_TO_BINLOG` quando a operação não deve ser propagada para as réplicas.
• Para automação: Use comandos `mysqladmin flush-*` em scripts em vez de abrir sessões completas de cliente MySQL.
• Auditoria de privilégios: Prefira os privilégios dinâmicos do MySQL 8.0 (`FLUSH_STATUS`, `FLUSH_TABLES`, etc.) em vez do amplo privilégio `RELOAD` para contas de monitorização e backup.

Perguntas Frequentes

O FLUSH PRIVILEGES precisa de ser executado após cada instrução GRANT ou REVOKE?

Não. `GRANT`, `REVOKE`, `CREATE USER` e `DROP USER` recarregam automaticamente as tabelas de concessão em memória. `FLUSH PRIVILEGES` só é necessário após modificações DML diretas nas tabelas do sistema `mysql` (por exemplo, `UPDATE mysql.user SET …`).

O FLUSH TABLES WITH READ LOCK pode causar tempo de inatividade da aplicação?

Sim. Adquire um bloqueio de escrita global que bloqueia todas as operações `INSERT`, `UPDATE`, `DELETE` e DDL em todas as bases de dados no servidor. Num sistema OLTP ocupado, mesmo alguns segundos de `FTWRL` podem esgotar os pools de ligações e causar erros em cascata na aplicação. Para bases de dados exclusivamente InnoDB, use `mysqldump –single-transaction` para evitar isto completamente.

O FLUSH STATUS é equivalente a reiniciar o servidor MySQL para fins de benchmarking?

Não. `FLUSH STATUS` redefine a maioria dos contadores de estado, mas não limpa o pool de buffers InnoDB, redefine estados de ligação ou afeta as estatísticas acumuladas de `performance_schema`. Para um benchmark verdadeiramente limpo, um reinício do servidor combinado com a limpeza do pool de buffers é mais preciso, embora impraticável em produção.

Por que o FLUSH HOSTS não existe como comando autónomo em alguma documentação do MySQL 8.0?

`FLUSH HOSTS` ainda funciona no MySQL 8.0, mas o método preferido é `TRUNCATE TABLE performance_schema.host_cache`, que é mais explícito e pode ser executado sem o privilégio `RELOAD` se o utilizador tiver `DELETE` em `performance_schema`. Ambos alcançam o mesmo resultado.

O que acontece se o FLUSH ENGINE LOGS for executado durante uma carga de escrita de pico no InnoDB?

Força uma descarga síncrona do buffer de log InnoDB para disco, o que pode causar uma breve interrupção de escrita se os ficheiros de redo log estiverem em armazenamento lento. Em servidores com NVMe, o impacto é tipicamente sub-milissegundo. Em disco rotativo ou armazenamento SAN muito carregado, pode causar picos de latência notáveis. Agende esta operação durante janelas de baixo tráfego sempre que possível.