1) Montar o grafo sem pensar em cardinalidade e caminhos

A maioria dos problemas de performance no Neo4j começa antes do Cypher: começa na modelagem.

Quando você cria relacionamentos sem entender quantas conexões cada nó terá (cardinalidade), o grafo vira um “corredor
infinito” para consultas que fazem navegação. Isso faz o otimizador perder opções e a execução explodir em número de caminhos.

• Use relacionamentos com semântica clara (o que significa “seguiu”, “pertence”, “comprou”, etc.).
• Evite modelar tudo como propriedade quando a pergunta natural é “quais nós estão conectados por quê?”.
• Limite expansões em consultas: navegação sem controle (ex.: “expandir tudo até N” sem filtro) é receita para lentidão.
• Revise padrões de acesso: se você frequentemente consulta por um “subgrafo”, represente isso no modelo.

2) Ignorar índices e constraints (e depois culpar o Cypher)

Sem índices e constraints, o Neo4j tende a fazer varreduras caras para encontrar nós e validar consistência.

Isso é especialmente crítico quando você faz lookup por propriedades (por exemplo, buscar por id, email,
sku ou slug). O custo vira proporcional ao tamanho do grafo — e cresce rápido.

• Crie constraints de unicidade quando um campo deve ser único.
• Crie índices para propriedades usadas em filtros frequentes.
• Garanta consistência de tipo: coleções e formatos diferentes podem impedir o uso de padrões esperados.
• Evite depender de valores “quase únicos” (ex.: nome) quando você precisa buscar com precisão.

// Unicidade para identificar um nó de forma determinística
CREATE CONSTRAINT pessoa_id_unique IF NOT EXISTS
FOR (n:Pessoa)
REQUIRE n.id IS UNIQUE;

// Índice para filtros frequentes (quando não é unicidade)
CREATE INDEX pessoa_email_index IF NOT EXISTS
FOR (n:Pessoa)
ON (n.email);

// Use id em queries com lookup para reduzir custo
MATCH (p:Pessoa {id: $id})
RETURN p;

3) Escrever consultas “bonitas”, mas que geram trabalho demais

A consulta pode parecer correta, mas ainda assim fazer trabalho redundante ou gerar resultados intermediários gigantes.

Alguns anti-padrões comuns:

• Carregar grande volume sem necessidade: retornar tudo (“RETURN n”) quando você só precisa de campos específicos.
• Duplicar trabalho com joins implícitos: usar múltiplas expansões sem filtros bem posicionados.
• Fazer ORDER BY/LIMIT no lugar errado: se você ordena cedo demais, pode ordenar muitos candidatos.
• Usar agregações sem entender o agrupamento: collect() e agregações podem crescer muito em cardinalidade.
• Ignorar EXPLAIN/PROFILE: se você não mede, você “chuta” o que está caro.

4) Atualizar dados de forma insegura (modelagem + transações)

Consistência e manutenção são parte da engenharia: sem cuidado, você cria duplicidade, registros órfãos e atualizações quebradas.

Erros clássicos acontecem em operações de escrita:

• Criar nós duplicados ao importar/atualizar sem constraints e sem estratégia de idempotência.
• Remover relacionamentos sem limpar dependências, deixando “nós soltos” que poluem consultas futuras.
• Fazer operações massivas em uma única transação: isso aumenta risco de tempo limite e pressão no sistema.
• Usar SET para “atualizar tudo” sem controlar quais campos mudam e sem considerar concorrência.
• Não definir claramente o que é dado vs. o que é estado: às vezes o mesmo relacionamento vira “histórico” e “estado” ao mesmo tempo.

Uma prática saudável é planejar suas escritas para serem previsíveis: nó único por identificador, relacionamentos com semântica,
e updates que não dependem de “sorte”.