Sql générique: surcharge de performance?

Question

J'ai recherché cette question sur Google et je n'arrive pas à trouver une opinion cohérente ou de nombreuses opinions basées sur des données solides. Je voudrais simplement savoir si l'utilisation du caractère générique dans une instruction SQL SELECT implique un surcoût supplémentaire par rapport à l'appel individuel de chaque élément. J'ai comparé les plans d'exécution des deux dans plusieurs requêtes de test différentes, et il semble que les estimations lisent toujours la même chose. Est-il possible que certains frais généraux soient engagés ailleurs ou sont-ils réellement traités de la même façon?

Ce que je fais référence à spécifiquement:

SELECT * 

contre

SELECT item1, item2, etc. 

Answer 1

SELECT * FROM... 

et

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

fait la même chose parce que les deux sont une analyse non optimisé

La différence est:

• la recherche supplémentaire dans sys.columns pour résoudre *
• le contrat/signature change lorsque le schéma de la table cha nges
• incapacité à créer un indice de couverture. En fait, aucune option de réglage du tout, vraiment
• doivent actualiser les vues nécessaires si non schemabound
• ne peut pas indexer ou schemabind une vue en utilisant *
• ... et d'autres choses

Autre SO questions sur le même sujet ...

• What is the reason not to use select * ?
• Is there a difference betweeen Select * and Select list each col
• SQL Query Question - Select * from view or Select col1,col2…from view
• “select * from table” vs “select colA,colB,etc from table” interesting behaviour in SqlServer2005

Answer 2

EDIT: Si vous parlez de l'astérisque wild card comme dans Select * From ... puis voir d'autres réponses ...

Si vous parlez de caractères génériques dans les clauses predicate ou d'autres expressions de requête utilisant l'opérateur Like, (_ , %) comme décrit ci-dessous, alors:

Cela a à voir avec si l'utilisation du caractère générique affecte si le SQL est "SARG-ABLE" ou non. SARGABLE, (Search-ARGument-able) signifie si les arguments de recherche ou de tri de la requête peuvent être utilisés comme paramètres d'entrée pour un index existant. Si vous préfixer la carte sauvage au début d'un argument

Where Name Like '%ing' 

Ensuite, il n'y a aucun moyen de traverser un index sur le champ de nom pour trouver les nœuds qui fin en « ing ».

Si Otoh vous ajoutez le caractère générique à la fin,

Where Name like 'Donald%' 

l'optimiseur peut encore utiliser un index sur la colonne de nom, et la requête est toujours SARG-mesure

Answer 3

Voulez-vous dire select * from ... au lieu de select col1, col2, col3 from ...?

Je pense qu'il est toujours préférable de nommer la colonne et récupérer la quantité minimale d'informations, parce que

• votre code fonctionnera indépendamment de l'ordre physique des colonnes dans la db. L'ordre des colonnes ne devrait pas avoir d'impact sur votre application, mais ce sera le cas si vous utilisez *. Cela peut être dangereux en cas de migration db, etc.
• Si vous nommez les colonnes, le SGBD peut optimiser davantage l'exécution. Par exemple, s'il existe un index contenant toutes les données qui vous intéressent, la table ne sera pas accessible du tout.

Si vous voulez dire quelque chose d'autre avec "wildcard", ignorez simplement ma réponse ...

Answer 4

Si vous appelez voiture sauvage SQL est *. Cela n'implique pas de surcharge de performance par soi-même. Cependant, si la table est étendue, vous pourriez vous retrouver à récupérer des champs que vous ne cherchez pas. En général, ne pas être spécifique dans les champs que vous recherchez ou insérez est une mauvaise habitude. Tenez compte

insert into mytable values(1,2) 

Qu'arrive t-il si la table est étendue à trois champs?

Answer 5

Il ne peut pas être plus de travail du point de vue du plan d'exécution. Mais si vous récupérez des colonnes dont vous n'avez pas réellement besoin, c'est une bande passante réseau supplémentaire qui est utilisée entre la base de données et votre application. De même, si vous utilisez une API client de haut niveau qui effectue un certain travail sur les données renvoyées (par exemple, selectall_hashref de Perl), ces colonnes supplémentaires imposeront des coûts de performance du côté client. Combien? Dépend.