Skip Navigation Links



Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de UsuĆ”rios
»CĆ©lulas AcadĆŖmicas«

Micro de mulher
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
FaƧa um pequeno teste com 10 questƵes de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programaĆ§Ć£o com nosso treinamento on-line de lĆ³gica de programaĆ§Ć£o
.:.
Veja nosso calendƔrio de treinamentos
Gostou da PƔgina?
Então

para um amigo!

Pesquisa personalizada
Pesquisar Dicas:

 






Por que Querys similares podem possuir planos de execução tão diferentes ?
Por estranho que pareça esta pergunta, isso realmente pode acontecer. Quando duas querys simulares ou identicas possuem performance muito deferente, precisamos comparar os planos de execução das querys para resolver esse mistério.

Vamos ver um exemplo utilizando querys por data na tabela Orders do banco northwind, ora usando uma variável como argumento de busca, ora um valor literal. Veja as querys :

-- Query 1: Retorna 5 linhas, usando uma variável no argumento de busca (SARG)


DECLARE @odate AS DATETIME
SET @odate = '19980506'
SELECT * FROM Orders
WHERE OrderDate >= @odate
GO

-- Query 2: Retorna todas as linhas, usando uma variável no argumento de busca (SARG)

DECLARE @odate AS DATETIME
SET @odate = '19960101'
SELECT * FROM Orders
WHERE OrderDate >= @odate
GO

-- Query 3: Retorna 5 linhas, usando um valor literal no argumento de busca (SARG)
-- argument (SARG)

SELECT * FROM Orders
WHERE OrderDate >= '19980506'
GO

As querys 1 e 2 usam uma variável local no SARG (Search Argument). Já a query 3 usa uma referencia ao mesmo valor que as querys 1 e 2 porém na forma de Hard-Code. As querys 1 e 3 devolvem o mesmo resultado, mas como você vê, cada uma contém um plano de execução diferente.

Execute as 3 querys anteriores no banco northwind para ter certeza que você conhece o retorno das 3 querys e como cada uma delas é diferente. Agora execute as querys novamente, mas ative o Statistics IO no inicio do Batch :


SET STATISTICS IO ON

Apesar da query 1 e query 3 retornarem o mesmo resultado, query 1, que usa uma variável local, requer 21 leituras lógicas, enquanto que a query 3, que usa o valor em hard code, requer apenas 10 leituras lógicas. Query 1 usa o mesmo número de leituras que a query 2, independente do fato da query 2 retornar muito mais registros.

Execute as querys mais uma vez e olhe para o SHOWPLAN para ver como o SQL Server executa cada query. Você pode ver o plano de execução a partir do query analyzer usando "Set showplan_text ON" no inicio do batch e fazendo "set showplan_text off" no final.

Você verá que as querys 1 e 2 possuem planos de execução identicos : Para executar essas querys, o SQL Server faz um scan na primary key, que é a coluna orderID, que a clausula where não usa para nada. Já para executar a query 3 o SQL Server usa o índice OrderDate (definido na coluna orderdate) fazendo um index seek, o que explica a diferença no número de leituras lógicas entre as querys 1 e 3

Mas afinal, por que o SQL server escolhe planos de execução tão diferentes para querys que parecem identicas ? O SQL Server não conhece o valor da variável local da query 1 quando ele otimiza a query, por isso tem que adivinhar que valor deve ser. Indices nonclustered tipicamente não são úteis se temos a necessidade de retornar uma grande porcentagem de linhas da tabela. E, apesar da query 1 retornar apenas 5 linhas, o SQL Server não sabe disso, por isso assume que a query vá retornar um terço da tabela, porque está sendo usando o operador > . O indice OrderDate não será eficiente se a query returnar muitas linhas, então o SQL Server não o utiliza. Na query 3, porém, o SQL Server conhece precisamente quantas linhas a query irá retornar porque o SARG é literal. E sabendo que a query vai retornar apenas 5 linhas, o SQL server utiliza o índice nonClustered.

