DESAFIO DO GORDO – Porque não um Table Scan?

Pessoal,

Hoje quero propor um desafio relacionado ao otimizador de consultas do SQL Server.

Vamos criar a seguinte tabela:

USE [tempdb]
GO
CREATE TABLE Aluno
(CodAlu INT, NomeAlu VARCHAR(30) NOT NULL)
GO
INSERT Aluno (CodAlu, NomeAlu)
VALUES
(1,’Vitor’),
(2,’Maria’),
(3,’Jorge’)
GO

Ao realizarmos a consulta “SELECT * FROM Aluno WHERE NomeAlu IS NOT NULL” temos o seguinte plano de execução:

PlanoExec1

Agora quero que expliquem o motivo da consulta “SELECT * FROM Aluno WHERE NomeAlu IS NULL” não executar um TABLE SCAN e sim um operador chamado CONSTANT SCAN:

PlanoExec2

Coloquem suas respostas nos comentários e não deixe de inscrever-se no blog para receber todos os posts.

Grande abraço.

 

Anúncios
  1. Elifas Horacio
    06/05/2014 às 14:27

    Pelo fato de nao conseguir indexar um valor null.. neste caso.. minha sugestao seria criar uma constraint default preenchendo algum dado no lugar do null e na hora da busca, colocar no where a condição da constraint.

  2. 06/05/2014 às 14:44

    Boa informação. Precisamos nos manter atualizados.

  3. 06/05/2014 às 14:59

    Vitor, seria porque na fase inicial quando o optimizer tenta encontrar contradições para salvar recursos ele identifica que o predicado com o valor null é uma total contradição em relação a coluna NomeAlu não aceitar null .

  4. Paolo
    07/05/2014 às 10:06

    Deduzindo, acho que pelo fato da coluna ser not null, na segunda consulta ele praticamente invalida o where, e trás todos os dados

  5. Douglas Tassio
    07/05/2014 às 10:12

    Talvez seja por que ele já efetuou a pesquisa (table scan) na tabela uma vez e na segunda vez, ele manteve a pesquisa (constant scan) e trouxe o resultado.

  6. Fabricio Nascimento Pires
    10/05/2014 às 13:50

    Acredito que seja porque o campo NomeAlu contém a regra de NOT NULL e por esse motivo ao realizar o SELECT colocando a condição IS NULL na clausula WHERE, o otimizador entende que há uma contradição e por esse motivo a consulta se torna simples.

    Diferente do TABLE SCAN, que como definido no primeiro SELECT, o otimizador escolheu realizar um SCAN de toda a tabela, ou seja, linha a linha até encontrar o resultado requerido.

    Acredito que seja isso.

    Abraços!

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: