Amélioration des performances & d'exécution des requêtes
Résolu/Fermé
guedo
guedo
- Messages postés
- 77
- Date d'inscription
- mercredi 26 novembre 2014
- Statut
- Membre
- Dernière intervention
- 10 avril 2019
guedo
- Messages postés
- 77
- Date d'inscription
- mercredi 26 novembre 2014
- Statut
- Membre
- Dernière intervention
- 10 avril 2019
A voir également:
- Amélioration des performances & d'exécution des requêtes
- Amélioration des performances & d'exécution des requêtes ✓ - Forum - MySQL
- Nous avons désactivé la détection de la voix pour améliorer les performances du téléphone ✓ - Forum - Android
- Comment ameliorer les performance de son pc ✓ - Forum - Windows
- Ce processus uwp est interrompu pour améliorer les performances du système - Forum - Microsoft Edge
- Les cybermarchés ont amélioré leurs performances mais peuvent encore mieux faire, selon les consomma - Actualités
2 réponses
Reivax962
9 avril 2019 à 11:17
- Messages postés
- 3671
- Date d'inscription
- jeudi 16 juin 2005
- Statut
- Membre
- Dernière intervention
- 11 février 2021
9 avril 2019 à 11:17
Bonjour,
As-tu pensé à créer un index sur ID_CONTACT dans ta table Status ?
Xavier
As-tu pensé à créer un index sur ID_CONTACT dans ta table Status ?
Xavier
jee pee
9 avril 2019 à 12:02
- Messages postés
- 35653
- Date d'inscription
- mercredi 2 mai 2007
- Statut
- Modérateur
- Dernière intervention
- 16 août 2022
9 avril 2019 à 12:02
Bonjour,
L'index est effectivement une bonne idée.
Si le Status est souvent utilisé avec les données Contact une solution serait d'intégrer dans cette dernière table le Status courant. Cela simplifierait notablement la recherche.
Cdlt
L'index est effectivement une bonne idée.
Si le Status est souvent utilisé avec les données Contact une solution serait d'intégrer dans cette dernière table le Status courant. Cela simplifierait notablement la recherche.
Cdlt
Reivax962
9 avril 2019 à 13:20
- Messages postés
- 3671
- Date d'inscription
- jeudi 16 juin 2005
- Statut
- Membre
- Dernière intervention
- 11 février 2021
9 avril 2019 à 13:20
Effectivement, garder d'un côté l'historique, et de l'autre la valeur courante permet de conserver le meilleur des deux mécanismes :)
Par contre il faut être sûr que le code de fasse jamais d'UPDATE direct sur la table CONTACT, l'idéal étant de coder une procédure stockée de mise à jour du statut qui gère elle-même, d'un côté l'UPDATE contact, de l'autre l'INSERT status.
Par contre il faut être sûr que le code de fasse jamais d'UPDATE direct sur la table CONTACT, l'idéal étant de coder une procédure stockée de mise à jour du statut qui gère elle-même, d'un côté l'UPDATE contact, de l'autre l'INSERT status.
9 avril 2019 à 11:44
Non, dans ma table status, j'ai un INDEX appliqué sur l'ID STATUS pour le définir comme étant une clé primaire en auto increment.
Donc la procédure serait d'ajouter à ma table un index de type INDEX uniquement sur la colonne ID_STATUS, (en plus de l'index de clé primaire).
Le fait de rajouter dans la table status un index sur l'ID CONTACT va me permettre d'adapter la structure de ma requête c'est bien sa ?
9 avril 2019 à 13:16
Pas besoin d'index sur la clef primaire, elle est indexée par nature.
Par contre, l'index sur ID_CONTACT est indispensable. Tu n'as pas besoin de changer ta requête, c'est totalement transparent de ce point de vue-là.
Xavier
10 avril 2019 à 17:34
Des chargement de pages sur mon application web qui pouvait aller jusqu'à plusieurs minutes se retrouvent charger en moins de 3 secondes ... c'est une merveille :)