Requête très longue à charger

**LucasB16** · 28/09/2014, 18h11

Bonjour,

j'ai monté un site, ou le but est de voir des profils de gens uns par uns.

Mais dès que l'utilisateur A voit l'utilisateur B, il ne doit plus pouvoir le revoir après, donc j'ai une table "membres_vus" ou j'inscris le pseudo de l'utilisateur qui a vu, et le pseudo de l'utilisateur vu.

Et pour afficher les profils, j'utilise cette requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT *
FROM users
WHERE users.login NOT IN (SELECT membres_vus.to FROM membres_vus WHERE membres_vus.from = "'.$_SESSION['login'].'")
ORDER BY RAND()

Mais la page est vraiment très très longue à charger, environ 30 secondes avec une bonne connexion... Au début il n'y avait que quelques dizaines de profils donc ça allait, mais maintenant il y a 1200 profils et plus de 50 000 vus...

Comment faire pour avoir le même système mais qui rame moins?

Merci d'avance,

Lucas

**sabotage** · 28/09/2014, 20h54

La page est longue a charger ou bien la requête est longue a executer ?
Ce n'est pas pareil.
Tu nous parles de "bonne connexion" mais la vitesse de connexion n'intervient pas dans l'execution d'une requête.
Donc il faudrait déjà identifier le point lent.

Tout de même : ORDER BY RAND() n'est pas efficace sur de grandes quantités de données.
Contrôle que le problème ne soit pas seulement là.

**LucasB16** · 28/09/2014, 21h58

La lenteur vient bien de la requête et non pas de la page, et le problème ne vient pas de la fonction RAND() j'ai essayé

**sabotage** · 28/09/2014, 23h45

Quel est le temps d'execution de la sous requête ?

**Celira** · 29/09/2014, 13h21

Tu as essayé ta requête directement sur la base (avec PhpMyAdmin ou assimilé) ?
Quel SGBD utilises-tu ? ya-t-il des index ?

**LucasB16** · 29/09/2014, 17h59

Envoyé par sabotage

Quel est le temps d'execution de la sous requête ?

Le temps d'éxecution de ma requête est de 19 secondes.

Envoyé par Celira

Tu as essayé ta requête directement sur la base (avec PhpMyAdmin ou assimilé) ?
Quel SGBD utilises-tu ? ya-t-il des index ?

Oui, j'ai essayé ma requête directement depuis ma base (cf. ci-dessus)
Mon SGBD est MySQL (SGBD de easy-hebergement.net)

**gmarsay** · 29/09/2014, 18h32

Si il y a beaucoup de champs sur la table "users", le "SELECT *" de ta requête peut être remplacé par la liste des champs que tu as besoin de récupérer.
Est-ce que tu as besoin de récupérer tous les membres d'un seul coup (soit 1200 profils pour un nouvel user...) ? Si non tu peux ajouter un "LIMIT <nb_membre_a_recuperer>" a la fin de ta requête.

**LucasB16** · 29/09/2014, 19h47

Envoyé par gmarsay

Si il y a beaucoup de champs sur la table "users", le "SELECT *" de ta requête peut être remplacé par la liste des champs que tu as besoin de récupérer.
Est-ce que tu as besoin de récupérer tous les membres d'un seul coup (soit 1200 profils pour un nouvel user...) ? Si non tu peux ajouter un "LIMIT <nb_membre_a_recuperer>" a la fin de ta requête.

J'ai tout essayé, rien ne marche.. Le problème vient du nombre d'entrées dans la table membres_vus. Quelqu'un m'a parlé d'indexation des données? J'ai essayé de me renseigner mais je ne suis pas expert en PHP, je ne comprends pas vraiment..

**sabotage** · 30/09/2014, 07h19

Le temps d'éxecution de ma requête est de 19 secondes.

Pas la requête entière, seulement la sous-requête.

Dans tous les cas ta requête serait beaucoup plus rapide si tu travaillais avec des id numériques et pas avec des logins.
Dans ta table "users" l'index devrait être un id numérique autoincrementé.
Dans membres_vus on aurait cet id au lieu du login.

**CosmoKnacki** · 30/09/2014, 09h13

