Discussion :

[clavier12AZQSWX]

bonjour,

sur le serveur de prod (1&1 mutualisé), j'ai une requête qui prend 8s à l'affichage via l'interface php (dont je n'ai pas la main sur le script php pour le modifier).
quand je fais juste un affichage des données via un select dans phpmyadmin, ça ne prend que 1s.

d'où pensez-vous que la lenteur provienne ? config php ou config mémoire serveur du script ou autre ?

Durant ces 8s, y-a-t-il un moyen de trouver le nœud à améliorer ?

Questions sql :
si ma requête est une VIEW et qu'elle se termine par un "order by 1,2,3,4", faut-il obligatoirement ajouter des index sur les champs ciblés par le order ?
Par exemple, mon champs 1, est un CONCAT (nom,' ',prenom), est-ce que ça veut dire que je dois ajouter aussi un index sur les champs nom et prénom de la table dont se sert cette VIEW ?

Merci pour votre lecture et conseils.

[SQLpro]

https://sqlpro.developpez.com/cours/quoi-indexer/

A +

[clavier12AZQSWX]

merci , je vais lire.

je viens de remarquer qu'en forcant un affichage de 10 tuples par page plutôt que 3, je passe de 8s à 22s.
cela ne supposerait-il pas un problème de performance PHP ?

[clavier12AZQSWX]

re-bonjour,

j'ai lu et appliqué les bases conseillés.
mais ça n'a rien amélioré même après avoir dumper/recrrer les tables optimisées.
pat contre, la requête issue sur une vu est une requête union de type
create view
select...
union
select ...

si je ne garde que la 1ere partie (avant le union), c'est rapide instantané
si je garde que la 2nd partie (après le union) c'est lent.
donc je suppose que le problème vient soit de la 2nd partie de la requête soit des paramètres liés à l'union dans MYSQL.

Je continue de chercher, mais je vous mets ma requête au cas où qq chose vous titille : (gras = champ indéxé)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE OR REPLACE VIEW v_data_pointages AS
  
	SELECT edt_id AS IDI,
		CONCAT (UPPER(etu_nom),' ',etu_prenom) AS ETUDIANT,
		edt_date AS LADATE,
		WEEK(edt_date,1) AS SEMAINE, 
		DATE_FORMAT(edt_date, "%Y-%m") AS PERIODE,
		' En attente des émargements' AS STATUT,
		TIME(TIMEDIFF(edt_heure_fin,edt_heure_debut)) AS DUREE,
		TIME_TO_SEC(TIME(TIMEDIFF(edt_heure_fin,edt_heure_debut))) AS DUREE_SECONDES
	FROM edt
	LEFT JOIN etudiants ON edt_grp_id IN (etu_grp1_id,etu_grp2_id,etu_grp3_id,etu_grp4_id,etu_grp5_id,etu_grp6_id,etu_grp7_id,etu_grp8_id,etu_grp9_id) AND etu_visible=1
	WHERE edt_visible=1 
	AND edt_id NOT IN (SELECT DISTINCT point_edt_id FROM pointages WHERE point_etu_id=etu_id)
		
	ORDER BY 2,3,4,5,6;

Je sais que la structure in (c1,c2,c3,c4 ..etc) n'est pas idéale et mauvaise en SGBDR, mais je n'avais pas le choix. est-ce la cause de la lenteur?
pour infos, ma table principale EDT comporte QUE 630 lignes et la table fille en jointure 125 lignes. La table secondaire (dans le NOT IN) comporte 6000 lignes.

La recherche continue, je vais essayer d'enlever la seconde partie "NOT IN"...

ps : je n'ai pas mis la balise CODE car sinon le gras ne fonctionne plus.

[clavier12AZQSWX]

rebonjour,

j'ai avancé d'un grand pas.
en isolant la requête de construction de la VIEW, j'ai découvert que c'est une partie dans le second block UNION qui fait ralentir beaucoup :

C'est la partie NOT IN :

Code :

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

AND edt_id NOT IN (SELECT DISTINCT point_edt_id FROM pointages WHERE point_etu_id=etu_id)

J'ai googlé, et j'ai vu que c'était un cas classique (que je connais pas) dans les lenteurs mysql. J'ai vu qu'on pouvait transformer la requête NOT IN en LEFT JOIN + un ..is null ce que j'ai fait :

Code :

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

1
2
LEFT JOIN pointages ON edt_id=point_edt_id AND point_etu_id=etu_id
	WHERE  AND point_edt_id is null

avant ce qui prenait 22s ne prend plus que 9s
et ce qui prenait 8s ne prend plus que 3 ou 4s c'est presque un gain x2. C'est joli mais la requête n'est plus "lisible", je dois y ajouter un commentaire pour me souvenir de l'astuce et de la complication d'écriture sql. Le NOT IN était trés compréhensible.

Maintenant si quelqu'un sait si ce dernier pallier de lenteur je peux le réduire avec une optimisation de la config de mysql ou de php, ça me serait utile.

Merci pour vos aides et votre lecture.

[Paraffine]

C'est peut-être plus "parlant" avec une clause "NOT EXISTS" (à tester car cela se montre parfois moins performant) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT edt_id AS IDI,
		CONCAT (UPPER(etu_nom),' ',etu_prenom) AS ETUDIANT,
		edt_date AS LADATE,
		WEEK(edt_date,1) AS SEMAINE, 
 		DATE_FORMAT(edt_date, "%Y-%m") AS PERIODE,
		' En attente des émargements' AS STATUT,
		TIME(TIMEDIFF(edt_heure_fin,edt_heure_debut)) AS DUREE,
		TIME_TO_SEC(TIME(TIMEDIFF(edt_heure_fin,edt_heure_debut))) AS DUREE_SECONDES
	FROM edt
	LEFT JOIN etudiants ON edt_grp_id IN (etu_grp1_id,etu_grp2_id,etu_grp3_id,etu_grp4_id,etu_grp5_id,etu_grp6_id,etu_grp7_id,etu_grp8_id,etu_grp9_id) AND etu_visible=1
	WHERE edt_visible=1 
	AND NOT EXISTS (select 1 FROM pointages WHERE point_etu_id=etu_id and point_edt_id = edt_id)
 
	ORDER BY 2,3,4,5,6;

Sans vouloir être désagréable, cette modélisation avec etu_grp1_id ... etu_grp9_id est parfaitement hideuse