Como corrigir o erro de permissão ao limpar o banco no WP-Optimize
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.














