Permissão no banco WP-Optimize: corrigir limpeza

Tipo Performance & Velocidade

Nome do erro Erro de permissão ao limpar banco no WP-Optimize EN: WP-Optimize database cleanup permission error

Severidade Atenção

Descrição O erro de permissão no banco do WP-Optimize trava a limpeza quando o usuário MySQL definido no wp-config.php não tem o privilégio que o comando OPTIMIZE TABLE exige para recriar a tabela. O plugin marca cada otimização como falha e o overhead não cai. A correção é conceder o GRANT correto ao usuário do banco.

O que é o erro de permissão no banco do WP-Optimize?

O erro de permissão no banco do WP-Optimize é a falha em que a aba Optimizations executa cada operação, mas devolve uma mensagem de privilégio negado em vez de reduzir o overhead da tabela. O WP-Optimize não tem acesso próprio ao banco: ele roda as consultas pela conexão que o WordPress abre com o usuário e a senha definidos nas constantes DB_USER e DB_PASSWORD do wp-config.php. Quando uma otimização de tabela é disparada, o plugin envia o comando OPTIMIZE TABLE ao MySQL. Em tabelas InnoDB, esse comando é remapeado pelo servidor para um ALTER TABLE que recria a tabela inteira, e essa recriação exige os privilégios ALTER, INDEX, CREATE e DROP sobre o schema. Se o usuário do WordPress recebeu apenas SELECT, INSERT, UPDATE e DELETE, o servidor recusa a operação com um erro de comando negado, e a limpeza para naquele ponto.

Como identificar

A aba Optimizations mostra a mensagem “Optimizing the table … failed” logo abaixo da operação, em vermelho, e o overhead da tabela continua igual ao anterior.
O log do MySQL ou o WP_DEBUG registra o erro “OPTIMIZE command denied to user ‘usuário’@’host’ for table ‘wp_options'” ou “ALTER command denied to user”.
Rodar wp db query “OPTIMIZE TABLE wp_postmeta;” pela linha de comando devolve “Access denied” em vez de uma tabela de status com Op optimize e Msg_text status OK.
A coluna Status do relatório do WP-Optimize fica em “Table does not support optimize, doing recreate + analyze instead” e em seguida falha por falta de privilégio para recriar.
Apenas a limpeza por DELETE de revisões e transients conclui, enquanto toda otimização que recria a tabela é marcada como falha, sinal de que faltam privilégios de DDL e não de leitura ou escrita.

Antes de começar: Antes de mexer em privilégios, exporte o banco com um dump completo para ter de onde restaurar. Conceda ALTER, CREATE e DROP só no schema do WordPress, no formato nome_do_banco.*, e nunca em escopo global com asterisco ponto asterisco, porque um usuário do site com DROP global pode apagar qualquer banco do servidor se a senha vazar.

Como prevenir

Ao criar a conta do banco para um site WordPress, conceda de uma vez SELECT, INSERT, UPDATE, DELETE, ALTER, INDEX, CREATE e DROP restritos ao schema do site, para a limpeza que recria tabela funcionar sem ajuste posterior
Sempre limite o GRANT ao banco do WordPress no formato nome_do_banco.* em vez de escopo global, para reduzir o estrago caso a senha do usuário do site vaze
Antes de migrar de hospedagem, anote os privilégios do usuário do banco de origem e replique exatamente no destino, porque painéis diferentes criam contas com privilégios mínimos distintos
Confira se um plugin de segurança ou uma política do provedor não revoga ALTER e DROP do usuário do site de forma automática, o que silenciosamente quebra a otimização de tabela depois de já estar funcionando

Causa

O usuário em DB_USER do wp-config.php recebeu só os privilégios SELECT, INSERT, UPDATE e DELETE na criação da conta de hospedagem, e o OPTIMIZE TABLE de uma tabela InnoDB é remapeado para um ALTER TABLE que exige ALTER, INDEX, CREATE e DROP que o usuário não tem.
O banco roda MySQL anterior à versão 5.7 e o WP-Optimize tenta o caminho de recriar mais analisar a tabela InnoDB, descrito na doc oficial do plugin, em vez de um OPTIMIZE direto, e essa recriação esbarra na falta de privilégio de DDL do usuário.
A conta do banco foi concedida com escopo restrito a um único schema, no formato GRANT em nome_do_banco.* para o usuário@host, e a otimização tenta operar numa tabela com prefixo que ficou fora desse escopo, então o servidor nega o comando.
Um plugin de segurança ou uma política do provedor revogou os privilégios de ALTER e DROP do usuário do site para reduzir o risco de injeção, e a limpeza que recria tabela passou a ser recusada a partir daquele momento.
A tabela alvo é InnoDB e o servidor responde com o aviso de que não suporta optimize e parte para recriar mais analisar, e é nesse passo de recriação que o privilégio ausente derruba a operação.