Uma fora de garantir que o SQL Server conheça o valor da variável em tempo de compilação - e possa assim usar o índice correto - é encapsular a query em uma stored procedure. Você precisa utilizar a opção With Recompile para criar a stored procedure se o melhor query plan pode variar conforme os valores de entrada :


CREATE PROC DateRangeTest
@odate AS DATETIME
WITH RECOMPILE
AS
SELECT * FROM Orders
WHERE OrderDate >= @odate
GO


Agora rode as seguintes instruções e compare o número de leituras de cada uma :

EXEC DateRangeTest '19980506'
-- returns 5 rows
EXEC DateRangeTest '19960101'
-- returns 830 rows

Você verá que a primeira chamada da procedure, que retorna apenas 5 linhas, consegue utilizar o índice OrderDate, enquanto que a segunda chamada continua a utilizar o scan no indice clustered porque retorna um volume de linhas muito grande.





Envie seus comentįrios sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentįrios nesta pįgina

Veja abaixo os comentários já enviados :

Nome : Jose E-Mail : jtpneto@ibest.com.br
nao entendi se esse codigo é usado em delphi ou nao!
Nome : Dennes Torres E-Mail : dennes@bufaloinfo.com.br

Este artigo é sobre SQL Server, não fala sobre nenhuma linguagem de programação especificamente, apenas sobre o banco de dados.

Nome : Ricardo S. E-Mail : ricardo_sant_anna@hotmail.com
Na verdade contstatei que a query que retorna mais linhas é a que usa index clustered ( cost = 100%) , e a que retorna somente 5 linhas é q usa index non-clustered ( cost = 300 ).
Nome : Renato E-Mail : renatosos@hotmai.com
Alguem pode me dizer p/ que serve uma QUERY PLAN ?
Nome : Luciana Farias Pinto E-Mail : luciana.farias@ccsservices.com.br
Não é bem um comentário, preciso urgente fazer alguns cursos:
Vb06
SQL
Programação em Java
Esses cursos que quero tem que começar do zero e ir até o mais avançado...
Gostaria de receber um retorno.
Att.
Luciana
Nome : Erivelton Rosante E-Mail : eriva_br@hotmail.com
Legal o artigo, só naum entendi esta opção "WITH RECOMPILE" usada na PROC???
Nome : Thiago E-Mail : thiaguim10@hotmail.com
Ótimo artigo.... obrigado!
Nome : Rogério Barbosa E-Mail : rogerio@juba.com.br
valeu pelo artigo, estava tentando identificar este problema a varios dias e não encontrava nd.. vc me salvou..rsrs.. mas seguinte, tenho dois servidores com os mesmos dados nas tabelas, utilizando os mesmo indices também, em um deles a consulta utilizando variaveis faz um scan table e no outro também utilizando variaveis é realizado o Index SEEK. Os dois servidores utilizam a mesma versao do SQL Server.. vc pode me ajudar ?

muito obrigado
continue postando, vc ajuda mta com isso, acho q salva o emprego de muitas tbm..rsrs

Grande Abraço...
Nome : qsNvrMv6G6 E-Mail : u0ukc4mhasq@outlook.com
coupons and discount for ehtiyevrng Hey there! I just wanted to ask if you ever have any trouble with hackers? My last blog (wordpress) was hacked and I ended up losing several weeks of hard work due to no back up. Do you have any methods to protect against hackers?

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::



Quer saber mais?
Faça um curso na Búfalo Informática, Treinamento e Consultoria e
Prepare-se para o Mercado!
Veja o que a Búfalo tem para você.

ļæ½ BĆŗfalo InformĆ”tica, Treinamento e Consultoria - Rua Ɓlvaro Alvim, 37 Sala 920 - CinelĆ¢ndia - Rio de Janeiro / RJ
Tel.: (21)2262-1368 (21) 9240-5134 (21) 9240-7281 e-Mail:
contato@bufaloinfo.com.br