José Antônio da Cunha IFRN Administração de Banco de Dados

Estudo de caso Imagine a seguinte situação: você acabou de concluir um relatório que demonstra a produtividade dos vendedores na tiragem de pedidos da empresa Northwind. Esse relatório sumariza os pedidos existentes na tabela Orders para um determinado vendedor. Após conclusão do relatório, você verifica no plano de execução que o índice existente EmployeeID não está sendo utilizado na seleção de pedidos de um vendedor e você decide investigar o porquê. O select executado na Figura 1 a seguir comprova que o índice Employeeid não está sendo selecionado, pois foi utilizado um clustered index scan em PK_Orders. Análise de desempenho do índice

Estudo de caso

Análise de desempenho do índice Você decide então analisar as estatísticas do índice pelo comando DBCC SHOW_STATISTICS, para verificar o histograma relacionado à coluna EmployeeID. Execute o comando: dbcc show_statistics (orders, employeeID) O resultado é apresentado na figura a seguir

Análise de desempenho do índice Resultado

Análise de desempenho do índice Com base nas estatísticas, constatamos que: A medida de seletividade da coluna Employeeid na tabela Orders nos informa que, dos 830 pedidos existentes, 43 (5% do total) foram realizados para o vendedor de código 9; A densidade para Employeeid informa que cada empregado possui média de 92 pedidos na tabela Orders (830* ).

Análise de desempenho do índice Por fim, deduz-se que: o índice não foi utilizado devido à baixa seletividade da coluna Employeeid. O custo da pesquisa com utilização do índice é maior que o processo de clustered index scan realizado na tabela. Podemos comprovar executado os comandos a seguir. Observe que ao forçar a escolha do índice o número de logical reads pulou de 27 para 91!

Análise de desempenho do índice Executando: set statistics io on select * from Orders where EmployeeID = 9 Obtem-se como resultado: (43 row(s) affected) Table 'Orders'. Scan count 1, logical reads 27, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Executando: set statistics io on select * from Orders with (index=EmployeeID) where EmployeeID = 9 Obtem-se como resultado: (43 row(s) affected) Table 'Orders'. Scan count 1, logical reads 91, physical reads 0, read- ahead reads 0, lob logical reads 0, lob physical reads 0, lob read- ahead reads 0.

Análise de desempenho do índice Considerando que não precisamos de toda informação contida no pedido, mas somente do número efetivo de pedidos para esse vendedor. Queremos saber quantos pedidos foram emitidos para o vendedor de código 9. Substituímos então o comando select * from Orders Where employeeid=9 pelo comando select count(*) from Orders where employeeid=9 e analisemos o plano de execução na figura a seguir:

Análise de desempenho do índice

Confirme a mudança no plano de execução, onde o Clustered Index Scan em PK_Orders foi substituído pelo Index Seek em Orders. EmployeeID. O comando count(*) com o filtro para employeeid=9 viabiliza a query com cobertura do índice EmployeeOrders.

CheckSum na otimização de índices A função CheckSum pode ser utilizada para criar chave hash em oposição a índices criados sob colunas char ou varchar. A vantagem de trabalhar com índice hash é a redução no tamanho da chave do índice. Diminuindo o tamanho da chave estaremos aumentando a densidade de linhas por página de índice, induzindo melhorias de desempenho. Nota: índices hash não podem ser utilizados em comparações envolvendo os operadores >, >=,.esse tipo de índice se presta somente para pesquisas igualitárias. Uma chave hash é utilizada como uma boa opção de desempenho na construção de um índice, sendo utilizado na substituição de longas chaves alfanuméricas por um único inteiro, gerado à partir de funções matemática.

CheckSum na otimização de índices A implementação dessa idéia envolve os seguintes passos: Devemos criar uma coluna calculada, utilizando a função CheckSum para geração automática do código hash. alter table customers add cs_CompanyName as Checksum(CompanyName) Devemos então criar um índice sobre essa coluna. create index ix_cs_CompanyName on Customers (cs_CompanyName) Podemos então realizar consulta sobre a coluna com o código hash da seguinte forma: select * from Customers where cs_CompanyName = Checksum('The Cracker Box') and CompanyName = 'The Cracker Box'

CheckSum na otimização de índices Observando as estatísticas do índice CompanyName dbcc showcontig(Customers,CompanyName)

CheckSum na otimização de índices Observando as estatísticas do índice CompanyName dbcc showcontig(Customers,ix_cs_CompanyName)

CheckSum na otimização de índices No comando select apresentado anteriormente, existe uma redundância na comparação com o nome do cliente, que é referenciado na linha da função CheckSum: “...Where cs_CompanyName=checksum(’The Cracker Box’)” “...AND CompanyName=‘The Cracker Box’...”. Esse procedimento é necessário já que existe a possibilidade dessa função gerar o mesmo código hash para inputs distintos, conforme indicação da própria Microsoft. Para evitar resultados indesejados, trabalha-se com a segunda confirmação. Índices hash não deve ser utilizado em comparações do tipo...where CompanyName like (‘The Craker%’).