Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Rapidite d un requete SQL
Slu
je sais que le fait de faire des jointures est specialement "lourd"... j aimerais savoir si pour une requete qui disons retourne 50 record ... est ce que le temps de cette requete change beaucoup en fonction du nombre de record au deaprt dans la table ?
Et a partir de quelle "taille" peut on considerer qu une table est "lourde" ?
thx @+
Les jointures bien faites ça ralentit pas tant que ça.
Les performances dépendent probablement aussi de ton pc, de la base de données utilisées, des index et donc pas seulement du nombre d'enregistrements.
Il faut surtout veiller à choisir le bon type de jointure et si besoin à mettre en place des index.
Sur de petites tables les index n'ont aucun intérêt, mets-en sur les tables qui ont quelques milliers de lignes au moins...
La taille critique pour une table je ne la connais pas, moi je m'inquièterais pas trop pour ça, si tu optimises tes requêtes tu n'auras pas de problème je crois. A moins que tu comptes gérer des bases de données avec plusieurs centaines de milliers de lignes peut-être.
Je n'ai pas énormément d'expérience sur les grandes tables remarque, j'espère ne pas me tromper!
Les indexs sur les grandes tables sont importants a conditions d'etre définis correctement (ils doivent etre définis sur des colonnes ramenant entre 0 et5% des lignes totales : ca ne sert a rien de mettre un index sur un champ boolean par exemple).
Lorsque tu fais des sous requetes ou jointures, tu dois essayer d'etre le plus selectif possible, comme ca, le produit cartésien obtenu est moins important donc plus rapide a gérer.
Ensuite des fonctions de tris sur des grosses tables mal indexées sont des catastrophes.
J'espere que ceci pourra t'aider
Bon courage
Et pour un table simple avec juste une cle primaire ....
Est ce que la rapidite d un simple select va dependre du nombre d enregistrement total dans la table ou du nombre d enregistrement resultant du select ?
thx
Visiblement vous ne savez pas grand chose... Car un SGBDR (la lettre R signifie Relationnel donc induit les jointures) est spécialement conçu pour mettre en relation des données, c'est à dire faire des jointures...je sais que le fait de faire des jointures est specialement "lourd"...
Ce n'est donc pas lourd, c'est justement ce qu'il y a de plus performant dans un SGBDR bien fait !
Encore faut il éviter les nombreuses erreurs de "design" de bases de données que commettent les jeunes développeurs, par exemple en faisant des clefs sur 3 colones ou en utilisant des VARCHAR ou des GUID comme clef !!!
Ce qui est lourd c'est le volume des données à brasser. Plus le volume des données est important plus la requête sera longue.
C'est que ce je montre à longueur de journées dans les cours d'optimisation que je donne dans différents instituts de formation professionnelles...
Ni l'un ni l'autre : le nombre de lignes (la notion d'enregistrement propre au fichier n'existe pas dans les SGBDR) n'a aucune signification car une ligne peut être composée d'un seul octet ! C'est donc le nombre d'octets lu, traité et rapporté qui est significatif. Or un modèle parfaitement normalisé (donc beaucoup de relations) sera plus performant qu'un modèle mono table...Est ce que la rapidite d un simple select va dependre du nombre d enregistrement total dans la table ou du nombre d enregistrement resultant du select ?
A +
Si c'est SQL Server qui devient poussif a gerer des cles avec 3 colonnes, il suffit de changer de SGBD pour continuer a faire du design dans l'etat de l'art !!
Je ne peux qu'approuver cette affirmation ... (même si la leçon est un peu sévère ...)Envoyé par SQLpro
Sur le site où je travaille (une grande Banque française ...), il n'est pas rare de trouver des tables de plusieurs dizaines de millions de lignes, voire plusieurs centaines, la plus grande devant dépasser, me semble-t-il, le milliard ...
C'est vrai que nous disposons de "gros" ordinateurs (Mainframe z/OS) et de "gros" SGBD (DB2 for z/OS) ...
C'est justement pour cela qu'on utilise des SGBDR, car si c'etait uniquement pour gerer 3 lignes, on peut utiliser un fichier texteJe ne peux qu'approuver cette affirmation ... (même si la leçon est un peu sévère ...)
Sur le site où je travaille (une grande Banque française ...), il n'est pas rare de trouver des tables de plusieurs dizaines de millions de lignes, voire plusieurs centaines, la plus grande devant dépasser, me semble-t-il, le milliard ...
C'est vrai que nous disposons de "gros" ordinateurs (Mainframe z/OS) et de "gros" SGBD (DB2 for z/OS) ...
Je reviens a ce que j'ai écrit plus haut, si les indexes sont bien pensés a la création, regénérés de temps en temps, si la BDD est bien gérées (taille des blocs,...) les jointures sont tres performantes. C'est sur que si tu fais un produit scalaire de deux tables a 100 millions d'enregistrements avec un jointure sur deux champs de type chaine de caractere, que tu mets un like, que tu tries sur une colonne non indexée et qu'en plus tu demandes un distinct alors la oui, tu peux partir boire ton café tranquillement apres avoir lancé la requete.
Donc si tu as des problemes de performances avec tes requtes, regardes d'abord tout ca. Examine le plan d'execution de tes requetes, lance des statistiques. Si tout te parrait correct, cela peut venir de la configuration de ton SGBD, dans ce cas, demande de l'aide dans le forum approprié.
Bon courage
Euh ... pardonnez mon ignorance ... mais c'est quoi un produit scalaire ?
Produit cartésien, sans doute...
Oups pardonoui carthésien... Je n'a trompé en ecrivant
Je suis en ce moment en plein vecteurs
thx
donc si j ai bien compris : la rapidite d une requete ne va pas dependre du nombre d enregistrement "d'origine" dans la table ni du nombre d'enregistrement retourne par la requete mais du nombre d octets qui compose l'ensemble des enregistrements retournes par la requete .
?!?!
Personne pour confirmer ?
Dans l'absolu oui !
A +
Pour moi, la rapidité d'une requête va aussi dépendre du chemin d'accès choisi par le SGBD.thx
donc si j ai bien compris : la rapidite d une requete ne va pas dependre du nombre d enregistrement "d'origine" dans la table ni du nombre d'enregistrement retourne par la requete mais du nombre d octets qui compose l'ensemble des enregistrements retournes par la requete .
?!?!
Pour les recherches "ouvertes" (de nombreuses lignes répondent aux critères saisis) et si la requête est exécutée sous forme de curseur à l'interieur d'un programme applicatif, il suffit d'éviter de matérialiser la table résultante (la totalité des lignes) et de ne retourner que le nombre de lignes à afficher sur le poste utilisateur. On parle alors d'interrogation paginée.
Si la table est matérialisée ou si on ne peut pas paginer alors oui dans ce cas là la requête sera lourde à exécuter.
Rien à voir avec le sujet : le problème est de savoir ce qui rend lent ou rapide une requête. Le fait que le jeu de ligne soit renvoyé en bloc, avec ou sans curseur n'a rien à voir avec le temps mis pour former le jeu des résultats. Après c'est un problème de verouillage éventuel des lignes et de contention potentiel !
A +
Disons que je raisonnais plutôt au niveau du temps de réponse constaté par l'utilisateur. Si la table résultante n'est pas matérialisée (mais ce n'est pas toujours possible) l'utilisateur a plus rapidement sa réponse (les premières lignes de la table résultante). Encore faut il coder un prédicat de reprise pour obtenir la suite. Dans les architectures transactionnelles à fort débit c'est plutôt le mode de fonctionnement qu'on privilégie.
Ceci étant, le temps total pour obtenir l'ensemble des résultats sera voisin c'est vrai (voire même supérieur) mais simplement il est fractionné en plusieurs unités de temps élémentaire ...
Je reconnais aussi bien volontiers que je me suis éloigné de la question d'origine ...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager