wildcard Sql: sobrecarga de desempenho?

Question

Eu pesquisei esta pergunta e não consigo encontrar uma opinião consistente, ou muitas opiniões que são baseadas em dados sólidos. Eu simplesmente gostaria de saber se usando o curinga em uma instrução SQL SELECT incorre em sobrecarga adicional do que chamar cada item individualmente. Comparei os planos de execução de ambas em várias consultas de teste diferentes, e parece que as estimativas sempre ler o mesmo. É possível que alguma sobrecarga é incorrido em outro lugar, ou são eles realmente tratado de forma idêntica?

O que eu estou me referindo especificamente:

SELECT *

vs.

SELECT item1, item2, etc.

Answer 1

SELECT * FROM...

e

SELECT every, column, list, ... FROM...

irá realizar o mesmo, porque ambos são um unoptimised varredura

A diferença é:

• a pesquisa extra na sys.columns para resolver *
• o contrato / mudança de assinatura quando as alterações de esquema tabela
• incapacidade de criar um índice de cobertura. Na verdade, há opções de ajuste em tudo, realmente
• tem que atualizar vistas necessárias se não schemabound
• não pode índice ou schemabind uma visão usando *
• ... e outras coisas

Outros SO perguntas sobre o mesmo assunto ...

• Qual é a razão para não usar select *?
• Existe uma diferença betweeen Select * e selecione lista de cada col
• SQL Query Pergunta - Select * from exibir ou selecionar col1, col2 ... do ponto de vista
• “SELECT * da tabela ”vs‘seleccionar cola, colB, etc da tabela’comportamento interessante na SQLServer2005

Answer 2

Você select * from ... média em vez de select col1, col2, col3 from ...?

Eu acho que é sempre melhor para nomear a coluna e recuperar a quantidade mínima de informações, porque

• seu código irá funcionar independentemente da ordem física das colunas no db. A ordem das colunas não deve ter impacto na sua aplicação, mas será o caso se você usar *. Pode ser perigoso em caso de migração db, etc.
• se você nomear as colunas, o DBMS pode otimizar ainda mais a execução. Por exemplo, se houver um índice que contém todos os dados você está interessado em, a tabela não será acessado em tudo.

Se você quer dizer alguma coisa com "wildcard", apenas ignore a minha resposta ...

Answer 3

EDIT: Se você está falando sobre o cartão asterisco selvagem como em Select * From ... depois ver outras respostas ...

Se você está falando de curingas em cláusulas de predicado, ou outras expressões de consulta usando o operador Like, (_ , % ) como descrito abaixo, em seguida:

Isto tem a ver com se usando o Wildcard afeta se o SQL é "SARG-CAPAZ" ou não. Sargable, (-Search-argumento capaz) meios ou não de busca ou classificar argumentos da consulta podem ser usados ??como parâmetros de entrada para um índice existente. Se você prefixar o wild card para o início de um argumento

 Where Name Like '%ing'

Então não há nenhuma maneira de atravessar um índice no campo de nome para encontrar os nós que final em 'ing'.

Se otoh você acrescentar o curinga até o fim,

Where Name like 'Donald%' 

, em seguida, o otimizador pode ainda usar um índice na coluna nome, ea consulta é ainda SARG-able

Answer 4

Se que você chamar SQL carro selvagem é *. Isso não implica sobrecarga de desempenho por ela própria. No entanto, se a tabela é estendida você poderia encontrar-se campos recuperar você não pesquisa. Em geral, não sendo específico nos campos você pesquisar ou inserção é um mau hábito. Considere

insert into mytable values(1,2)

O que aconteceria se a tabela é estendido para três campos?

Answer 5

Pode não ser mais trabalho do ponto de vista plano de execução. Mas se você está buscando colunas que você realmente não precisa, que é a largura de banda de rede adicional a ser usado entre o banco de dados e sua aplicação. Além disso, se você estiver usando uma API cliente de alto nível que executa alguns trabalhos sobre os dados retornados (por exemplo, selectall_hashref do Perl) então essas colunas extra vai impor custo de desempenho no lado do cliente. Quanto? Depende.