[résolu] Problème de requête, CPU à 100%...

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [résolu] Problème de requête, CPU à 100%...

RaTo

Je dois écrire une requête qui me retourne la liste des personnes non connectées depuis 1 mois (à un réseau).
La requête que j'ai écris :

SELECT * FROM historique_login WHERE login_loginname NOT IN (SELECT login_loginname FROM historique_login WHERE login_timestamp > (NOW( ) - INTERVAL 1 MONTH ))

Quand je lance la requête dans phpMyAdmin, la page se charge très lentement et se bloque. Je n'arrive pas à afficher de résultats. Le processus mysqld-nt.exe consomme à ce moment 99% du CPU et met longtemps à redescendre, même quand je tente d'arrêter l'exécution de la requête.

Qu'est-ce qui cloche dans cette requête ? :??:

Message édité par RaTo le 27-07-2005 à 11:28:08

Publicité

skeye

Tu peux pas la faire sans sous-requête? [:mlc]
du style:
select * from historique_login where login_timestamp < (NOW( ) - INTERVAL 1 MONTH )

[:dawa]

---------------
Can't buy what I want because it's free -

Beegee

Remplace le NOT IN par un NOT EXISTS pour voir.

Code :

SELECT *
FROM historique_login hl
WHERE NOT EXISTS
(SELECT 1
FROM historique_login
WHERE login_loginname = hl.login_loginname
AND login_timestamp > (NOW( ) - INTERVAL 1 MONTH ));

skeye

Beegee a écrit :

Remplace le NOT IN par un NOT EXISTS pour voir.

Code :

SELECT *
FROM historique_login hl
WHERE NOT EXISTS
(SELECT 1
FROM historique_login
WHERE login_loginname = hl.login_loginname
AND login_timestamp > (NOW( ) - INTERVAL 1 MONTH ));

Mais [:ktulu] !

---------------
Can't buy what I want because it's free -

Beegee

skeye a écrit :

Tu peux pas la faire sans sous-requête? [:mlc]
du style:
select * from historique_login where login_timestamp < (NOW( ) - INTERVAL 1 MONTH )

[:dawa]

Ben non, vu sa demande, il veut pas voir les utilisateurs qui se sont connectés durant le dernier mois

skeye

Beegee a écrit :

Ben non, vu sa demande, il veut pas voir les utilisateurs qui se sont connectés durant le dernier mois

c'est pas ce que j'ai écrit?

---------------
Can't buy what I want because it's free -

Beegee

Non, tu sélectionnes l'historique de plus d'un mois de tous les utilisateurs.

Ce n'est pas la même chose que l'historique complet des utilisateurs non connectés durant le dernier mois.

RaTo

Beegee a écrit :

Non, tu sélectionnes l'historique de plus d'un mois de tous les utilisateurs.

Ce n'est pas la même chose que l'historique complet des utilisateurs non connectés durant le dernier mois.

Exactement. :jap:

Sinon en remplaçant le NOT IN par NOT EXISTS j'ai une erreur de syntaxe :
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'EXISTS (SELECT login_loginname FROM historique_login WHERE login_timestamp > (NO' at line 1

skeye

Beegee a écrit :

Non, tu sélectionnes l'historique de plus d'un mois de tous les utilisateurs.

Ce n'est pas la même chose que l'historique complet des utilisateurs non connectés durant le dernier mois.

ah oui.
Ca empêche pas de le faire sans sous-requête.

select max(login_timestamp), champ2, champ3
from historique_login
where login_timestamp < (NOW( ) - INTERVAL 1 MONTH )
group by (champ2, champ3)

[edit]

encore raté... [:joce]

Message édité par skeye le 26-07-2005 à 15:25:55

---------------
Can't buy what I want because it's free -

megadub

bah pourquoi pas ça simplement :

SELECT * FROM historique_login WHERE login_timestamp <= (NOW( ) - INTERVAL 1 MONTH ))

Si tu supprimes les logins de plus d'un mois alors il suffit de garder ceux de moins d'un mois... comment faire simple quand on peut faire compliqué

Publicité

skeye

RaTo a écrit :

essaye d'aliaser ta table dans la requête imbriquée, aussi.

---------------
Can't buy what I want because it's free -

skeye

megadub a écrit :

