1. Ce site utilise des cookies. En continuant à utiliser ce site, vous acceptez l'utilisation des cookies. En savoir plus.
  2. Bonjour tout le monde ! Veillez consulter la Politique de forum pour comprendre nos règles, Merci a vous !
    Rejeter la notice
Cookies Politique du forum

INFO Moteur HFSQL-23 mal optimisé

Discussion dans 'Base de donnés & HFSQL' créé par Razorte, Oct 2, 2018.

  1. Razorte

    Razorte Member

    Inscrit:
    Mai 11, 2018
    Messages:
    49
    J'aime reçus:
    50
    Bonjour à tous, ce matin j'ai remarqué que le moteur SQL du HFSQL est mal optimisé quand il s'agit de faire des conditions avec plusieurs variable ensemble.

    Exemple : WHERE a.Saison+a.Ref = b.Saison+b.Ref

    Cette requête prenait a elle seules 4 secondes et après avoir remplacé les "+" par des "AND", la requête ne mettait plus que 25ms a s'exécuter !

    Exemple: WHERE a.Saison = b.Saison AND a.Ref = b.Ref

    J'ai remarqué cette mauvaise optimisation du moteur sur plusieurs de mes requêtes.
     

    Fichiers attachés:

    #1 Razorte, Oct 2, 2018
    Tags:
    joker apprécie ceci.
  2. hh59

    hh59 New Member

    Inscrit:
    Mar 21, 2018
    Messages:
    10
    J'aime reçus:
    11
    Les deux requêtes ne font pas la même chose !!
    Par exemple si a.saison = "ET" , a.ref = "E12345" et b.saison = "ETE" , b.ref = "12345"
    Tout dépend aussi des tes index , si saison est en index ou seulement ref .
    A voir si les champs calculés aussi peuvent améliorer ces requêtes.
     
    #2 hh59, Oct 2, 2018
  3. Razorte

    Razorte Member

    Inscrit:
    Mai 11, 2018
    Messages:
    49
    J'aime reçus:
    50
    Elles ne font pas la même chose, mais au final ça revient au même pour mon utilisation. C'est juste qu'avec les "AND" je teste variable par variable et non les données ensemble.
    Exemple :

    a.Saison+a.Ref = b.Saison+b.Ref
    '13E'+51 = '13E'+51

    Avec les "AND"

    a.Saison = b.Saison AND a.Ref = b.Ref
    '13E' = '13E' AND 51 = 51

    Les deux cas fonctionnent, juste dans le premier cas le moteur est obliger de créer une nouvelle colonne avec l'addition des variables, pas dans le deuxième, c'est pour cela que je pense que la 2 méthode avec les "AND" est plus rapides pour le moteur HFSQL. Après je parle dans mon cas.
     
    #3 Razorte, Oct 2, 2018
    joker apprécie ceci.
  4. channibal

    channibal Well-Known Member
    MEMBRE WX

    Inscrit:
    Fev 22, 2018
    Messages:
    210
    J'aime reçus:
    277
    Bonjour,

    En faite le moteur ne fait que suivre le logique essentiel de la programmation: évaluation, comparaison et processus.

    Dans le premier exemple WHERE a.Saison+a.Ref = b.Saison+b.Ref : Le moteur lance un processus, évalue la première partie de la comparaison, sauvegarde le résultat, lance un deuxième processus, évalue la deuxième partie de la comparaison, sauvegarde le résultat, lance une comparaison logique entre les deux résultats de l’évaluation (là il a été obligé de mettre le processus principal en pause en attendant les résultats des 2 évaluations.. ce qui signifie du temps)

    Dans la deuxième expression WHERE a.Saison = b.Saison AND a.Ref = b.Ref : Le moteur, dans le cas de HFSQL, lance 2 processus, lance 2 comparaisons logiques (pas d'obligation d'attente)
    Et si on remplace le AND par un _AND_ le moteur ne lancera qu'un seul processus le cas échéant, le temps sera encore moins long (je suppose)

    Maintenant dans ton exemple Est-ce que les 2 expressions donnent le même résultat? Dans tous les cas? Je ne serais pas trop sûr!
    Si tes valeurs été tous des numériques alors les 2 expressions ne donneront pas le même résultat

    Exemple:

    a.Saison+a.Ref = b.Saison+b.Ref
    13+51 = 51+13
    64 = 64
    Là l'expression est Vrai

    Avec les "AND"

    a.Saison = b.Saison AND a.Ref = b.Ref
    13 = 51 AND 51 = 13
    Là c'est plus rapide, mais l'expression est Faux

    Bon Dev.
     
    #4 channibal, Oct 3, 2018
    joker apprécie ceci.
  5. Razorte

    Razorte Member

    Inscrit:
    Mai 11, 2018
    Messages:
    49
    J'aime reçus:
    50
    Effectivement c'est pour cela que je précise bien dans mon cas, étant donnée que j'utilise des variables de type chaîne. Merci

    Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

    pour l'astuce des _AND_ je vais essayer.
     
    #5 Razorte, Oct 3, 2018
    joker apprécie ceci.
  6. channibal

    channibal Well-Known Member
    MEMBRE WX

    Inscrit:
    Fev 22, 2018
    Messages:
    210
    J'aime reçus:
    277
    Juste par curiosité et pour tester s'il y a changement dans les temps.

    Si on fait les évaluations avant la requête et on compare juste les résultats

    Partie1 est une Chaîne = a.Saison+a.Ref
    Partie2 est une Chaîne = b.Saison+b.Ref

    WHERE Partie1 = Partie2

    Sera-telle plus rapide?

    Édit: Je crois que je dis n'importe quoi vu que les tables ne seront interrogées qu’après le lancement de la requête :)
     
    #6 channibal, Oct 3, 2018
    joker apprécie ceci.
  7. Razorte

    Razorte Member

    Inscrit:
    Mai 11, 2018
    Messages:
    49
    J'aime reçus:
    50
    Le _AND_ ne fonctionne pas: "Mot _AND_ inattendu". Dommage mais bon 25ms c'est quand même déjà pas mal.

    Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

    , je ne peut pas tester ce que tu dits car dans mon cas la condition me sert pour la liaison entre mes 2 tables.
     
    #7 Razorte, Oct 3, 2018
  8. channibal

    channibal Well-Known Member
    MEMBRE WX

    Inscrit:
    Fev 22, 2018
    Messages:
    210
    J'aime reçus:
    277

    Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

    Le _AND_ ne fonctionne pas: "Mot _AND_ inattendu". Dommage mais bon 25ms c'est quand même déjà pas mal.

    Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

    , je ne peut pas tester ce que tu dits car dans mon cas la condition me sert pour la liaison entre mes 2 tables.
    Cliquez pour agrandir...
    Oui effectivement pas besoin de _AND_ en SQL c'est la notion par défaut.

    Sinon, 4 secondes c'est un peu trop quand même pour la première méthode!! t'as essayer d'optimiser la requête? genre masquer les rubriques inutilisés par exemple?
     
    #8 channibal, Oct 3, 2018
  • Razorte

    Razorte Member

    Inscrit:
    Mai 11, 2018
    Messages:
    49
    J'aime reçus:
    50

    Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!

    Oui effectivement pas besoin de _AND_ en SQL c'est la notion par défaut.

    Sinon, 4 secondes c'est un peu trop quand même pour la première méthode!! t'as essayer d'optimiser la requête? genre masquer les rubriques inutilisés par exemple?
    Cliquez pour agrandir...
    Oui maintenant elle ne prend plus que 25ms après avoir changer les + par des AND.
     
    #9 Razorte, Oct 3, 2018
    joker apprécie ceci.
  • DomergueR

    DomergueR New Member

    Inscrit:
    Juin 21, 2018
    Messages:
    17
    J'aime reçus:
    5
    Ben cela me parait normal que a+b=c+d soit plus long, car il faut concaténer a avec b puis c avec d puis faire la comparaison (trois opérations minimum), avec a=c and b=d où il y a au plus deux opérations.

    Et bien sur comme le dit hh59 les résultats ne sont pas identiques selon le contenu des variables, je pense qu'il faut avoir le moins de traitement tant dans les requêtes que dans les traitements de tout programme.
     
    #10 DomergueR, Oct 4, 2018
    • (Vous devez vous identifier ou vous inscrire pour poster ici.)

    Partager cette page

    Chargement...