Discussion :

[polux23]

Bonjour messieurs,

Je cherche a optimiser une requête , je constate que l'analyse du résultat via EXPLAIN semble surprenant, je m'explique, j'ai une table très simple :

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
CREATE TABLE `toto` (
  `id` tinyint(3) unsigned NOT NULL default '0',
  `mot` varchar(30) NOT NULL default '',
  UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
 
-- 
-- Contenu de la table `toto`
-- 
 
INSERT INTO `toto` VALUES (1, 'toto');
INSERT INTO `toto` VALUES (2, 'tata');
INSERT INTO `toto` VALUES (3, 'titi');
INSERT INTO `toto` VALUES (4, 'tutu');
INSERT INTO `toto` VALUES (5, 'momo');
INSERT INTO `toto` VALUES (6, 'mama');
INSERT INTO `toto` VALUES (7, 'mimi');
INSERT INTO `toto` VALUES (8, 'meme');
INSERT INTO `toto` VALUES (9, 'mumu');
INSERT INTO `toto` VALUES (10, 'mbmb');

Si je fait la requête suivante :

EXPLAIN SELECT id, mot FROM toto WHERE id IN ( 1, 2 )

J'ai le résultat suivant :
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | SIMPLE | toto | range | id | id | 1 | NULL | 2 | Using where

On vois que le nombre de lignes parcourus est bien de 2 : normal, j'ai bien un index, et je fait une recherche avec deux valeur dans mon where

Maintenant et c'est là que tout deviens surprenant avec une seconde requète

EXPLAIN SELECT id, mot FROM toto WHERE id IN ( 1, 2, 3 )

J'ai le résultat suivant :
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
1 | SIMPLE | toto | ALL | id | NULL | NULL | NULL | 10 | Using where

Et la on constate que tous les éléments de ma table sont parcouru, que le type de recherche passe de "range" à "ALL" alors la grande question est pourquoi ?

Nota, je fait des test en local sous windows avec phpmyadmin, j'ai remarqué que si je fait les tests en ligne (serveur linux) je constate le problème au delà de 8 condition dans mon WHERE IN ...... de plus, j'ai essayé de mettre l'index en clé primaire, clé index ou clé unique, j'ai le même problème dans les 3 cas.

[Maximil ian]

Salut,

J'imagine que l'optimiseur estime que le nombre de lignes à récupérer est suffisamment grand pour aller les lire en séquence directement dans les blocs de données plutôt que passer par l'index...

Sometimes MySQL does not use an index, even if one is available. One circumstance under which this occurs is when the optimizer estimates that using the index would require MySQL to access a very large percentage of the rows in the table. (In this case, a table scan is likely to be much faster because it requires fewer seeks.) However, if such a query uses LIMIT to retrieve only some of the rows, MySQL uses an index anyway, because it can much more quickly find the few rows to return in the result.

http://dev.mysql.com/doc/refman/5.0/...l-indexes.html

[polux23]

Ok, j'ai posé un LIMIT 0,3 à la fin et effectivement, j'ai le résultat escompté, je vais procéder de cette façon alors.

Merci de ton aide