Hello,

Merci pour cette réponse précise et efficace :)
Merci pour le déplacement, c’est vrai qu'au début j'ai pensé un souci de script dans ma page php et au fur et à mesure de la rédaction du post, j’avais essayé dans phpmyadmin mais pas pensé à déplacer le sujet.
Alors pour les champs, ils sont bien en INT(11), et pour les '35' , je pensais qu'on devait systématiquement mettre la valeur (ici une variable php dans la requête SQL que la page php) entre ' ' .
Pour les 4 jointures, j'(étais un peu douteux que ça puisse venir de là, j'ai d'ailleurs une autre requête utilisant qu'une jointure avec coverlink et même souci de lenteur.
En revanche, il n'y avait pas d'index sur les tables coverlink et doubles. J’avais essayé en ajoutant une colonne avec INDEX UNIQUE, mais ça n'avait rien changé. Je ne savais pas qu'on pouvait définir comme index plusieurs champs.
Je devrais théoriquement me coucher un peu moi con que je me suis levé lol

Du coup, bah c'est beaucoup plus rapide maintenant :D

Merci pour le coup de palme et bon ouiK :)

Je déplace le sujet dans la catégorie SQL vu qu'il s'agit surtout d'optimisations SQL et pas PHP.

Il n'y a malheureusement pas de magie une requête avec 4 jointures, c'est gourmand en ressources...
La 1ère chose à vérifier c'est est-ce que tu as bien mis des index sur tes tables notamment sur les champs sur lequel tu fait la jointure et sur lesquels tu cherches ?
Est-ce que le format des champs SQL sont bien défini ? (J'ai un doute quand je vois id='35' car un id ne doit être que numérique donc id=35 et type de champ INT)

COUINNNN !

Sur une base de données de titres musicaux (webradio).

Pour presque chaque musique, une pochette de disque est associée (je me sers de l'ID de la musique, dans la table songs, pour appeler un fichier .jpg ).
Pour les remix ou les musiques faisant partie d'un même album, je réiutilise une pochette existante (la table coverlink sert à faire la jonction entre l'ID du remix , et l'ID de la musique dont on veut utiliser la pochette).
Pour faciliter le tri des musiques par le propriétaire de la radio, je note aussi dans une table "doubles" , les musiques qui sont en doubles.
Les tables "category" et subcategory" servent au classement des musiques par rubrique dans le logiciel de programmation musicale (RadioDJ).

Pour pouvoir éditer (remplacer ou cropper la pochette, ou modifier les tags artist ou titre - fonction accessible seulement aux admins du site bien sur) de la musique qui passe sans passer par le panneau d'admin du site, j'ouvre une page avec l'ID de la musique à éditer, dans l'URL.
Comme il est possible que cette musique soit une musique dont la pochette est celle d'une autre musique (utilisation du coverlink), j'ai besoin de lister toutes les musiques utilisant cette pochette.
Par conséquent, je dois utiliser une requête qui me parait pourtant simple :
[code]SELECT songs.artist, songs.title, songs.duration, songs.date_played, songs.artist_played, doubles.song_id AS songisdouble, coverlink.linkto AS linkto, songs.ID AS ID, subcategory.name AS subcatName, category.name AS catName
FROM songs
LEFT JOIN doubles ON songs.ID = doubles.song_id
LEFT JOIN coverlink ON songs.ID = coverlink.song_id
LEFT JOIN subcategory ON subcategory.ID = songs.id_subcat
LEFT JOIN category ON category.ID = subcategory.parentid
WHERE songs.ID = '35'
OR coverlink.linkto = '35'
OR coverlink.song_id = '35'[/code]
Les résultats sortent comme attendu (dans cet exemple, 7 musiques utilisent la même pochette, j'ai bien les 7 lignes), mais elle met environ 4 ou 5 secondes à être exécutée. C’est juste impensable. Pas un problème hardware car idem sur 2 pc et chez l'hébergeur :(

Si je ne laisse qu'un critère dans le WHERE, la requête est exécutée en quelques ms , mais je n'ai pas tous les résultats que je veux.

Je ne sais pas du tout où chercher et cette lenteur me rend ouf :(

Si quelqu'un a une piste, je suis preneur :)

Merkouin :)