Guia de Limpeza: Como usar o PS Cleaner para reduzir o tamanho do seu banco de dados sem apagar pedidos.

O que o PS Cleaner realmente faz no banco de dados do PrestaShop e por que pode apagar pedidos

O PrestaShop Cleaner é um módulo projetado para limpar dados da loja — mas aqui está o problema real: ele não diferencia automaticamente dados “inofensivos” de dados críticos como pedidos, clientes e histórico de compras.

Na prática, isso significa que uma execução mal configurada pode apagar:

• pedidos (ps_orders)
• clientes (ps_customer)
• carrinhos (ps_cart)
• histórico de pedidos (ps_order_history)

E isso impacta diretamente o funcionamento da loja e a integridade do negócio.

Se sua loja está apresentando lentidão causada por dados acumulados, o PS Cleaner pode parecer uma solução rápida — mas sem controle técnico, ele vira um risco crítico.

Como o módulo atua diretamente nas tabelas do banco

O PS Cleaner executa operações diretas no banco MySQL, geralmente usando:

• DELETE FROM tabela
• TRUNCATE TABLE tabela

Exemplo real de operação:

TRUNCATE TABLE ps_connections;
TRUNCATE TABLE ps_guest;
TRUNCATE TABLE ps_cart;

🔎 Checkpoint de diagnóstico:

• Se você ver uso de TRUNCATE, significa remoção total da tabela
• Se houver DELETE sem WHERE, também é limpeza massiva

⚠️ Problema: algumas opções do módulo não deixam claro quais tabelas serão afetadas.

Diferença entre limpar dados de teste vs dados reais

O módulo foi originalmente pensado para ambientes de teste.

👉 Em staging, faz sentido limpar:

• pedidos fake
• clientes fictícios
• estatísticas de teste

👉 Em produção, isso é perigoso porque:

• os dados são reais
• não existe separação entre “teste” e “produção”
• qualquer limpeza pode afetar faturamento e histórico

🔎 Regra prática:

• Se sua loja já vendeu → trate TODO dado como crítico

Risco crítico: exclusão de pedidos, clientes e histórico

O maior erro ao usar o PS Cleaner é assumir que ele “só limpa lixo”.

Na prática, dependendo das opções:

• pedidos podem ser apagados
• clientes podem ser removidos
• histórico de vendas pode desaparecer

Exemplo de impacto real:

Backoffice:
Pedido #10234 → não encontradoFrontend:
Erro ao acessar histórico de pedidosLog:
SQLSTATE[23000]: Integrity constraint violation

Se isso acontecer, você já está lidando com um impacto crítico no banco.

Por que o banco de dados cresce no PrestaShop e impacta diretamente a performance

Antes de usar o PS Cleaner, você precisa entender o problema raiz: crescimento do banco.

O banco de dados do PrestaShop cresce continuamente por causa de:

• logs de navegação
• sessões de usuários
• carrinhos abandonados
• estatísticas
• conexões

Esse crescimento leva a um cenário clássico:

👉 consultas mais lentas
👉 uso maior de CPU
👉 aumento de latência

Isso está diretamente ligado ao impacto do banco na performance da loja.

Tabelas que mais acumulam dados (logs, conexões, carrinhos, estatísticas)

As principais responsáveis pelo crescimento são:

🔎 Checkpoint:

Execute:

SELECT table_name, data_length/1024/1024 AS MB
FROM information_schema.tables
WHERE table_schema = 'sua_base'
ORDER BY data_length DESC;

Se essas tabelas estiverem no topo → você tem um banco inchado.

Impacto do crescimento do banco no MySQL e tempo de resposta

Quando o banco cresce demais:

• consultas ficam mais lentas
• índices perdem eficiência
• aumenta o tempo de resposta (TTFB)

Exemplo de problema:

Slow query log:
Query_time: 5.832s
SELECT * FROM ps_connections WHERE date_add > NOW() - INTERVAL 1 DAY;