Como resolver

Confirme qual usuário do banco o WordPress usa: abra o wp-config.php por FTP e leia as constantes de conexão para saber exatamente qual conta o WP-Optimize está usando e em qual banco ela opera. Anote os três valores antes de mexer em privilégios.
```
define( 'DB_NAME', 'nome_do_banco' );
define( 'DB_USER', 'usuário_do_banco' );
define( 'DB_HOST', 'localhost' );
```
Reproduza o erro pela linha de comando: rode o mesmo comando que o WP-Optimize dispara, isolado, para confirmar que a falha é de privilégio e não outra coisa. Se voltar Access denied, o problema é o GRANT do usuário.
```
wp db query "OPTIMIZE TABLE wp_options;"
```
Veja os privilégios atuais do usuário: entre no MySQL com uma conta administrativa, normalmente a root ou a conta de admin do painel da hospedagem, e liste o que o usuário do site realmente pode fazer. Procure por ALTER, INDEX, CREATE e DROP na resposta.
```
mysql -u root -p
SHOW GRANTS FOR 'usuário_do_banco'@'localhost';
```
Conceda os privilégios que o OPTIMIZE TABLE exige: ainda no MySQL com a conta administrativa, acrescente ao usuário do site os privilégios de recriação de tabela apenas no banco do WordPress, nunca em escopo global. Em seguida recarregue as permissões para o servidor aplicar a mudança na hora.
```
GRANT ALTER, INDEX, CREATE, DROP ON nome_do_banco.* TO 'usuário_do_banco'@'localhost';
FLUSH PRIVILEGES;
```
Valide a otimização e rode de novo no WP-Optimize: repita o comando isolado para confirmar que agora a tabela de status volta com Msg_text como OK, depois abra o plugin e dispare a limpeza completa. O overhead deve cair e as operações param de aparecer em vermelho.
```
wp db query "OPTIMIZE TABLE wp_options;"
wp-admin -> WP-Optimize -> Database -> Run all selected optimizations
```

SQL

-- Diagnostico: lista os privilegios atuais do usuario do site
SHOW GRANTS FOR 'usuario_do_banco'@'localhost';

-- Concede SO os privilegios de DDL que o OPTIMIZE TABLE exige,
-- restrito ao schema do WordPress (nunca global *.*)
GRANT ALTER, INDEX, CREATE, DROP
  ON nome_do_banco.*
  TO 'usuario_do_banco'@'localhost';

FLUSH PRIVILEGES;

-- Confirma que a otimizacao agora roda sem Access denied
OPTIMIZE TABLE wp_options;

Perguntas frequentes

Por que o WP-Optimize falha com erro de permissão só na otimização de tabela?

Porque a limpeza de revisões e transients usa DELETE, que o usuário do site costuma ter, enquanto a otimização de tabela InnoDB é remapeada pelo MySQL para um ALTER TABLE que recria a tabela e exige ALTER, INDEX, CREATE e DROP. Se a conta tem só leitura e escrita, o servidor nega esse comando e a operação para.

Qual erro exato aparece quando falta privilégio no banco do WP-Optimize?

No log do MySQL ou com o WP_DEBUG ligado aparece algo como OPTIMIZE command denied to user usuário arroba host for table wp_options, ou ALTER command denied to user. Esse texto confirma que a falha é de GRANT do usuário do banco, e não de configuração do plugin ou falta de espaço em disco.

Quais privilégios o usuário do banco precisa para o WP-Optimize otimizar tabelas?

Além de SELECT, INSERT, UPDATE e DELETE, o usuário precisa de ALTER, INDEX, CREATE e DROP no schema do WordPress. O OPTIMIZE TABLE em InnoDB recria a tabela inteira, e essa recriação só roda com esses quatro privilégios de DDL concedidos sobre o banco do site.

Por que a doc do WP-Optimize diz que tabelas InnoDB são recriadas?