Bien vu, même connerie que moi! [:joce]
J'avais pas pensé non plus qu'il conservait tout son historique... [:joce]

---------------
Can't buy what I want because it's free -

skeye

par curiosité, ya combien de lignes dans ta table historique_login?

[edit]

Question subsidiaire : ne serait-ce pas intéressant de la transformer en dernier_login? [:joce]

Message édité par skeye le 26-07-2005 à 15:32:35

---------------
Can't buy what I want because it's free -

Arjuna

Aircraft Ident.: F-MBSD

Vérifie déjà que dans ta version de MySQL y'a bien le EXISTS qui est supporté. Apparement, il ne l'est pas.

S'il ne supporte pas, alors change de version (super, j'adore ce SGBD ) ou tu peux aussi d'apporter une légère optimisation à ton NOT IN en résuidant la liste qu'il retourne :

Code :

SELECT * FROM historique_login WHERE login_loginname NOT IN (SELECT login_loginname FROM historique_login WHERE login_timestamp > (NOW( ) - INTERVAL 1 MONTH ) group by login_loginname)

C'est pas forcément énorme comme optimisation, mais ça devrait aider.

Ensuite, n'oublie pas de créer deux index :

historique_login(login_timestamp, login_loginname)
historique_login(login_loginname)

Le premier devant pouvoir être unique (en comptant qu'une personne ne se logue normalement pas deux fois dans la même milli-seconde.

RaTo

En balaçant la requête :

Code :

SELECT *
FROM historique_login hl
WHERE NOT EXISTS
(SELECT 1
FROM historique_login
WHERE login_loginname = hl.login_loginname
AND login_timestamp > (NOW( ) - INTERVAL 1 MONTH ));

Même résultat qu'avec la mienne, plantage de mysql...

Arjuna

Aircraft Ident.: F-MBSD

Teste ma solution.

Beegee

Autre question qui va avec : y a-t-il un index sur login_loginname ?

Arjuna

Aircraft Ident.: F-MBSD

Avec les index evidement.

megadub

skeye a écrit :

Bien vu, même connerie que moi! [:joce]
J'avais pas pensé non plus qu'il conservait tout son historique... [:joce]

ha oui, alors :

Code :

SELECT login_name, max(login_timestamp) FROM historique_login WHERE login_timestamp <= (NOW( ) - INTERVAL 1 MONTH ))
GROUP BY login_name

ça devrait le faire ça non ?

RaTo

skeye a écrit :

par curiosité, ya combien de lignes dans ta table historique_login?

22 116

skeye a écrit :

Question subsidiaire : ne serait-ce pas intéressant de la transformer en dernier_login? [:joce]

:??:

Beegee

Vu que EXISTS ne semble pas supporté, passage par jointure externe, comme d'hab'

Code :

SELECT *
FROM historique_login hl1
LEFT JOIN hl2 ON hl2.login_loginname = hl1.login_loginname
WHERE hl2.login_timestamp > (NOW( ) - INTERVAL 1 MONTH)
AND hl2.login_loginname IS NULL;

Il suffit d'avoir un index sur login_loginname.

edit: si tu veux juste les logins et que tu n'as pas besoin de l'historique, alors tu peux faire ça aussi :

Code :

SELECT login_loginname, MAX(login_timestamp)
FROM historique_login
GROUP BY login_loginname
HAVING MAX(login_timestamp) > (NOW( ) - INTERVAL 1 MONTH);

Message édité par Beegee le 26-07-2005 à 15:41:06

skeye

megadub a écrit :

ha oui, alors :

Code :

SELECT login_name, max(login_timestamp) FROM historique_login WHERE login_timestamp <= (NOW( ) - INTERVAL 1 MONTH ))
GROUP BY login_name

ça devrait le faire ça non ?

c'est le genre de trucs que j'ai proposé aussi...tu vas avoir pour tous les utilisateurs le plus récent login ayant plus d'un mois...

---------------
Can't buy what I want because it's free -

Arjuna

Aircraft Ident.: F-MBSD

A mon avis, il faut surtout un group by (pour faire un distinct) dans la sous-requête.

En effet, même si ce sont des doublons, un NOT IN pourtant sur des milliers de valeurs, ben ça fait tout tomber. Avec un distinct, y'en aura forcément infiniment moins, et ça devrait grandement améliorer l'éxécution du NOT IN

skeye

RaTo a écrit :

:??:

Bah ça a un intérêt de garder l'historique complet de tous les logins de tes utilisateurs, en vrai?
Parce-que si non, tu gardes la date du dernier login pour chaque utilisateur, et basta...ce qui résoud aussi le pb... [:joce]

---------------
Can't buy what I want because it's free -

RaTo

Arjuna a écrit :

Vérifie déjà que dans ta version de MySQL y'a bien le EXISTS qui est supporté. Apparement, il ne l'est pas.

Je pense que le EXISTS est bien dans la version de MySQL que j'utilise, car j'arrive à faire des requêtes du style "DROP TABLE IF EXISTS..."

La version : 4.1.10a

Beegee

Je t'ai donné 2 requêtes qui devraient marcher, juste au-dessus, y a pas besoin de EXISTS de toute façon.

RaTo

skeye a écrit :

Bah ça a un intérêt de garder l'historique complet de tous les logins de tes utilisateurs, en vrai?

Oui. (enfin c'est une exigence de mon supérieur, donc je ne peux pas modifier ça)

Message édité par RaTo le 26-07-2005 à 15:43:33

megadub

skeye a écrit :

c'est le genre de trucs que j'ai proposé aussi...tu vas avoir pour tous les utilisateurs le plus récent login ayant plus d'un mois...

exact

skeye

bon, alors voir plus haut les suggestions de beegee et arjuna... [:skeye]

---------------
Can't buy what I want because it's free -

skeye

Je pense que la bonne piste effectivement c'est de réduire au max le nombre de réponses de la sous-requête...

---------------
Can't buy what I want because it's free -

Arjuna

Aircraft Ident.: F-MBSD

Personne veut suivre ma requête :spamafote:

Arjuna

Aircraft Ident.: F-MBSD

C'est mal de tronquer une table de logs.

RaTo

Arjuna a écrit :

Personne veut suivre ma requête :spamafote:

J'ai créé les index et balancé ta requête, ça tourne là, ça à l'air de ramer tout autant...

Je crois que le problème c'est en fait les 22 000 lignes.

skeye

RaTo a écrit :

J'ai créé les index et balancé ta requête, ça tourne là, ça à l'air de ramer tout autant...

Je crois que le problème c'est en fait les 22 000 lignes.

22000 c'est pas la mer à boire non plus...à moins que le serveur soit vraiment juste ya pas de raison que ce soit si lent!

---------------
Can't buy what I want because it's free -

RaTo

RaTo a écrit :

J'ai créé les index et balancé ta requête, ça tourne là, ça à l'air de ramer tout autant...

ça tourne toujours..

Message édité par RaTo le 26-07-2005 à 16:00:08

RaTo

Bon j'ai arrêté la requête d'Arjuna, ça ramait trop..

Beegee

Et mes requêtes alors ?

Arjuna

Aircraft Ident.: F-MBSD

C'est étrange que ça ramme autant, t'as combien de login différents ?

Parcequ'un IN, c'est lent, certes, mais à la base, si le nombre est limité, ça doit quand même pas prendre des siècles... Idem pour un group by sur 22000 lignes, ça représente pas un gros volume.

Une requête normale fonctionne ?

RaTo

Bonsoir les amis,

Je vous réponds juste, je continuerai à tester demain au boulot, là je ne peux pas, merci de votre aide.

RaTo

Arjuna a écrit :

C'est étrange que ça ramme autant, t'as combien de login différents ?

582.

Arjuna a écrit :

Une requête normale fonctionne ?

Oui.

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

SQL/NoSQL

[résolu] Problème de requête, CPU à 100%...

Sujets relatifs
[VB][RESOLU]Probleme lors d'un demarrage d'un prg fait en vb	Probleme de modification dans un fichier!
[Résolu] Prob avec suppression maintenant :P	[Résolu] Importer sous Access
[Resolu]macro suite a une saisie clavier	[RESOLU] [MySQL API C] Problème avec mysql_query
[SQL] Problème écriture requête
Plus de sujets relatifs à : [résolu] Problème de requête, CPU à 100%...

Page générée en 0.101 secondes