Discussion :

[gmic7]

Bonjour,

j'ai un petit problème d'optimisation avec une requête a priori simple :

Code :

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

1
2
3
4
5
SELECT vote.sel_id AS sel_id, SUM(vot_nb_voix) AS nb_voix, cat_id
FROM vote NATURAL JOIN selection
WHERE cam_id = 1 AND vot_type = 1
GROUP BY vote.sel_id
ORDER BY cat_id ASC, nb_voix DESC

Une requête pour connaitre le nombre de voix pour chaque sélection (un vote peut correspondre à plusieurs voix).
Et bien elle s'exécute en 9 secondes avec environ 40 entrées dans la table sélection et 150 000 dans la table vote.

Les 2 tables concernées sont :

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
17
18
19
20
21
22
CREATE TABLE `selection` (
  `sel_id` int(10) unsigned NOT NULL auto_increment,
  `cam_id` int(10) unsigned NOT NULL,
  `cat_id` int(10) unsigned NOT NULL,
  `sel_titre` varchar(255) collate utf8_unicode_ci NOT NULL
  PRIMARY KEY  (`sel_id`),
  KEY `selection_FKIndex1` (`cat_id`),
  KEY `selection_FKIndex2` (`cam_id`)
)
 
CREATE TABLE `vote` (
  `vot_id` int(10) unsigned NOT NULL auto_increment,
  `sel_id` int(10) unsigned default NULL,
  `eta_id` int(10) unsigned default NULL,
  `vot_type` tinyint(3) unsigned NOT NULL,
  `vot_nb_voix` int(10) unsigned NOT NULL,
  `vot_date` datetime NOT NULL,
  `vot_ip` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`vot_id`),
  KEY `vote_FKIndex1` (`eta_id`),
  KEY `vote_FKIndex3` (`sel_id`)
)

Un EXPLAIN me donne ceci :

Code :

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

1
2
3
id     select_type     table     type     possible_keys     key     key_len     ref     rows     Extra
1     SIMPLE     selection     ref     PRIMARY,selection_FKIndex2     selection_FKIndex2     4     const     18     Using temporary; Using filesort
1     SIMPLE     vote     ref     vote_FKIndex3     vote_FKIndex3     5     selection.sel_id     2940     Using where

Edit : rajout d'une copie écran du explain plus simple à lire que le c/c :

Ca m'a l'air pourtant plutôt bien, les index sont bien utilisés.

Comment expliquer une telle lenteur ?

Merci par avance.

[Antoun]

Qu'est-ce que ça donne si tu mets un INNER JOIN avec une condition de jointure explicite à la place du NATURAL JOIN ?

[gmic7]

Même problème avec un INNER JOIN à la place du NATURAL JOIN, c'est même un peu plus long.

[CinePhil]

À tout hasard, lance une optimisation des tables.

[GyZmoO]

Salut.

L'explain montre qu'il va avoir besoin d'un filesort et d'une table temporaire (car les champs utilisés dans le ORDER BY sont != de ceux présents dans le GROUP BY)...

Peut être c'est ça qui plombe l'exécution?

[CinePhil]

Salut.

L'explain montre qu'il va avoir besoin d'un filesort et d'une table temporaire (car les champs utilisés dans le ORDER BY sont != de ceux présents dans le GROUP BY)...

Peut être c'est ça qui plombe l'exécution?

Tu mets le doigt sur un truc qui m'avait échappé ! La requête aurait été refusée par un autre SGBD car les colonnes ne faisant pas l'objet d'un calcul dans le SELECT ne sont pas toutes dans le GROUP BY et ne semblent pas en dépendance directe (pas de la même table).
Ce qui entraîne d'ailleurs une valeur aléatoire pour la colonne cat_id !

Essaie d'ajouter cat_id dans le GROUP BY. Ça aura au moins le mérite de rendre ta requête syntaxiquement plus juste.