A sua base de dados do PrestaShop não para de crescer: que tabelas pode esvaziar e quais não

A cópia de segurança da base de dados demora cada vez mais, o alojamento avisa que se está a aproximar do limite de espaço e algum ecrã do back-office está lento. Vê o que ocupa tanto e descobre que não são os produtos nem as encomendas: são tabelas com nomes como connections, guest ou log, com milhões de linhas que ninguém alguma vez olhou.

Vamos ver que tabelas crescem sozinhas, para que servem e o que se pode limpar sem perder nada importante.

Primeiro, meça

Antes de apagar o que quer que seja, obtenha a lista de tabelas ordenadas por tamanho. No phpMyAdmin ou na ferramenta de base de dados do seu alojamento vê-se diretamente; também com uma consulta a information_schema.TABLES filtrando pelo nome da sua base de dados e ordenando por DATA_LENGTH + INDEX_LENGTH. Quase sempre, poucas tabelas concentram a maior parte do espaço.

Nos exemplos uso o prefixo ps_, que é o predefinido; o seu pode ser outro.

As que crescem a cada visita

ps_connections e ps_connections_source

Registam cada visita à loja e de onde vinha o visitante. São usadas pelas estatísticas internas do PrestaShop (visitantes, origens de tráfego). Com tráfego de bots, crescem muito depressa.

Podem ser limpas? Sim, as linhas antigas, se não usa as estatísticas internas de visitas ou lhe basta um período recente. Perderá o histórico de visitas desses módulos de estatísticas, não encomendas nem clientes.

ps_guest

Um registo por cada visitante identificado através de um cookie, com dados técnicos do navegador. Está relacionado com as ligações e com os carrinhos.

Pode ser limpa? Com cuidado: só os visitantes que não estão associados a nenhum cliente nem a nenhum carrinho com encomenda. Apagar visitantes a eito deixa referências partidas.

ps_pagenotfound, ps_statssearch e semelhantes

Páginas não encontradas e pesquisas do motor de pesquisa interno, se tiver ativos os respetivos módulos de estatísticas. São úteis para detetar ligações partidas e perceber o que procuram os seus clientes, mas as linhas de há anos raramente o são.

Podem ser limpas? Sim, as antigas. Antes, se lhe interessar, exporte um resumo das pesquisas mais frequentes.

Os carrinhos

ps_cart e ps_cart_product guardam todos os carrinhos criados, também os que nunca deram origem a uma encomenda. Numa loja com anos de vida são centenas de milhares.

• Os carrinhos com encomenda nunca se tocam. A encomenda aponta para o seu carrinho, e muitos ecrãs, faturas e módulos precisam dele.
• Os carrinhos sem encomenda recentes também não: são os de clientes que estão a comprar agora ou que podem voltar, e os que os módulos de recuperação de carrinhos abandonados usam.
• Os carrinhos sem encomenda muito antigos podem ser eliminados, juntamente com as suas linhas. Confirme antes que nenhum módulo os usa como referência (regras de carrinho associadas, carrinhos guardados, orçamentos).

Os registos

ps_log

É o registo que vê em Parâmetros avançados → Registos. É alimentado pelo núcleo e pelos módulos. Um módulo que escreve uma mensagem em cada visita pode enchê-lo em semanas.

Pode ser limpa? Sim, o back-office tem uma opção para o esvaziar. Mas antes veja o que o enche: se uma mensagem se repete milhares de vezes, há algo para corrigir, e esvaziar a tabela só esconde o sintoma.

ps_mail

O registo dos e-mails enviados, se tiver ativado guardar os e-mails. Útil para confirmar se um e-mail saiu, mas contém endereços de clientes.

Pode ser limpa? Sim, e convém fazê-lo com um período de conservação definido. Guardar indefinidamente que e-mails foram enviados a quem não acrescenta nada e é mais um dado pessoal.

Tabelas de módulos

Muitos módulos têm os seus próprios registos: chamadas a APIs, sincronizações, avisos. Alguns purgam-nos sozinhos e outros não. Reveja as tabelas grandes com prefixo de módulo e a configuração de cada um antes de apagar à mão.

Em que não se mexe

Também não convém mexer em:

• Clientes e moradas, exceto através de um procedimento de apagamento de dados a pedido do titular, que tem de respeitar o que deve conservar por obrigação legal.
• Preços específicos e regras de carrinho expiradas sem confirmar antes se alguma é usada como modelo ou se um módulo depende delas.
• Tabelas de configuração com valores que não reconhece: costumam ser de módulos desinstalados, mas às vezes são de módulos ativos com nomes pouco claros.

Se o problema são as encomendas

Às vezes a tabela grande é a das encomendas, e é lógico: uma loja com anos de atividade acumula muitas. Aí não se trata de apagar, mas de arquivar: tirar as encomendas antigas das tabelas ativas para que o back-office trabalhe com menos linhas, conservando-as completas e recuperáveis.

Como fazer a limpeza

1. Cópia completa da base de dados, verificada.
2. Teste numa cópia da loja as consultas de limpeza e confirme que tudo continua a funcionar: encomendas, carrinhos de clientes, estatísticas.
3. Apague por lotes, não milhões de linhas numa única consulta, que pode bloquear a tabela e a loja.
4. Otimize as tabelas depois de apagar muito, para recuperar o espaço em disco.
5. Corrija a causa: desative estatísticas que não usa, trave os bots que geram milhares de ligações, corrija o módulo que enche o registo.
6. Agende a limpeza para que daqui a uns anos não volte a ser precisa uma grande limpeza.

Como resolver no PrestaShop

O RKR Order Archive retira das tabelas ativas as encomendas mais antigas do que o número de dias que definir (180 por predefinição), nos estados que escolher, e guarda-as completas em tabelas de arquivo: linhas, histórico, faturas, pagamentos, devoluções, notas de crédito, carrinho e mensagens. Tem modo de simulação para ver quantas encomendas e linhas moveria sem mexer em nada, cron com token, relatório por e-mail, restauro exato com o mesmo número de encomenda e apagamento definitivo bloqueado por predefinição. Não arquiva a encomenda com o último número de fatura, guia de remessa ou encomenda, para que o PrestaShop não repita a numeração. Para as restantes tabelas (ligações, visitantes, carrinhos, registos), com um pacote de horas de suporte da Rekire medimos a sua base de dados, preparamos a limpeza numa cópia e deixamo-la agendada.