[Résolu] Optimisation de LEFT JOIN

[finstreet]

Hello tout le monde,

J'ai un gros problème sur une requête.

SELECT ID_actualites, Date_actualites, Titre_actualites, Type_actualites, Actu_lu_nonlu FROM j_actualites LEFT JOIN j_lu_nonlu ON ID_actualites = Actu_lu_nonlu AND j_lu_nonlu.Membre_lu_nonlu = '1' WHERE Date_actualites < '2006-06-21 23:00:00' GROUP BY ID_actualites ORDER BY Date_actualites DESC LIMIT 0, 30

La petite me prend 5,7 secondes... argh

En fait c un système simple qui permet à la fois d'afficher TOUS les titres présents dans la table j_actualites et de préciser les actualités qui ont déjà été lues (dans la table j_lu_nonlu)

Pour j_actualites ca ressemble à ca :

ID_actualites  int(11)     Non    auto_increment              
Date_actualites  datetime     Non  0000-00-00 00:00:00                
Titre_actualites  varchar(250) latin1_swedish_ci   Non                  
Description_actualites  text latin1_swedish_ci   Non                  
Source_actualites  tinyint(2)     Non  0

Pour j_lu_nonlu ca ressemble à ca :

ID_lu_nonlu  int(11)     Non    auto_increment              
Actu_lu_nonlu  varchar(11) latin1_swedish_ci   Non                  
Membre_lu_nonlu  varchar(11) latin1_swedish_ci   Non

Le but c de diminuer sensiblement la durée forcément

Merci d'avance

 

[mr_go]

Tu ne peux pas utiliser des aliases et faire une requete du type :

select id.ID_actu
FROM ID_actualites id, ID_lu_nonlu  idnl
WHERE id.ID_actualites  = idnl.ID_lu_nonlu AND...

?

 

[finstreet]

Tu ne peux pas utiliser des aliases et faire une requete du type :

select id.ID_actu
FROM ID_actualites id, ID_lu_nonlu  idnl
WHERE id.ID_actualites  = idnl.ID_lu_nonlu AND...

?

Oui mais dans ce type de requetes ca ne m'affichera que les actus déjà lues non ?

En fait il me faut TOUTE la table j_actualites et que ca ne prenne qu'une partie de la table j_lu_nonlu ...

 

[spidetra]

Re: Optimisation de LEFT JOIN

Hello tout le monde,

J'ai un gros problème sur une requête.
...

Tu fait un LEFT JOIN entre un INT et un VARCHAR ?
Tu n'as pas de clé externe ?

j_actualites LEFT JOIN j_lu_nonlu ON ID_actualites = Actu_lu_nonlu

-> ID_actualites int(11) Non auto_increment
-> Actu_lu_nonlu varchar(11) latin1_swedish_ci Non


Note : ce genre de requête c'est plus simple à optimiser avec un petit export phpMyAdmin comtenant la structure des tables et les index associés.

 

[finstreet]

Tu fait un LEFT JOIN entre un INT et un VARCHAR ? 
Tu n'as pas de clé externe ?

Euh... oui... vais me cacher profond dans un trou c ca ? lol

Note : ce genre de requête c'est plus simple à optimiser avec un petit export phpMyAdmin comtenant la structure des tables et les index associés.

Pas compris là

Edit : Spidetra, en trois mots, il me tue Bon ben j'ai mis un INT au lieu d'un varchar... et suis passé à 0.0855 seconde.

Marchi marchi marchi marchi

 

[spidetra]

Re: Optimisation de LEFT JOIN

SELECT ID_actualites, Date_actualites, Titre_actualites, Type_actualites, Actu_lu_nonlu FROM j_actualites LEFT JOIN j_lu_nonlu ON ID_actualites = Actu_lu_nonlu AND j_lu_nonlu.Membre_lu_nonlu = '1' WHERE Date_actualites < '2006-06-21 23:00:00' GROUP BY ID_actualites ORDER BY Date_actualites DESC LIMIT 0, 30

Après relecture je comprend pas grand chose à ta syntaxe :
Pourquoi le AND j_lu_nonlu.Membre_lu_nonlu = '1' est avant la clause WHERE ?

 

[spidetra]

Note : ce genre de requête c'est plus simple à optimiser avec un petit export phpMyAdmin comtenant la structure des tables et les index associés.

Pas compris là

si ton pb de performance est lié à l'absence d'index ou a des mauvais index, on ne peut pas le voir avec ce que tu postes.

Tu sais quand une requête rame, les premières choses qu'on regarde :
- les index
- les mauvaises jointures

 

[finstreet]

Re: Optimisation de LEFT JOIN

Après relecture je comprend pas grand chose à ta syntaxe :
Pourquoi le AND j_lu_nonlu.Membre_lu_nonlu = '1' est avant la clause WHERE ?

J'avais un peu bidouillé mais oui à l'origine c'était bien placé

 

[mr_go]

Tu sais quand une requête rame, les premières choses qu'on regarde :
- les index
- les mauvaises jointures

et accessoirement la taille de la table

 

[spidetra]

Tu sais quand une requête rame, les premières choses qu'on regarde :
- les index
- les mauvaises jointures

et accessoirement la taille de la table

très honnêtement; non. La taille de la table (nbr d'enregistrements ) n'est pas si importante, c'est vraiment ce que je regarde en dernier.

 

[le_gber]

p'tite question d'un debutant en PHP,

existe-t-il une fonction PHP qui vous retourne le temps qu'un script met a s'executer - ou est-ce dispo dans phpMyAdmin quand would lancé la function en direct?

Merci

 

[e-kiwi]

>> Tu sais quand une requête rame, les premières choses qu'on regarde :
>>- les index
>>- les mauvaises jointures

+100000000

 

[shrom]

Tu sais quand une requête rame, les premières
choses qu'on regarde :
- les index
- les mauvaises jointures

Sans oublier la structure de la base qui peut être fautive et impossible à optimiser, dans ce cas, on remet tout à plat et on recommence ;-)

 

[finstreet]

p'tite question d'un debutant en PHP,

existe-t-il une fonction PHP qui vous retourne le temps qu'un script met a s'executer - ou est-ce dispo dans phpMyAdmin quand would lancé la function en direct?

Merci

si tu les lances une par une, tu as le temps d'afficher

 

[shrom]

existe-t-il une fonction PHP qui vous retourne le temps qu'un script met a s'executer - ou est-ce dispo dans phpMyAdmin quand would lancé la function en direct?

Su tu installes un debugger, tu pourras faire ce que l'on appelle du profiling et voir le temps que met une fonction à s'exécuter, le temps global d'exécution du script etc ..

http://xdebug.org/
http://dd.cron.ru/dbg/
http://pecl.php.net/package/apd