Isso indica um cenário clássico de MySQL lento no PrestaShop.

Sinais técnicos de banco inchado em produção

Você pode identificar rapidamente:

• admin lento ao abrir pedidos
• demora ao carregar relatórios
• aumento no uso de memória
• queries lentas no log

Se isso estiver acontecendo, provavelmente há consumo alto de memória causado pelo banco.

Quando usar o PS Cleaner sem comprometer pedidos reais da loja

O PS Cleaner só deve ser usado em cenários muito específicos.

Cenários seguros: ambiente de testes vs produção

✔ Seguro:

• ambiente staging
• loja recém-instalada
• dados de teste

❌ Risco alto:

• loja ativa
• histórico de pedidos real
• clientes cadastrados

Quando NÃO usar o PS Cleaner em loja ativa

Evite completamente se:

• você não tem backup
• não sabe quais tabelas serão afetadas
• não entende as opções do módulo

🔎 Se você precisa de limpeza em produção, o ideal é uma análise de desempenho antes de qualquer ação.

Critérios técnicos antes de executar a limpeza

Antes de usar:

• identificar tabelas grandes
• validar impacto
• entender dependências (foreign keys)

Exemplo:

SELECT COUNT(*) FROM ps_orders;

Se houver dados reais → não usar limpeza agressiva.

Checklist obrigatório antes de rodar o PS Cleaner em produção

Esse é o ponto mais importante do artigo.

Backup completo do banco de dados (dump SQL)

Execute:

mysqldump -u user -p db_name > backup.sql

🔎 Checkpoint:

• arquivo gerado?
• tamanho compatível com o banco?

Sem isso → não continue.

Validação de integridade das tabelas

Execute:

CHECK TABLE ps_orders;
CHECK TABLE ps_customer;

Se houver erro → pare imediatamente.

Teste em ambiente staging

Clone o ambiente:

• banco
• arquivos
• configurações

Teste tudo antes.

Identificação de tabelas críticas (orders, customers, carts)

Nunca limpe:

• ps_orders
• ps_customer
• ps_order_history

Essas tabelas são o core do negócio.

Como usar o PS Cleaner passo a passo sem apagar pedidos

Agora sim: execução segura.

Acessando o módulo no back office

Caminho:

• Módulos → PS Cleaner

Verifique as opções antes de qualquer ação.

Entendendo cada opção disponível no PS Cleaner

O módulo geralmente oferece:

• limpar catálogo
• limpar clientes
• limpar pedidos
• limpar estatísticas

⚠️ Nem todas são seguras.

Limpeza de dados de catálogo

Remove:

• produtos
• categorias
• atributos

✔ seguro apenas em staging

Limpeza de clientes e pedidos

⚠️ EXTREMAMENTE PERIGOSO

Remove:

• clientes
• pedidos
• histórico

Nunca usar em produção.

Reset de estatísticas

✔ geralmente seguro

Remove:

• dados analíticos
• conexões
• visitas

Configuração segura: o que desmarcar obrigatoriamente

Desmarcar:

• clientes
• pedidos
• catálogo

Manter apenas:

• estatísticas

Execução controlada da limpeza

Execute apenas uma ação por vez.

Após cada execução:

• verificar logs
• testar frontend
• validar admin

Se notar problemas → parar imediatamente.

O que cada opção do PS Cleaner remove no banco (análise técnica real)

Essa é a parte que diferencia um uso amador de um uso profissional.

Mapeamento das tabelas afetadas por cada ação

Diferença entre TRUNCATE vs DELETE nas operações

• TRUNCATE → remove tudo + reset de ID
• DELETE → remove dados mantendo estrutura

Exemplo:

TRUNCATE TABLE ps_cart;

Isso remove TODOS os carrinhos.

Impacto nas tabelas ps_orders, ps_customer e ps_cart

Se afetadas:

• pedidos somem
• clientes desaparecem
• histórico quebra

