Ordem de Índices Multicoluna

Índices compostos B-tree honram as regras de prefixo esquerdo: o planejador pode usar o índice apenas enquanto os predicados corresponderem às colunas líderes na ordem no PostgreSQL 18.4.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

-- Bom para: WHERE tenant_id = ? AND status = ? AND created_at > ?
CREATE INDEX events_tenant_status_created_idx
ON events (tenant_id, status, created_at);

Quando usar isso: Consultas filtram pela coluna B, mas o índice lidera com a coluna A e os planos mostram seq scan apesar de um índice existente.

Exemplo de Trabalho

CREATE TABLE events (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  tenant_id int NOT NULL,
  status text NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);
 
CREATE INDEX events_wrong_order_idx ON events (status, tenant_id, created_at);
CREATE INDEX events_right_order_idx ON events (tenant_id, status, created_at);
 
INSERT INTO events (tenant_id, status, created_at)
SELECT
  (i % 100) + 1,
  CASE WHEN i % 20 = 0 THEN 'failed' ELSE 'ok' END,
  now() - (random() * interval '30 days')
FROM generate_series(1, 400000) AS i;
 
ANALYZE events;
 
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE tenant_id = 7 AND status = 'failed' AND created_at >= now() - interval '1 day';

Remova o índice errado em implantações reais após verificar se o índice correto foi escolhido.

O que isso demonstra:

• Colunas de igualdade antes de colunas de intervalo
• tenant (seletivo no contexto da aplicação) geralmente lidera status
• O nome do índice em EXPLAIN confirma qual índice composto está sendo usado

Mergulho Profundo

Como Funciona

• Regra: índice utilizável para predicados em prefixos esquerdos de (col1), (col1, col2), (col1, col2, col3).
• Pular a coluna líder (WHERE status = ? apenas) não pode usar (tenant_id, status) eficientemente.
• Misturar igualdade e intervalo: coloque igualdades primeiro, intervalo por último (tenant_id =, status =, created_at >).
• Direção de ordenação: alinhe DESC com ORDER BY comum para evitar ordenações.

Heurísticas de Ordenação

Notas SQL

-- Dois índices quando duas formas de consulta dominam
CREATE INDEX events_tenant_created_idx ON events (tenant_id, created_at);
CREATE INDEX events_status_created_idx ON events (status, created_at)
WHERE status IN ('failed', 'retry');

Armadilhas

• Um mega-índice para todos os relatórios - Não serve bem a nenhuma consulta. Correção: 2-3 compostos comprovados mais índices parciais.
• Coluna líder de baixa cardinalidade - status primeiro quando sempre combinado com tenant_id. Correção: Coloque tenant_id à esquerda, a menos que um índice parcial corrija a fatia de status.
• Coerção implícita de tipo - Incompatibilidade de tipo do predicado pula o índice. Correção: Combine o tipo da coluna em SQL e ORM.
• OR entre colunas - A ordem do índice não pode salvar OR entre caminhos não prefixados. Correção: Reescrever com UNION ALL ou múltiplos índices parciais.
• Índices duplicados com colunas permutadas - Amplificação de escrita dobrada. Correção: Auditoria de índice redundante.

Alternativas

FAQs

Relacionado

• Noções Básicas de Design de Índices - Design geral
• Índices Duplicados e Redundantes - Limpeza
• Estatísticas Estendidas - ndistinct composto
• Índices Parciais e de Cobertura - Variantes

Versões do Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.