IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Requêtes MySQL Discussion :

Problème de performances, avec requête basique (culture générale SQL) [MySQL-5.1]


Sujet :

Requêtes MySQL

  1. #21
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 464
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 464
    Points : 19 453
    Points
    19 453
    Par défaut
    Salut SQLPRO.

    Citation Envoyé par SQLPRO
    Un index est dit couvrant, si la seule lecture de l'index suffit à récupérer toutes les informations nécessaires au traitement de la requête.
    Je ne savais pas que cela se nommait ainsi.
    C'est souvent le jargon qui me manque pour décrire les bonnes pratiques.
    Comme j'ai appris quelque chose aujourd'hui, je te mets un '+'1 !

    @+

  2. #22
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    NON !

    Justement ce n'est pas pour rien que j'ai mis argument de recherche en gras
    S'il n'est utilisé que par ce qu'il est couvrant, alors il est utilisé comme data et non comme argument de recherche , il est donc parcouru en ce cas séquentiellement (index scan)

    Et moi, c'est pour ça que j'ai mis deux requêtes

    Pour la première, certes il sera parcouru entièrement, puisqu'on fait les calculs pour la totalités des données sans restriction (il fera cependant probablement économiser de nombreuses lectures par rapport à un scan de la table)

    Mais pour la deuxième requete, ce sera bien une recherche d'index qui sera effectuée (même si 90% des personnes sont des hommes ! ), puisqu'il y a bien une clause de restriction et que l'index couvre la requête : les pages de l'index contenant les autres catégorie ne seront pas lues.

  3. #23
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 338
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 338
    Points : 39 733
    Points
    39 733
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message
    Et moi, c'est pour ça que j'ai mis deux requêtes
    Du coup c'est moi qui ai lu trop vite, ou le syndrome de l'arroseur arrosé

    Citation Envoyé par Artemus24 Voir le message
    Je ne savais pas que cela se nommait ainsi.
    Peut être que la notion "INDEXONLY" vous parle plus

    Citation Envoyé par SQLpro Voir le message
    Si vous forcez le choix d'index vous rendez le plan statique alors qu'il doit rester dynamique car une base est "vivante" les données évoluant. En forçant l'optimiseur à adopter une stratégie plutôt que l'autre vous risquez plus gros encore... Que les performances deviennent subitement catastrophiques.
    Plutôt que de forcer directement l'index, on peut tricher en modifiant les stats le temps de passer la requête qui pose problème, sous réserve de ne pas géner d'autres threads
    Dans tous les cas, ce type d'opération doit rester exceptionnnel et il faut supprimer le forçage ou refaire les stats dès que l'opération est terminée

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. Problème de performance avec mes requêtes update
    Par Battosaiii dans le forum PL/SQL
    Réponses: 19
    Dernier message: 03/08/2011, 09h38
  2. problème de performance sur requête avec Tsearch2
    Par Morpheas dans le forum PostgreSQL
    Réponses: 0
    Dernier message: 05/02/2008, 12h25
  3. Réponses: 8
    Dernier message: 11/02/2006, 23h36
  4. Problème de performance avec LEFT OUTER JOIN
    Par jgfa9 dans le forum Requêtes
    Réponses: 6
    Dernier message: 17/07/2005, 13h17
  5. [C#] Probléme de performance avec IsDbNull
    Par jab dans le forum Windows Forms
    Réponses: 8
    Dernier message: 04/04/2005, 11h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo