Avantage en termes de performances lorsque la requête SQL est limitée par rapport à l’appel de la ligne entière?

Question

Quel est l'avantage en termes de performances de sélectionner uniquement le champ obligatoire dans la requête au lieu d'interroger la ligne entière? Par exemple, si j'ai une rangée de 10 champs mais que je n'ai besoin que de 5 champs à l'écran, est-il utile d'interroger uniquement ces 5? Quel est l’avantage en termes de performances de cette limitation par rapport au risque de devoir ajouter ultérieurement des champs dans la requête SQL si nécessaire?

Answer 1

Ce n’est pas seulement l’aspect données supplémentaires que vous devez prendre en compte. La sélection de toutes les colonnes annulera l'utilité de recouvrir les index, car une recherche par signet dans l'index ou la table en cluster sera nécessaire.

Answer 2

Cela dépend du nombre de lignes sélectionnées et de la quantité de mémoire utilisée par ces champs supplémentaires. Cela peut être beaucoup plus lent si plusieurs champs text / blobs sont présents ou si plusieurs lignes sont sélectionnées.

En quoi l'ajout de champs plus tard est-il un risque? La modification des requêtes pour répondre aux exigences changeantes fait naturellement partie du processus de développement.

Answer 3

Le seul avantage que je connaisse de nommer explicitement vos colonnes dans votre instruction select est que, si une colonne utilisée par votre code est renommée, votre instruction select échouera avant votre code. Mieux encore, si votre instruction select est dans un proc, votre proc et le script de base de données ne seront pas compilés. Ceci est très pratique si vous utilisez des outils tels que VS DB edition pour compiler / vérifier les scripts de base de données. Sinon, la différence de performance serait négligeable.

Answer 4

Le nombre de champs récupérés est un effet de second ordre sur les performances par rapport à la surcharge de la requête SQL elle-même - sortir du processus, sur le réseau, vers un autre hôte et éventuellement sur le disque de cet hôte prend beaucoup plus de cycles que de pelleter quelques octets supplémentaires de données.

Évidemment, si les champs supplémentaires incluent un blob de mégaoctets, l’équation est biaisée. Mais, selon mon expérience, le temps de traitement de la transaction est du même ordre, voire supérieur, à celui des données récupérées. Je me souviens vaguement d'il y a de nombreuses années qu'un "vide" La demande NOP TNS correspond à environ 100 octets sur le fil.

Answer 5

Si le serveur SQL n'est pas la même machine à partir de laquelle vous interrogez, la sélection des colonnes supplémentaires transfère davantage de données sur le réseau (ce qui peut être un goulot d'étranglement), sans oublier qu'il doit lire davantage de données à partir du disque. , allouez plus de mémoire pour conserver les résultats.

Il n’ya pas une chose qui poserait un problème en soi, mais additionnez les choses et elles causent toutes des problèmes de performances. Chaque petit geste compte lorsque vous avez beaucoup de requêtes ou de données.

Je suppose que le risque serait que vous deviez ajouter les champs à la requête ultérieurement, ce qui signifierait peut-être changer de code, mais vous devrez généralement ajouter plus de code pour gérer les champs supplémentaires de toute façon.