Isso pode gerar problemas após limpeza e inconsistências graves.

Simulação real de erro ao usar PS Cleaner incorretamente

Agora vamos para um cenário real de produção — exatamente o tipo de erro que acontece quando o PS Cleaner é executado sem controle.

Cenário: exclusão acidental de pedidos

Imagine a seguinte situação:

• Loja ativa com pedidos reais
• Usuário executa “limpeza completa”
• Opção de pedidos marcada por engano

Resultado imediato:

• pedidos desaparecem
• histórico de compras quebra
• relatórios ficam inconsistentes

🔎 Checkpoint de diagnóstico:

• pedidos sumiram do admin?
• clientes não conseguem ver histórico?

Se sim, o problema já está instalado.

Logs simulados de falha no banco

Após a limpeza, os logs começam a mostrar inconsistências.

[ERROR] Doctrine\DBAL\Exception\ForeignKeyConstraintViolationException
Cannot delete or update a parent row: a foreign key constraint fails

Outro exemplo comum:

[WARNING] Missing order reference in ps_order_history
Order ID 10234 not found

Esses logs indicam que dados relacionados foram removidos parcialmente.

SQLSTATE[23000]: Integrity constraint violation

Esse erro aparece quando há quebra de integridade relacional.

Exemplo real:

SQLSTATE[23000]: Integrity constraint violation: 1452
Cannot add or update a child row:
a foreign key constraint fails (`ps_order_detail`)

👉 Tradução prática:

• a tabela filha ainda existe
• a tabela pai foi apagada

Falhas de foreign key em ps_orders

Exemplo de diagnóstico:

SELECT *
FROM ps_order_detail od
LEFT JOIN ps_orders o ON od.id_order = o.id_order
WHERE o.id_order IS NULL;

Se essa query retornar dados:

👉 você tem registros órfãos (corrupção lógica)

Isso configura um cenário típico de falhas após limpeza.

Consequências no front-end e back office

Quando isso acontece, os efeitos são imediatos:

Front-end:

• clientes não veem pedidos
• histórico vazio
• erros ao acessar conta

Back office:

• pedidos desaparecidos
• relatórios inconsistentes
• falhas ao abrir detalhes

🔎 Checkpoint:

• erro ao abrir pedido específico → tabela corrompida
• pedido inexistente mas itens existem → integridade quebrada

Como diagnosticar se o PS Cleaner quebrou sua loja

Aqui começa o processo de análise técnica real.

Verificação de integridade das tabelas

Execute:

CHECK TABLE ps_orders;
CHECK TABLE ps_order_detail;
CHECK TABLE ps_customer;

Se retornar:

status: OK

→ estrutura intacta

Se retornar erro → problema físico ou lógico

Consultas SQL para identificar dados faltantes

Pedidos inexistentes:

SELECT COUNT(*) FROM ps_orders;

Se cair drasticamente → limpeza incorreta.

Verificar dados órfãos:

SELECT od.*
FROM ps_order_detail od
LEFT JOIN ps_orders o ON od.id_order = o.id_order
WHERE o.id_order IS NULL;

Verificar clientes:

SELECT COUNT(*) FROM ps_customer;

🔎 Checkpoint de diagnóstico:

• dados órfãos encontrados → integridade comprometida
• contagem reduzida → dados deletados

Sintomas: pedidos sumindo, erros no admin, inconsistências

Os sinais mais comuns:

• pedidos não aparecem
• erros ao abrir pedido
• inconsistência entre tabelas
• admin lento ou travando

Isso pode escalar para:

👉 impacto no backoffice
👉 gargalos no banco

Como recuperar dados após limpeza incorreta do PS Cleaner

Aqui não existe “jeitinho”. Ou você tem backup, ou entra em modo de contenção.

Restauração via backup SQL

Se você seguiu o checklist:

mysql -u user -p db_name < backup.sql

🔎 Checkpoint:

• pedidos voltaram?
• clientes restaurados?
• admin funcionando?

