Regra

Evitar redundante base de dados redundantes.
A sobreposição de de base de dados índices desperdiçam
armazenamento e abrandam lentas escreve.

Linguagens suportadas: SQL

Introdução

Índices redundantes ocorrem quando múltiplos índices cobrem as mesmas colunas ou quando um índice é um prefixo de outro. Cada índice consome espaço em disco e deve ser atualizado em operações de INSERT, UPDATE e DELETE. Uma tabela com cinco índices sobrepostos em colunas semelhantes paga a penalidade de desempenho de escrita cinco vezes, enquanto apenas um índice seria suficiente para otimização de leitura.

Por que isso importa

Impacto no desempenho: Todo índice retarda as operações de escrita porque o banco de dados deve atualizar todos os índices quando os dados mudam. Índices redundantes multiplicam esse custo sem fornecer benefícios de consulta. Uma tabela com três índices redundantes em user_id triplica o overhead de escrita enquanto apenas um índice é utilizado.

Custos de armazenamento: Índices consomem espaço em disco proporcional aos tamanhos das colunas indexadas e à contagem de linhas. Índices redundantes desperdiçam armazenamento que poderia ser usado para dados reais ou índices úteis. Tabelas grandes com índices desnecessários podem desperdiçar gigabytes de armazenamento.

Complexidade de manutenção: Mais índices significam mais objetos para monitorar, analisar e manter. Administradores de banco de dados gastam tempo otimizando índices que não fornecem valor. Planejadores de consulta têm mais opções para avaliar, potencialmente escolhendo planos de execução subótimos.

Exemplos de código

❌ Não-conforme:

-- Índices redundantes na tabela de usuários
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_email_status ON users(email, status);
CREATE INDEX idx_users_created ON users(created_at);
CREATE INDEX idx_users_created_status ON users(created_at, status);

-- Os índices de coluna única são redundantes porque
-- os índices compostos podem atender às mesmas consultas

Por que está errado: O índice no e-mail é redundante porque idx_users_email_status começa com e-mail e pode lidar com consultas filtrando apenas por e-mail. Da mesma forma, idx_users_created é redundante com idx_users_created_status. Cada inserção ou atualização nesta tabela atualiza quatro índices quando dois seriam suficientes.

✅ Compatível:

-- Índices otimizados na tabela de usuários
CREATE INDEX idx_users_email_status ON users(email, status);
CREATE INDEX idx_users_created_status ON users(created_at, status);

-- Índices compostos podem atender a consultas em suas colunas de prefixo
-- Consultas apenas por email usam idx_users_email_status
-- Consultas apenas por created_at usam idx_users_created_status

Por que isso importa: Dois índices compostos atendem a todos os padrões de consulta, eliminando a redundância. Consultas filtrando por e-mail sozinhas usam o primeiro índice, e consultas que filtram por created_at sozinhas usam o segundo. O desempenho de escrita melhora porque apenas dois índices precisam de atualizações em vez de quatro.

Conclusão

Audite seus índices de banco de dados regularmente para identificar os redundantes. Remova índices que são prefixos de outros índices ou que duplicam a cobertura. Índices compostos podem atender a consultas em suas colunas principais, eliminando a necessidade de índices de coluna única separados na maioria dos casos.