Pour que la requete récupere tout d'abord les même enregistrements, je dois enlever les colonnes avec CASE WHEN et le temps de réponse passe de 3s à 0.7s :)
Type: Messages; Utilisateur: dimainfo
Pour que la requete récupere tout d'abord les même enregistrements, je dois enlever les colonnes avec CASE WHEN et le temps de réponse passe de 3s à 0.7s :)
Malheureusement après quelques tests je me rend compte que ce n'est pas le même résultat que j'obtiens des 2 requêtes avec et sans les informations complémentaires.
Effectivement après l’enlèvement des autres attributs le temps de réponse passe de 3s à 0.5s ce qui est logique mais je ne sais pas comment faire pour construire une autre requete pour récupérer ces...
La même requête sans le order by : 0s
La même requête sans le order by ni le LIMIT 20 : 0s aussi.
La volumétrie :
Job : 43 373 874
Tracking : 107490
TrackingStatusType : 23
trackingtype : 43...
Salut Artemus24,
En effet oui j'ai bien les index trkenv.EnvID et trk.TrkTypeID et ta requête a le même temps de réponse que la mienne :/ aucun changement.
Les filtres ne sont pas limité justement c'est à l'utilisateur de créer son propore filtre (colonnes, ordre d'affichage, ordre de tri...) c'est bien ce qui complique le travail.
J'ai un exemple d'une requête qui me pause problème, tout en sachant que les utilisateurs peuvent créer des filtres avec des données differentes alors je n'ai pas une requete type du moment que celle...
je ne crois pas que j'ai des problemes d'index, mon SGBD est Mysql. la récuperation d'un filtre implique à chaque fois l’interrogation des criteres de sélection et des colonnes à afficher depuis...
Sur l'affichage du résultat filtré.
Bonjour à tous,les amis j'ai un probleme de performances avec une base de données d'une application web de traçabilité qui peut atteindre des centaines de millions d'enregistrements. L'utilisateur...
Avant de marquer résolu je fais quelques tests tout d'abord.
job.StartDate est un attribut qui marque la date de creation du job, cette colonne ne peut en aucun etre modifié.
La réponse est instantanée, et ça me retourne les meme résultats je vous remercie :)
Et celle-ci aussi elle est instantanée.
Merci infiniement, je crois que c'est bon maintenant il faillait...
J'ai compris que effectivement l'ordre des identifiants est le meme que celui des StartDate, mais à quoi ça pourra m'aider, vous voulez dire que je faire un order by par l'identifiant au lieu de...
@Gaulouis
Table tampon je ne crois pas que ca marchera vu que nous devons avec les 22 derniers lignes en relation avec la table tracking et ça sera aussi couteux lors de l'insertion des jobs.
Sinon...
@kolodz
Vous avez raison le order by est la source de cette lenteur par contre on ne peut NI limiter les résultats avant les trier parce que ma requete ne répondera plus au besoin de client NI la...
@kolodz
EnvID_TrkTypeID est un index que j'avais rajouté sur la table tracking pour répondre à ma requete qui contient toujours ces 2 criteres.
Le nombre de la requete que vous m'avez demandé est...
Le résultat d' explain de la requete.
Le résultat de la requete :
SELECT count(*)
FROM tracking trk
INNER JOIN TrackingStatusType tst on tst.TrkStatusTypeID=trk.TrkStatusTypeID
INNER JOIN...
CREATE TABLE IF NOT EXISTS `_interchange` (
`TrkID` int(10) unsigned NOT NULL,
`SyntaxID` varchar(4) DEFAULT NULL,
`SyntaxVersion` varchar(1) DEFAULT NULL,
`TestID` varchar(1) DEFAULT...
Bonjour à tous,
J'ai un probleme d'amelioration de performanaces d'une de mes requetes, le temps de traitement s'éleve à 2s.
Ci-dessous la requete :
SELECT trk.TrkTypeID , trk.TrkID as TrkID,...
Le fullText ne marchera pas avec ce que je demande, car avec le MATCH ... AGAINST... je ne peux pas avoir l'enregistrement qui contient le mot '%TEST%' comme le LIKE.
Après plusieurs test, j'ai rajouté un USE INDEX (StartDate) après le
FROM job et ça a donnée une bonne résultat qui ne dépasse pas quand meme 1s, néanmoins le rajout d'un autre critere qui est ...
Si on remonte le filtre dans la sous requete ça donnera toujours le meme problème de performance d'ailleurs on faisant un test ça n'a aboutit en rien.
D'autres propositions ? :(
@aieeeuuuuu
Le filtre par 500 en amont est plus rapide par contre si les critères de recherche ne figurent pas sur ces 500 lignes alors le filtre va être faux.
Bien reçu, je dois maintenant créer une table avec ces index et après la charger avec ma table de 40m de tuples vu que je ne peux pas créer un index dessus avec ce volume de données.
@escartefigue
Donc si j'ai bien compris je rajoute l'index sur les 3 ou 4 attributs avec StartDate DESC et je supprime l'index sur le StartDate , JobTypeID, StatusTypeID et EnvID.
@aieeeuuuuu...
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.