Filtro não é índice

E ai, galera! Hoje venho com este post em homenagem ao meu amigo Thiago Carlos de Alencar que é especialista em Performance (o cara é bom bagarai!) daquele bancos de dados azul que só funciona com mouse (rsrsrss). Como o título bem sugere, vamos falar sobre a construção de índices no Oracle. Bom, como todos nós sabemos, índices são caminhos de acessos utilizados para percorrer uma pequena quantidade dos registros de uma tabela ao invés de ler todos os registros desta. Índices, compostos ou não, são preferencialmente criados em colunas que possuem uma alta seletividade – ou que são chaves em join com outros índices -, por isso normalmente são criados em colunas com valores únicos, sendo a melhor forma de construção destes.

Porém existem situações em que a query é efetuada justamente para retornar estas chaves únicas e, em muitos os casos, os filtros utilizados nesta query nem sempre possuem uma boa seletividade. É justamente ai que normalmente dá merda… Segundo o manual da Oracle, quando uma tabela possui colunas que são constantemente apresentadas como filtros em queries porém estas colunas não apresentam uma boa seletividade, é aconselhado que seja construído um índice composto contendo esta e outras colunas buscando-se melhorar a seletividade do índice para otimizar a pesquisa.

Se você não for utilizar índices bitmaps devido à grande quantidade de DMLs na tabela dos seu sistema, por favor, não crie índices aleatoriamente apenas baseado nas colunas que aparecem no filtro das queries do sistemas. Pois em casos de índices com baixa seletividade, quando a engine do Oracle buscar um registro em um índice para futuramente acessar a tabela, fatalmente irá ocorrer no acesso à um único bloco deste segmento, inibindo muito a performance caso a sua pesquisa deva retornar uma alta quantidade de registros. Neste caso, o correto seria acessar vários blocos em um único I/O através de um table full scan ou index fast full scan (utilizando do db_mutiblock_read_count), onde serão lidos todos os registros daquela tabela e futuramente descartados aqueles que não tem interesse.

Lembrando que no Oracle nós temos os seguintes tipos de acesso à índices:

  1. INDEX UNIQUE SCAN – este tipo de acesso é efetuado em uma chave única retornando quase que sempre um único registro;
  2. INDEX RANGE SCAN – o mais comum acesso à um único ou pequeno conjunto de registros em índices, o acesso à tabela é efetuado através do índice;
  3. INDEX RANGE SCAN DESCENDING – quando os dados são retornados de forma descendente, o inverso do acesso normal à um índice;
  4. FAST FULL INDEX SCAN – utilizando quando toda as achas do índice são pesquisados em uma query de forma e não é necessitado a ordenação, ou seja, são lidos todos os blocos folhas do índices para acessar a tabela;
  5. FULL INDEX SCAN – leitura total do índice, normalmente acontece quando é requerido o resultado da query de forma ordenada;
  6. INDEX MIN/MAX SCAN – quando na query é pesquisado o maior ou menor valor do índice;
  7. INDEX SKIP SCAN – o índice é acessado indiferente da primeira coluna que compõe o índice, exemplo, o índice é pesquisa pelas coluna B porém o índice foi construído através das colunas A e B, ou seja, dessa forma, a colunas B é acessada mesmo que a coluna A não seja utilizada;
  8. INDEX JOIN SCAN – a chave utilizada entre as tabelas é chave no índice;
  9. BITMAP INDEX SCAN – diferente do índice B-Tree padrão e disponível apenas na versão Enterprise Edition, o acesso a este índice que é implementado através de um mapa de bits e utilizado normalmente para ambientes DW – pois a alta utilização de DMLs prejudicará muito a performance com relação a manutenção deste índice. A pesquisa nas colunas normalmente acontece pela baixa seletividade e alta cardinalidade dos resultados. Exemplo, SEXO = ‘F’. Também são muito utilizados em DWs queries para transformação em estrela;

Sendo assim, analise cuidadosamente a criação de um índice, em relação à esta ou estas colunas, leve em consideração a distribuição de dados , valores distintos, quantidades de registros nulos, a capacidade de mutação da coluna devido aos DMLs e preferencialmente utilize colunas que são chaves em joins com outras tabelas.

Por hoje é só negadis!

4 thoughts on “Filtro não é índice

  1. Show de bola Carlao! Estava atoa na net e resolvi passar por aqui e ler o seu post! Parabens cara e foi um grande prazer trabalhar ao seu lado meu nobre! Abs!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s