O select * ainda é um grande não-não no SQL Server 2012?

Nos dias passados, era considerado um grande não-não-fazer select * from tableou select count(*) from tablepor causa do desempenho atingido.

Esse ainda é o caso nas versões posteriores do SQL Server (estou usando 2012, mas acho que a pergunta se aplicaria a 2008 - 2014)?

Edit: Como as pessoas parecem estar me classificando um pouco aqui, eu estou olhando para isso de um ponto de vista acadêmico / de referência, não se é a coisa "certa" a ser feita (o que é claro que não é)

Se você SELECT COUNT(*) FROM TABLEque retorna apenas uma linha (a contagem), é relativamente leve e é o caminho para obter esse dado.

E SELECT *não é um não-não físico, pois é legal e permitido.

No entanto, o problema SELECT *é que você pode causar muito mais movimentação de dados. Você opera em todas as colunas da tabela. Se você SELECTincluir apenas algumas colunas, poderá obter a resposta de um índice ou índices, o que reduz a E / S e também o impacto no cache do servidor.

Portanto, Sim , isso é recomendado como prática geral, pois desperdiça seus recursos.

O único benefício real SELECT *é não digitar todos os nomes de colunas. Porém, no SSMS, você pode usar arrastar e soltar para obter os nomes das colunas na sua consulta e excluir os que você não precisa.

Uma analogia: se alguém usa SELECT *quando não precisa de todas as colunas, também usaria SELECTsem uma WHERE(ou alguma outra cláusula limitadora) quando não precisa de todas as linhas?

Além da resposta já fornecida, sinto que vale a pena ressaltar que os desenvolvedores geralmente são preguiçosos ao trabalhar com ORM modernos, como o Entity Framework. Enquanto os DBAs tentam evitar o máximo possível SELECT *, os desenvolvedores geralmente escrevem o equivalente semanticamente equivalente, por exemplo, no c # Linq:

var someVariable = db.MyTable.Where(entity => entity.FirstName == "User").ToList();

Em essência, isso resultaria no seguinte:

SELECT * FROM MyTable WHERE FirstName = 'User'

Há também uma sobrecarga adicional que ainda não foi coberta. Esses são os recursos necessários para processar cada coluna em cada linha para o objeto relevante. Além disso, para cada objeto mantido na memória, esse objeto deve ser limpo. Se você selecionou apenas as colunas necessárias, poderia economizar facilmente mais de 100mb de ram. Embora não seja uma quantidade enorme por si só, é o efeito cumulativo da coleta de lixo, etc., que é o custo do lado do cliente.

Então, sim, para mim, pelo menos, é e sempre será um grande não. Também precisamos educar sobre os custos "ocultos" de fazer isso mais também.

Termo aditivo

Aqui está uma amostra de extração apenas dos dados necessários conforme solicitado nos comentários:

var someVariable = db.MyTable.Where(entity => entity.FirstName == "User")
                             .Select(entity => new { entity.FirstName, entity.LastNight });

Desempenho: Uma consulta com SELECT * provavelmente nunca será uma consulta de cobertura ( explicação simples de conversa , explicação de estouro de pilha ).

Prova de futuro: sua consulta pode retornar todas as sete colunas hoje, mas se alguém adicionar cinco colunas no próximo ano, em um ano sua consulta retornará doze colunas, desperdiçando IO e CPU.

Indexação: se você deseja que seus modos de exibição e funções com valor de tabela participem da indexação no SQL Server, esses modos de exibição e funções devem ser criados com a ligação de esquema, o que proíbe o uso de SELECT *.

Prática recomendada : nunca use SELECT *no código de produção.

Para subconsultas, eu prefiro WHERE EXISTS ( SELECT 1 FROM … ).

Edit : Para abordar o comentário de Craig Young abaixo, usar "SELECT 1" em uma subconsulta não é uma "otimização" - é para que eu possa ficar na frente da minha classe e dizer "não use SELECT *, sem exceções! "

Sobre a única exceção que consigo pensar é onde o cliente está executando algum tipo de operação de tabela dinâmica e exige todas as colunas presentes e futuras.

Posso aceitar uma exceção envolvendo CTEs e tabelas derivadas, embora deseje ver planos de execução.

Observe que considero COUNT(*)uma exceção a isso porque é um uso sintático diferente de "*".

No SQL Server 2012 (ou qualquer versão a partir de 2005), o uso SELECT *...é apenas um possível problema de desempenho na instrução SELECT de nível superior de uma consulta.

Portanto, NÃO é um problema nas Views (*), nas subconsultas, nas cláusulas EXIST, nas CTEs, nem nas SELECT COUNT(*)..etc., etc. Observe que isso provavelmente também é verdade para Oracle e DB2, e talvez PostGres (não tenho certeza) , mas é muito provável que ainda seja um problema em muitos casos para o MySql.

Para entender o porquê (e por que ainda pode ser um problema em um SELECT de nível superior), é útil entender por que houve um problema, porque usar SELECT *..significa significa " retornar TODAS as colunas ". Em geral, isso retornará muito mais dados do que você realmente deseja, o que obviamente pode resultar em muito mais IO, tanto em disco quanto em rede.

O que é menos óbvio é que isso também restringe os índices e planos de consulta que um otimizador de SQL pode usar, porque sabe que, em última análise, deve retornar todas as colunas de dados. Se você souber antecipadamente que deseja apenas determinadas colunas, geralmente poderá usar planos de consulta mais eficientes aproveitando os índices que possuem apenas essas colunas. Felizmente, existe uma maneira de saber isso com antecedência, que é para você especificar explicitamente as colunas que deseja na lista de colunas. Mas quando você usa "*", está renunciando a isso em favor de "apenas me dê tudo, vou descobrir o que preciso".

Sim, também há uso adicional de CPU e memória para processar todas as colunas, mas é quase sempre menor em comparação com essas duas coisas: a significativa largura de banda extra de disco e rede necessária para as colunas que você não precisa, e ter que usar menos plano de consulta otimizado porque precisa incluir todas as colunas.

Então o que mudou? Basicamente, os Otimizadores de SQL incorporaram com êxito um recurso chamado "Otimização de Colunas", o que significa apenas que agora eles podem descobrir nas subconsultas de nível inferior se você realmente usará uma coluna nos níveis superiores da consulta.

O resultado disso é que não importa mais se você usar 'SELECT * ..' nos níveis inferior / interno de uma consulta. Em vez disso, o que realmente importa é o que está na lista de colunas do SELECT de nível superior. A menos que você use SELECT *..na parte superior, ela deve assumir novamente que você deseja TODAS as colunas e, portanto, não pode empregar otimizações de coluna efetivamente.

(* - observe que há um problema de ligação menor e diferente no Views, *onde eles nem sempre registram as alterações nas listas de colunas quando "*" é usado. Existem outras maneiras de resolver isso e isso não afeta o desempenho.)

Há mais um pequeno motivo para não usar SELECT *: se a ordem das colunas retornadas mudar, seu aplicativo será interrompido ... se você tiver sorte. Caso contrário, você terá um bug sutil que pode passar despercebido por um longo tempo. A ordem dos campos em uma tabela é um detalhe de implementação que nunca deve ser considerado pelos aplicativos, pois a única vez que fica visível é se você usar a SELECT *.

É fisicamente e problematicamente permitido o uso select * from table, no entanto, é uma má ideia. Por quê?

Primeiro de tudo, você descobrirá que está retornando colunas que não precisa (recursos pesados).

Em segundo lugar, demorará mais tempo em uma tabela grande do que nomear as colunas porque, quando você seleciona *, na verdade você seleciona os nomes das colunas no banco de dados e diz "me dê os dados que estão associados às colunas que têm nomes nessa outra lista . " Embora isso seja rápido para o programador, imagine fazer essa pesquisa no computador de um banco que pode ter literalmente centenas de milhares de pesquisas em um minuto.

Em terceiro lugar, fazer isso realmente torna mais difícil para o desenvolvedor. Com que frequência você precisa alternar entre SSMS e VS para obter todos os nomes de colunas?

Em quarto lugar, é um sinal de programação preguiçosa e não acho que qualquer desenvolvedor queira essa reputação.

Pode ser um problema se você colocar o Select * ...código em um programa, porque, como apontado anteriormente, o banco de dados pode mudar com o tempo e ter mais colunas do que o esperado quando você escreveu a consulta. Isso pode levar à falha do programa (na melhor das hipóteses) ou o programa pode seguir seu caminho alegre e corromper alguns dados, porque está analisando valores de campo que não foram escritos para manipular. Em resumo, o código de produção SEMPRE deve especificar os campos a serem retornados no SELECT.

Dito isso, tenho menos problemas quando Select *faz parte de uma EXISTScláusula, pois tudo o que será retornado ao programa é um booleano indicando o sucesso ou falha do select. Outros podem discordar dessa posição e eu respeito a opinião deles. PODE ser um pouco menos eficiente para codificar Select *do que para codificar 'Selecionar 1' em uma EXISTScláusula, mas não acho que exista perigo de corrupção de dados, de qualquer maneira.

Muitas respostas select *estão erradas, por isso abordarei quando achar que está certo ou pelo menos OK.

1) Em EXISTS, o conteúdo da parte SELECT da consulta é ignorado, para que você possa escrever SELECT 1/0e não cometerá erros. EXISTSapenas verifica se alguns dados retornariam e retornariam um booleano com base nisso.

IF EXISTS(
    SELECT * FROM Table WHERE X=@Y
)

2) Isso pode iniciar uma tempestade de fogo, mas eu gosto de usar select *os gatilhos da minha tabela de histórico. Por select *isso, evita que a tabela principal obtenha uma nova coluna sem adicionar a coluna à tabela de histórico e também gera um erro imediatamente quando inserido / atualizado / excluído na tabela principal. Isso evitou várias vezes em que os desenvolvedores adicionaram colunas e esqueceram de adicioná-lo à tabela de histórico.