Linq to SQL: selecione otimização

Em tabelas grandes no MSSQL; Selecionar colunas específicas resulta em maior velocidade da consulta. O mesmo se aplica ao Linq to SQL?

Isso seria:

var person = from p in [DataContextObject].Persons
             where p.PersonsID == 1
             select new { p.PersonsID, p.PersonsAdress, p.PersonsZipcode };

ser mais rápido que isso:

var person = from p in [DataContextObject].Persons
             where p.PersonsID == 1
             select p;

...?

6
adicionado editado
Visualizações: 7
fonte
ro ru fr es de zh hi bn ar

6 Respostas

Eu recomendo altamente LinqPad . É grátis e permite que você execute consultas LINQ dinamicamente. Quando você também pode olhar para o SQL que é gerado.

O que você verá é que a consulta LINQ traduzirá a primeira consulta para selecionar apenas essas colunas. Então é mais rápido.

6
adicionado
fonte

Se você estiver limitando o tamanho do conjunto de resultados selecionando apenas algumas colunas específicas, YES terá um efeito.

EDIT ading clarification from comment

Como isso é melhor, reduzirá o tamanho dos dados resultantes retornados do SQL E reduzirá o tamanho dos objetos usados ​​para armazenar os resultados na memória.

Isso se deve ao fato de que, no final, o LINQ to SQL gera SQL, portanto, os mesmos benefícios de desempenho existem.

4
adicionado
fonte
Ambos! O SQL Server responderá mais rapidamente, limitando os dados transmitidos, e reduzirá o tamanho da coleção contendo os resultados, reduzindo a memória
adicionado o autor Mitchel Sellers, fonte
Resultando em uma diminuição da alocação de memória? Ou maior velocidade?
adicionado o autor roosteronacid, fonte

Existem 3 aspectos com "mais rápido" aqui.

  1. menos dados transmitidos significa Mais rápido. Por outro lado, não conseguir isso significativamente mais rápido, a menos que você selecione mais de uma linha ou se sua pessoa contém algum outras colunas "pesadas" - longas varchars, imagem etc.

  2. como J. Curran apontou, menos memória alocada significa mais rápido. A mesma observação que em 1. aplica-se aqui.

  3. Sua consulta é executada mais rapidamente se você tem um índice contendo todos colunas selecionadas (ou anexadas a ele a partir do SQL Server 2005). Nesse caso, o mecanismo do SQL Server não precisa carregar a página com a linha na memória - se ainda não estiver lá.

Pessoalmente eu não me incomodaria tentar otimizar minhas consultas dessa maneira (a menos que, como eu disse, suas linhas contenham dados binários ou strings muito longas que você não precisa), parcialmente porque se você decidir mais tarde que gostaria de ter mais informações sobre essa pessoa selecionada, você precisaria alterar seu código de acesso ao banco de dados em vez de apenas acessar uma propriedade em sua classe POCO/anônima.

3
adicionado
fonte

Além do que os outros disseram, a nova estrutura sem nome será um objeto muito mais leve do que o objeto Person - seria muito mais rápido, mesmo se você selecionasse todas as colunas. (A pessoa tem o método/campos etc para suportar a gravação do objeto de volta ao banco de dados. O tipo não nomeado não.)

1
adicionado
fonte

Eu acho que o mesmo se aplica, porque LINQ to SQL converte as operações de consulta Linq para comandos SQL.

1
adicionado
fonte

Se você tiver colunas muito grandes, como binários e imagens, isso poderá fazer uma diferença significativa, e é por isso que o LINQ to SQL permite especificar o carregamento de atraso para determinadas colunas, para que você ainda possa selecionar objetos inteiros sem executar projeções 'selecionar novas' .

1
adicionado
fonte