Resolver problemas

Porque é que o cPanel e o phpMyAdmin mostram tamanhos diferentes para uma base de dados

Revisto a 5 min de leitura MySQL phpMyAdmin espaço bases de dados

O cPanel e o phpMyAdmin podem mostrar valores diferentes para a mesma base porque a origem e o momento de atualização dependem da configuração do servidor.

Verificar quanto ocupa a base de dados no cPanel e no phpMyAdmin

  • O phpMyAdmin obtém de INFORMATION_SCHEMA o espaço atribuído aos dados e índices. Em InnoDB estes valores são aproximados.
  • O cPanel pode obter a utilização a partir de INFORMATION_SCHEMA ou dos ficheiros do servidor, conforme a configuração do WHM. Com a opção predefinida utiliza INFORMATION_SCHEMA.
  • O cPanel mantém uma cache dos tamanhos durante cerca de quatro horas.
  • No MySQL 8, as estatísticas de tabelas que o phpMyAdmin consulta podem ficar em cache até 24 horas com a configuração predefinida.

Por isso, uma diferença isolada não demonstra que uma das ferramentas esteja a medir mal nem que toda a diferença seja espaço físico recuperável.

Localizar as tabelas grandes

Abra a base no phpMyAdmin e ordene as tabelas por tamanho. Reveja separadamente Data e Index. O valor apresentado como Overhead vem de DATA_FREE: representa espaço atribuído que não está ocupado, mas não demonstra por si só quanto pode ser devolvido ao sistema operativo. Num tablespace partilhado pode refletir espaço comum a várias tabelas.

Entre as tabelas que já vimos crescer de forma significativa estão wp_actionscheduler_actions e wp_options no WordPress, e ps_layered_filter_block no PrestaShop, embora deva identificar sempre que componente utiliza cada tabela antes de agir.

Antes de esvaziar ou eliminar uma tabela, identifique que aplicação a utiliza e gere uma cópia de segurança. O nome não basta para decidir que é dispensável.

Recuperar espaço sem danificar a base

A operação Optimize table só deve ser considerada depois de eliminar uma quantidade importante de dados e confirmar que a tabela pode ser reduzida. Em InnoDB costuma reconstruir a tabela, consome espaço temporário e gera uma carga considerável de disco. Muitas tabelas InnoDB admitem escritas durante parte do processo, embora sejam necessários bloqueios exclusivos breves e determinados índices ou configurações possam obrigar a copiar a tabela e bloqueá-la durante mais tempo. Se a tabela utilizar um tablespace partilhado, a operação não garante que o ficheiro físico do servidor diminua.

Primeiro:

  1. Gere uma cópia recente e confirme que a consegue recuperar.
  2. Elimine a partir da aplicação apenas os dados de que já não precisa.
  3. Verifique que existe espaço suficiente para a operação.
  4. Otimize apenas as tabelas afetadas.

Os valores ainda não foram atualizados

Espere pelo menos pelo recálculo seguinte do cPanel, que normalmente ocorre a cada quatro horas. No phpMyAdmin, as estatísticas do MySQL 8 podem demorar até 24 horas a mudar.

Não execute Optimize table apenas para forçar a atualização de um contador. Se a diferença continuar depois desses prazos, peça uma revisão indicando a base, os valores, os ecrãs onde aparecem e a hora da verificação. Será possível compará-los com a utilização real do servidor e determinar se convém atualizar a cache do cPanel sem pedir credenciais.

Compare sempre a mesma base, unidade e momento: MB e MiB não são equivalentes. Não some o espaço livre de um tablespace partilhado uma vez por cada tabela. Antes de uma reconstrução grande, combine com o suporte uma janela de trabalho e uma margem de espaço; um contador desatualizado não justifica arriscar uma base que funciona.

Também lhe pode ser útil

Algo não bate certo ou mudou? Diga-nos e revemos.