Tuning - Plano de Execução - Parte 3 Olá! Continuaremos nosso estudo sobre planos de execução de queries discutindo um pouco mais sobre o processo de BookMark Lookup, representado pelo símbolo Como vimos no artigo anterior, a query abaixo – que utiliza o índice EmployeeId , criado sobre a coluna de mesmo nome – ilustra essa situação .
Agora uma questão: Como melhorar a performance dessa query ? Você poderia responder: “Mas porque melhorar a performance de uma query que roda tão rápido ? “. Pois é. As tabelas possuem um sério “defeito” – elas costumam crescer rapidamente e os problemas de performance sismam em crescer com elas. Pensando com bom senso, se a tabela possui um número reduzido de linhas ( e “reduzido” também é um conceito muito relativo) você dificilmente precisará otimizar acesso. O que precisamos entender é como identificar objetos no plano que podem causam perda de performance e o que exatamente podemos fazer para contornar esse tipo de problema. Existem duas coisas que fazem com que o otimizador selecione um índice para resolver uma query:
Concluímos que quanto mais próximo um índice estiver desses dois princípios - seletividade e cobertura -, maiores serão suas chances de utilização. Vamos aplicar esses princípios na otimização da query. O primeiro passo será substituir o asterisco pelas colunas que realmente serão utlizadas . Nesse caso, as colunas necessárias são CustomerId e OrderDate . Vamos substituir e analisar o comportamento do plano: O plano permaneceu inalterado porque as colunas CustomerId e OrderDate não fazem parte do índice, sendo necessário resgatá-las da página de dados. Vamos criar outro índice, acrescentando as colunas CustomerId e OrderDate: create index ix_EmployeeId on Orders (EmployeeId, CustomerId, OrderDate) Compare agora o plano de execução com os anteriores : o processo de BookMark Lookup sumiu !
Muitas vezes um índice não é utilizado porque, além de possuir baixa seletividade, não fornece a cobertura necessária para as colunas presentes na query . Índices desse tipo, além de ineficientes, são um contra-pêso nos processos de modificação de dados porque irão requerer atualização adicional nos processos de insert, update e delete. Vamos fazer outro teste “dropando” o índice criado anteriormente ... drop index Orders.ix_employeeId ... e executando a query abaixo: O plano de execução continua SEM o processo de BookMark Lookup, mesmo referenciando a coluna OrderId que NÃO faz parte da estrutura do índice EmployeeId. Ora, se a coluna OrderId não pertence ao índice, não seria necessário um acesso adicional à página de dados ? A resposta é Não. Quer saber porquê ? Então não perca a continuação dessa matéria. Um forte abraço a todos! Paulo Ribeiro
|
|
|||||||||||||
Todos
os direitos reservados: DevMedia Group |