Se sim → recuperação completa.

Correção manual de tabelas relacionadas

Se não há backup completo:

• tentar reconstruir integridade
• remover dados órfãos

Exemplo:

DELETE FROM ps_order_detail
WHERE id_order NOT IN (SELECT id_order FROM ps_orders);

⚠️ Isso não recupera pedidos — apenas limpa inconsistências.

Quando a recuperação não é possível

Se:

• tabelas críticas foram truncadas
• não existe backup
• dados foram sobrescritos

👉 a recuperação é praticamente impossível

Nesse caso, o cenário vira:

• perda de histórico
• perda de dados comerciais
• impacto financeiro direto

Alternativas seguras ao PS Cleaner para reduzir o banco sem risco

Aqui está o caminho profissional.

Limpeza manual controlada via SQL

Ao invés de usar o módulo, você pode limpar apenas o necessário.

Exemplo:

DELETE FROM ps_connections
WHERE date_add < NOW() - INTERVAL 30 DAY;

✔ remove dados antigos
✔ mantém dados recentes
✔ não afeta pedidos

Otimização de tabelas específicas (logs, stats)

Exemplo:

OPTIMIZE TABLE ps_connections;
OPTIMIZE TABLE ps_guest;

Isso melhora performance sem remover dados críticos.

Uso de manutenção preventiva no banco

Uma estratégia sólida inclui:

• limpeza periódica de logs
• monitoramento de crescimento
• análise de queries

Se você não sabe por onde começar, uma análise de tabelas é essencial.

Impacto da limpeza do banco na performance da loja

Quando feita corretamente, a limpeza do banco gera ganhos reais.

Redução de tempo de resposta do MySQL

Após limpeza:

• queries mais rápidas
• menor uso de CPU
• menor latência

Melhoria no carregamento do back office

Sintomas resolvidos:

• admin rápido
• relatórios instantâneos
• menos travamentos

Isso reduz diretamente o admin lento por banco.

Relação entre banco otimizado e velocidade geral

Um banco otimizado impacta:

• tempo de carregamento
• conversão
• SEO

Se sua loja sofre com impacto do banco pesado, essa é uma das principais causas.

Erros comuns ao usar o PS Cleaner e como evitar

Rodar em produção sem backup

Erro clássico.

→ Resultado: perda irreversível

Limpar tabelas críticas por engano

Nunca marque:

• pedidos
• clientes

Não entender o impacto das opções

Cada opção = alteração direta no banco.

Ignorar testes prévios

Sempre testar em staging.

Se você não valida antes, pode enfrentar problemas após limpeza.

Estratégia segura de manutenção do banco no PrestaShop

Frequência ideal de limpeza

• logs: semanal ou mensal
• estatísticas: mensal
• tabelas críticas: nunca via Cleaner

Monitoramento do crescimento do banco

Execute regularmente:

SELECT table_name, data_length
FROM information_schema.tables
WHERE table_schema = 'db';

Boas práticas para evitar acúmulo de dados

• limitar retenção de logs
• limpar dados antigos manualmente
• evitar módulos que acumulam dados

Escolher corretamente addons evita riscos de módulos que poluem o banco.

Quando contratar otimização profissional para banco de dados PrestaShop

Cenários de risco alto ou banco crítico

• banco acima de 2GB
• loja lenta
• erros frequentes

Limitações do PS Cleaner em ambientes complexos

O módulo não:

• analisa impacto real
• entende dependências
• protege dados comerciais

Otimização avançada com análise técnica completa

Uma abordagem profissional inclui:

• análise de queries
• indexação
• tuning de MySQL

Exemplo de configuração real:

[mysqld]
innodb_buffer_pool_size=1G
query_cache_size=0
max_connections=200

💡 Se você precisa otimizar banco com segurança ou evitar riscos críticos, o ideal é atuar com especialistas.

Ou, se já houve falha, buscar suporte técnico especializado antes que o problema escale.