Je pense qu'une bonne partie de la lenteur vient du fait que ta base est mal conçue. Au lieu de faire une table dans laquelle les logins sont répétés x fois pour chaque relation (ce qui prend de la place et n'est pas rapide), tu devrais plutôt utiliser les index de chaque login, exemple:

table: user

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
id | login          | champ1  | champ2 ...
-----------------------------------------------
 1 | Robert
 2 | Norbert
 3 | Gilbert
 4 | Philibert
...

table: membres_vus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
id | id_user | id_user_vu
-------------------------------
 1 |       4 |          2
 2 |       2 |          1
 3 |       1 |          2
 4 |       4 |          3
...

En faisant ça, au lieu de comparer des chaînes de caractères MySQL n'aura que des nombres à comparer, ce qui est plus rapide (et prend moins de place).

**aieeeuuuuu** · 30/09/2014, 11h13

Envoyé par LucasB16

Quelqu'un m'a parlé d'indexation des données? J'ai essayé de me renseigner mais je ne suis pas expert en PHP, je ne comprends pas vraiment..

Pour votre requête, vous pouvez placer cet index :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
CREATE UNIQUE INDEX UIX_VU ON membres_vus (FROM, TO)

Mais idéalement, il faudrait commencer par appliquer ce qui a déjà été dit, notamment l'utilisation d'identifiants numériques en lieu et place des logins.

**LucasB16** · 30/09/2014, 23h01

Merci à tous pour vos réponses!!!

Envoyé par CosmoKnacki

Je pense qu'une bonne partie de la lenteur vient du fait que ta base est mal conçue. Au lieu de faire une table dans laquelle les logins sont répétés x fois pour chaque relation (ce qui prend de la place et n'est pas rapide), tu devrais plutôt utiliser les index de chaque login, exemple:

table: user

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
id | login          | champ1  | champ2 ...
-----------------------------------------------
 1 | Robert
 2 | Norbert
 3 | Gilbert
 4 | Philibert
...

table: membres_vus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
id | id_user | id_user_vu
-------------------------------
 1 |       4 |          2
 2 |       2 |          1
 3 |       1 |          2
 4 |       4 |          3
...

En faisant ça, au lieu de comparer des chaînes de caractères MySQL n'aura que des nombres à comparer, ce qui est plus rapide (et prend moins de place).

Merci beaucoup, ça m'éclaire énormément!
Dois-je mettre des index pour les champs id_user & id_user_vu?

**LucasB16** · 02/10/2014, 16h35

up

**aieeeuuuuu** · 02/10/2014, 16h39

Je ne vois pas l’intérêt de la colonne id dans la table membres_vus.

Vous indiquez qu'un ne peut en voir un autre qu'une seule fois. Définissez donc le couple (id_user , id_user_vu) comme clef primaire, ce qui créera automatiquement l'index nécessaire à votre requête.

**LucasB16** · 02/10/2014, 17h16

Envoyé par aieeeuuuuu

Je ne vois pas l’intérêt de la colonne id dans la table membres_vus.

Vous indiquez qu'un ne peut en voir un autre qu'une seule fois. Définissez donc le couple (id_user , id_user_vu) comme clef primaire, ce qui créera automatiquement l'index nécessaire à votre requête.

D'accord!

Ma table est-elle bien conçue à présent? Les champs "id_membre" et "id_membre_vu" ont un Index "Primary"

**punkoff** · 02/10/2014, 19h42

bonjour,

non.
Une date cest une date et non un big int

**LucasB16** · 02/10/2014, 21h03

Envoyé par punkoff

bonjour,

non.
Une date cest une date et non un big int

Oui, mais la date est notée en timestamp

**manzeki** · 09/10/2014, 18h38

Vu que le Where est appliqué sur id_user le meilleur index sera id_user, id_user_vu et non id_user_vu, id_user

Essayez les requêtes suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT u.id, u.login
FROM users u
WHERE u.id NOT IN (SELECT id_user_vu FROM membres_vus WHERE id_user = '.$user_id . ')

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT u.id, u.login
FROM users u
INNER JOIN membres_vus v ON v.id_user NOT IN ('.$user_id . ') AND u.id = v.id_user_vu

Requête très longue à charger

Requêtes MySQL

Discussions similaires

Partager

Partager