Dicas de Performance: Clustered Index Scan

Quando falamos de banco de dados, um dos assuntos de maior significância, ou o de maior significância, está relacionado a performance. Performance é uma área muito extensa, que precisa ser estudada com afinco. " Afinal, quando desenvolvemos ou rodamos alguma consulta não queremos que a transação fique lenta! Correto? ".

Por isso, resolvi trazer através desse singelo artigo uma dica de Tuning, que pode ajudar muito na hora de melhorar a performance das consultas no seu banco de dados. Esse é um dos principais cenários, que vai encontrar quando olhar para Performance em banco de dados. Estou me referindo ao Operador Clustered Index Scan! Mais, que operador é esse?

É um operador lógico e físico de planos de execução. O plano de execução é o resultado gerado pelo Query Optimizer, quando executamos uma consulta. através dele conseguimos saber o que, e onde podemos melhorar a performance da consulta. O Clustered Index Scan lê todas as linhas do índice clustered, retornando somente as linha que atenderem predicado opcional, um exemplo o WHERE.

Exemplo 1:

Na imagem acima, é possível notar a existência do operador citado anteriormente, no cenário temos um SELECT, bem simples, retornando o campo ID, NOME, e CODIGO, da tabela CRYPTO, onde o NOME é igual a Bitcoin. O operador em questão está onerando nosso ambiente de banco de dados deixando a consulta mais lenta. como mostram as imagens abaixo:

Passando o mouse sobre o operador é possível notar que são lidas, 16 milhões de linhas para retornar somente 1 linha, também conseguimos perceber um aumento no custo de I/O, e CPU. Isso para o banco de dado é extremamente custoso, a depender da carga executada na instrução, podendo travar todo o ambiente.

E agora como podemos tratar esse operador? Simples! Podemos criar uma índice do tipo NONCLUSTERED, para nossa tabela CRYPTO, pegando nosso campo PREDICATE, priorizando assim, o nível de seletividade da nossa consulta. Fazendo um INCLUDE nos demais campos, exceto nosso campo ID que é a nossa PK(Primary Key), e já faz parte do nosso índice CLUSTERED.

Exemplo 2:

Como citado anteriormente vamos criar o índice abaixo para nossa tabela:

CREATE NONCLUSTERED INDEX IX_CRYPTO ON CRYPTO (NOME) INCLUDE (CODIGO, PRECO) WITH(DROP_EXISTING = ON) --SE EXISTIR DROP E RECRIE FAZENDO AS ALTERAÇÕES.

É possível notar a diferença de forma visual, e agora, qual impacto isso causou, ou qual benefício isso trouxe ao nosso SQLServer?

Ao passarmos o mouse sobre nosso operador agora está sendo realizado um Index Seek (usa a capacidade de busca de índices para recuperar linhas de um índice não clusterizado. O mecanismo de armazenamento usa o índice para processar somente as linhas que atendem ao predicado SEEK:() ). Resumindo, agora está sendo lida 1 linha, e retornando 1 linha, e nosso custo de I/O, e CPU reduziram significativamente, melhorando a performance e o tempo de execução da nossa consulta.

Espero ter ajudo! Muito obrigado, por fazer parte da minha rede de contatos no Linkedin, e breve teremos mais dicas, contem sempre comigo!

See you later!!!

Referências:

CREATE INDEX

Operadores Físicos e Lógicos de Plano de Execução