Changements de schéma
- Extraire par ordre --- Si le code extrait la colonne # comme moyen d’obtenir les données, une modification du schéma entraînera un réajustement des numéros de colonne. Cela va gâcher l'application et de mauvaises choses vont arriver.
- Extraire par nom: si le code extrait une colonne par son nom
foo, et qu'une autre table de la requête ajoute une colonne foo, la façon dont cela est traité peut entraîner des problèmes lors de la tentative d'obtention de la colonne de droite foo .
Dans les deux cas, une modification de schéma peut entraîner des problèmes lors de l'extraction des données.
Déterminez ensuite si une colonne en cours d'utilisation est supprimée de la table. Le select * from ...fonctionne toujours mais des erreurs quand essayant de tirer les données sur l'ensemble des résultats. Si la colonne est spécifiée dans la requête, la requête sera erreur en donnant au lieu une indiciation claire quant à quoi et où est le problème.
Surcharge de données
Certaines colonnes peuvent avoir une quantité importante de données associées. Sélectionner en arrière *va extraire toutes les données. Oui, voici que varchar(4096)c'est sur 1000 lignes que vous avez sélectionnées en vous donnant une possibilité supplémentaire de 4 mégaoctets de données dont vous n'avez pas besoin, mais qui sont quand même envoyées sur le réseau.
En ce qui concerne le changement de schéma, varchar peut ne pas exister lors de la création initiale de la table, mais maintenant, il existe.
Défaut de transmettre l'intention
Lorsque vous sélectionnez retour *et obtenez 20 colonnes mais n'en avez besoin que de 2, vous ne communiquez pas l'intention du code. En regardant la requête qui fait, select *on ne sait pas quelles sont les parties importantes de celle-ci. Puis-je modifier la requête pour qu'elle utilise plutôt cet autre plan afin de l'accélérer en n'incluant pas ces colonnes? Je ne sais pas parce que l'intention de ce que la requête retourne n'est pas claire.
Regardons quelques violons SQL qui explorent un peu plus ces changements de schéma .
Tout d’abord, la base de données initiale: http://sqlfiddle.com/#!2/a67dd/1
DDL:
create table one (oneid int, data int, twoid int);
create table two (twoid int, other int);
insert into one values (1, 42, 2);
insert into two values (2, 43);
SQL:
select * from one join two on (one.twoid = two.twoid);
Et de retour les colonnes que vous obtenez sont oneid=1, data=42, twoid=2et other=43.
Maintenant, que se passe-t-il si j'ajoute une colonne à la première table? http://sqlfiddle.com/#!2/cd0b0/1
alter table one add column other text;
update one set other = 'foo';
Et comme avant mes résultats de la même requête sont oneid=1, data=42, twoid=2et other=foo.
Un changement dans l'une des tables perturbe les valeurs de a select *et soudainement votre liaison de 'other' à un int va lancer une erreur et vous ne savez pas pourquoi.
Si au lieu de cela votre instruction SQL était
select
one.oneid, one.data, two.twoid, two.other
from one join two on (one.twoid = two.twoid);
Le changement de table 1 n'aurait pas perturbé vos données. Cette requête s'exécute de la même manière avant et après le changement.
Indexage
Lorsque vous faites un, select * fromvous tirez toutes les lignes de toutes les tables qui correspondent aux conditions. Même les tables qui vous intéressent vraiment. Cela signifie que plus de données sont transférées, mais un autre problème de performances se cache plus loin dans la pile.
Index. (lié à SO: Comment utiliser index dans une instruction select? )
Si vous extrayez un grand nombre de colonnes, l'optimiseur de plan de base de données peut ne pas utiliser un index, car vous devrez quand même extraire toutes ces colonnes. Cela prendrait plus de temps d'utiliser l'index, puis toutes les colonnes de la requête. que ce serait juste de faire un scan complet de la table.
Si vous êtes sélectionnez le, par exemple, le nom d'un utilisateur (que vous faire beaucoup et ont donc un indice sur elle), la base de données peut faire un balayage d' index unique ( index postgres wiki uniquement scan , mysql analyse complète tableau vs complet scan d'index , Index seule analyse: Éviter le tableau d' accès ).
Il y a pas mal d'optimisations pour ne lire que des index, si possible. Les informations peuvent être extraites plus rapidement sur chaque page d’index, car vous en tirez moins aussi - vous n’ajoutez pas toutes les autres colonnes pour le select *. Il est possible qu'une analyse d'index seulement renvoie des résultats de l'ordre de 100 fois plus rapidement (source: Select * is bad ).
Cela ne veut pas dire qu'une analyse d'index complète est excellente, c'est toujours une analyse complète - mais c'est mieux qu'une analyse de table complète. Une fois que vous commencez à rechercher toutes les conséquences select *négatives sur les performances, vous continuez à en trouver de nouvelles.
Lecture connexe