Índices transformam queries lentas em rápidas. Mas índices errados pioram performance. Aprenda quando criar, tipos corretos e trade-offs.

CrazyStack8 de fevereiro de 202610 min de leituracompartilharX LinkedIn WhatsApp

Conceitos Principais

Default. Melhor para equality e range (>, <, BETWEEN). Sorted data. 99% dos casos.

Generalized Inverted Index. Para arrays, JSONB, full-text search. Lento write, rápido read.

Índice em subset. WHERE status = 'active'. Menor, mais rápido. Queries específicas.

Índice em múltiplas colunas. Ordem importa. (a, b) ≠ (b, a). Leftmost prefix rule.

Passo a Passo

Identifique Slow Queries: pg_stat_statements: SELECT query, mean_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
Analyze Query Plan: EXPLAIN ANALYZE problema query. Seq Scan em tabela grande? Precisa índice.
Crie Índice: Single column: CREATE INDEX idx_users_email ON users(email). Multi-column: CREATE INDEX idx_orders_user_date ON orders(user_id, created_at).
Partial Index: CREATE INDEX idx_active_users ON users(email) WHERE status = 'active'. Menor, queries específicas mais rápidas.
Monitore Usage: pg_stat_user_indexes: SELECT indexrelname, idx_scan FROM pg_stat_user_indexes. idx_scan = 0? Índice não usado, delete.

• Index em foreign keys sempre

• WHERE clause columns

• JOIN columns

• ORDER BY columns (se frequente)

• Partial indexes para queries específicas

• Monitor index usage

• REINDEX periodicamente

• Index em todas as colunas (overkill)

• Multi-column na ordem errada

• Não monitorar usage (índices mortos)

• GIN quando B-tree suficiente

• Index em low-cardinality columns