Filtrar por texto pode destruir a performance do SQL

Se você já trabalhou com views grandes, dashboards BI ou análises em bases volumosas, provavelmente já sofreu com consultas lentas, timeouts ou relatórios demorando minutos (ou horas) para carregar.
Uma vez, durante uma análise real, me deparei exatamente com isso, um simples filtrar por texto no SQL — e a solução foi mais simples do que parecia.

Às vezes, trocar o campo certo no filtro faz toda a diferença.

Índice

🔍 O cenário real

Recebi um script que utilizava uma view grande como fonte principal para um dashboard BI. Essa view processava entre 1 e 10 milhões de registros, com vários SELECTs internos, campos derivados e múltiplas referências à mesma tabela.

O filtro aplicado originalmente era assim:

WHERE status_processo= 'pendentes'

O problema: essa consulta demorava e frequentemente resultava em timeout.

🧠 O que estava causando lentidão?

O campo status_processo não possuía índice.
Ou seja, toda vez que essa consulta rodava, o Oracle precisava varrer milhões de linhas comparando texto — processo conhecido como full scan.

Já a coluna codigo_status, equivalente numérica do mesmo campo, era indexada.

⚙️ Como identifiquei o gargalo

Pesquisei as estruturas da view
Validei índices pelo dicionário de dados (USER_IND_COLUMNS, DBA_INDEXES)
Comparei o custo no EXPLAIN PLAN

O plano deixava claro: o filtro por texto estava exigindo um TABLE ACCESS FULL, enquanto o código poderia sair de um INDEX RANGE SCAN — muito mais rápido.

🚀 A solução aplicada

Substituí o filtro por texto:

WHERE status_processo= 'Pendentes'

por:

WHERE codigo_status = 4

📌 Resultado:

Antes: timeout
Depois: retorno em ~3 minutos (normal dado o tamanho da view)

🧪 Antes vs Depois (simplificado)

Situação	Tipo de filtro	Tipo de leitura	Tempo	Explain Plan
Antes	Texto (`descricao_status`)	FULL TABLE SCAN	Timeout	Custo alto
Depois	Numérico (`codigo_status`)	INDEX RANGE SCAN	~3min	Custo reduzido

💡 Macetes TecProdutiva

✔️ Sempre prefira chaves numéricas em filtros.
✔️ Evite comparar strings grandes, especialmente em views.
✔️ No Oracle, EXPLAIN PLAN e AUTOTRACE são seus melhores amigos.
✔️ Antes de pensar em criar índice, verifique quais já existem.
✔️ Views complexas + filtros inadequados = dashboard lento.

❌ Erro comum + solução

❌ Erro	Filtrar por campos descritivos porque parecem mais intuitivos
✅ Correto	Filtrar por campos indexados (geralmente chaves numéricas ou IDs)

🚀 Checklist final

✔️ Use EXPLAIN PLAN quando algo estiver lento
✔️ Prefira filtros indexados (normalmente numéricos)
✔️ Evite WHERE texto = ... quando não houver índice
✔️ Teste em ambiente controlado antes de aplicar ao dashboard