ZephLe 15/06/2015 à 21:57

Hello,

j'ai un problème de performance avec une requête MySQL que je n'arrive pas à comprendre (pour info, c'est la cause des lenteurs actuelles de la page "mes sujets"). J'ai essayé de le reproduire avec les conditions les plus simples possibles, voilà ce que ça donne :

SELECT
	member.id,
	member_cache.id,
	section.id,
	topic.id
FROM
	topic
	INNER JOIN
	(
		section
		INNER JOIN
		(
			member
			LEFT JOIN (member_cache) ON member_cache.id = member.id
		) ON member.id = section.last_member
	) ON section.id = topic.section
WHERE
	topic.last_time IS NOT NULL
ORDER BY
	topic.last_time DESC
LIMIT 0, 1

Schéma des tables utilisées dans cette requête

CREATE TABLE `member` (
  `id` int(10) unsigned NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `member_cache` (
  `id` int(10) unsigned NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE TABLE `section` (
  `id` int(10) unsigned NOT NULL,
  `last_member` int(10) unsigned NOT NULL DEFAULT '0'
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

CREATE TABLE `topic` (
  `id` int(10) unsigned NOT NULL,
  `section` int(10) unsigned NOT NULL,
  `last_time` int(10) unsigned NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

ALTER TABLE `member`
  ADD PRIMARY KEY (`id`);

ALTER TABLE `member_cache`
  ADD PRIMARY KEY (`id`);

ALTER TABLE `section`
  ADD PRIMARY KEY (`id`);

ALTER TABLE `topic`
  ADD PRIMARY KEY (`id`), ADD KEY `section__last_time` (`section`,`last_time`), ADD KEY `last_time` (`last_time`);

C'est une requête qui est supposée sortir les N derniers sujets (en l'occurrence un seul) triés par date de dernière activité (table "topic"), ainsi que leur section parente (table "section"), le dernier posteur de chaque sujet (table "member") et quelques informations supplémentaires sur ce posteur (table "member_cache"). Si j'exécute cette requête avec un "EXPLAIN", j'obtiens ça :

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	section	ALL	PRIMARY	NULL	NULL	NULL	2188	Using temporary; Using filesort
1	SIMPLE	member	eq_ref	PRIMARY	PRIMARY	4	temporary.section.last_member	1	Using index
1	SIMPLE	member_cache	eq_ref	PRIMARY	PRIMARY	4	temporary.section.last_member	1	Using index
1	SIMPLE	topic	ref	section__last_time,last_time	section__last_time	4	temporary.section.id	106	Using index condition

Ce que je ne comprends pas c'est que MySQL se retrouve à scanner 2188 lignes de la table "section" (1ière ligne du tableau, valeurs en rouge) alors que la seule utilisation de cette table est faite pour récupérer la section parente de chaque sujet, et qu'on utilise pour ça son champ "id" qui se trouve être sa clé primaire. C'est d'ailleurs bien indiqué dans la première ligne, on voit comme "possible_keys" PRIMARY, mais au final aucune clé n'est utilisée pour une raison qui m'échappe et on se retrouve à scanner toute la table.

Pourquoi est-ce que MySQL décide de ne pas utiliser cet index ? C'est d'autant plus curieux que si je supprime la jointure la plus intérieure sur "member_cache" (qui a priori n'influe en rien sur la table "section"), alors l'index est correctement utilisé et la requête tourne beaucoup plus vite. Ça parle à quelqu'un ? À défaut, vous savez comment je pourrais avoir plus d'informations sur les raisons qui provoquent ce choix de MySQL ?

Si vous voulez reproduire en local, j'ai exporté la base et les données utilisées ici, et j'ai constaté le problème sur les versions 5.5.35-log et 5.6.15 de MySQL.