Porque, conforme a doc oficial do plugin, o OPTIMIZE em InnoDB antes do MySQL 5.7 é ineficaz e na prática reconstrói a tabela inteira. Por isso o WP-Optimize parte para recriar mais analisar a tabela, e é justamente esse passo de recriação que exige o privilégio de DDL que muitas contas de hospedagem não têm.

Conceder DROP ao usuário do site é seguro?

É seguro desde que o GRANT seja limitado ao schema do WordPress no formato nome_do_banco ponto asterisco, nunca em escopo global. Assim o usuário só pode recriar tabelas do próprio site. O risco real é conceder DROP em asterisco ponto asterisco, que permitiria apagar qualquer banco do servidor se a senha vazar.

Como confirmo que o problema é permissão e não outra falha do WP-Optimize?

Rode o comando isolado wp db query com OPTIMIZE TABLE numa tabela. Se voltar Access denied ou command denied to user, é permissão. Se voltar uma tabela de status com Msg_text como OK, o privilégio existe e a falha do plugin tem outra origem, como timeout ou tabela travada.

Preciso de acesso root ao MySQL para corrigir esse erro?

Você precisa de uma conta administrativa do banco, que pode ser a root via SSH ou a conta de admin do painel da hospedagem em ferramentas como o phpMyAdmin. Com ela você roda o GRANT que acrescenta os privilégios ao usuário do site. O próprio usuário do site não consegue conceder privilégios a si mesmo.

Informativo

Como corrigir o cache do WP Rocket que serve Custom Fields dinâmicos do ACF PRO desatualizados no WordPress

O cache ACF WP Rocket entrega valores antigos quando o WP Rocket guarda o HTML já renderizado da página e não regenera esse arquivo ao salvar um Custom Field dinâmico do ACF PRO; o visitante continua vendo o valor anterior até o cache expirar ou ser purgado.

Grave

Como corrigir o erro 404 após ativar o WP Rocket

O WP Rocket erro 404 surge quando o navegador pede um arquivo CSS/JS minificado, um asset de CDN ou uma página que o cache aponta para um caminho inexistente. Na maioria dos casos a causa é o nome do arquivo combinado mudar e a referência antiga ficar em cache.

Atenção

Como corrigir o cache mobile do WP Rocket que não funciona no iOS no WordPress

O cache mobile do WP Rocket não funciona no iOS quando a opção Separate cache files for mobile devices está desativada, quando uma camada de cache acima do WP Rocket (Cloudflare, Varnish ou NGINX) entrega a versão desktop ao iPhone, ou quando o user agent do Safari iOS não é detectado como dispositivo móvel.

Atenção

Como corrigir o aviso de cache do navegador no WordPress

O aviso de browser caching no WordPress aparece quando os arquivos estáticos do site são servidos sem cabeçalho de validade (expires), forcando o navegador a baixar tudo de novo a cada visita. A correção e definir expires headers no servidor.

Grave

Como corrigir JavaScript do JetEngine removido pelo Perfmatters

O JavaScript do JetEngine removido pelo Perfmatters acontece quando o Delay JavaScript ou o Script Manager tira o jet-engine frontend.min.js e o jQuery da página. O resultado e Listing Grid vazio, JetSmartFilters que não filtra e Load More que não responde. A correção e excluir os scripts do JetEngine do delay, não desligar o Perfmatters.

Grave

Como corrigir CLS alto e layout shift no WordPress

CLS alto no WordPress é quando o Cumulative Layout Shift, a medida de quanto os elementos da página "pulam" durante o carregamento, fica acima de 0,1. Costuma vir de imagens e iframes sem dimensões reservadas, fontes que trocam de tamanho e anúncios ou banners injetados sem espaço fixo.

Setores

Extensões

Integrações

Como corrigir o erro de permissão ao limpar o banco no WP-Optimize

O que é o erro de permissão no banco do WP-Optimize?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o cache do WP Rocket que serve Custom Fields dinâmicos do ACF PRO desatualizados no WordPress

Como corrigir o erro 404 após ativar o WP Rocket

Como corrigir o cache mobile do WP Rocket que não funciona no iOS no WordPress

Como corrigir o aviso de cache do navegador no WordPress

Como corrigir JavaScript do JetEngine removido pelo Perfmatters

Como corrigir CLS alto e layout shift no WordPress

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos