[MySQL] Pourquoi il n'utilise pas l'index sur cet order by ?

Marsh Posté le 01-02-2004 à 22:23:54

J'ai une requete toute conne de type :

Code :

SELECT * FROM produit ORDER BY id

Et apparement (d'après l'EXPLAIN), il n'utilise pas l'index (qui existe sur id) pour cette requete.
alors que si je fais un truc du genre

Code :

SELECT * FROM produit WHERE id=5465

là il l'utilise sans problème.

Je viens de lire http://www.nexen.net/docs/mysql/an [...] sation.php et je ne vois vraiment pas ce qui pourrait empêcher l'utilisation de l'index dans mon cas :-(

J'ai mysql 4.0.16

Message édité par dweis le 01-02-2004 à 22:24:20

Reply

Marsh Posté le 01-02-2004 à 22:23:54

Reply

Marsh Posté le 01-02-2004 à 22:28:51

sauf erreur l'index sur la clé primaire est physique (les données sont physiquement l'une après l'autre)

Donc pas besoin de faire un index logique (seconde index)

Je ne sais pas si je réponds à ta question mais c'est peut-être une piste

Reply

Marsh Posté le 01-02-2004 à 23:25:21

euh non, désolé mais ça a aucun rapport avec mon problème :-/

Enfin pour mon problème, je suis entrain de me demander si c'est pas simplement un bug du EXPLAIN parce que les requetes vont drôlement vite alors je pense qu'elles utilisent quand même l'index

Reply

Marsh Posté le 02-02-2004 à 00:44:23

Bizarre :??:
Tu aurais la structure de la table ? [:figti]

Reply

Marsh Posté le 02-02-2004 à 01:34:31

Code :

CREATE TABLE produit (
id int(11) NOT NULL default '0',
nom varchar(250) NOT NULL default '',
cat int(11) NOT NULL default '0',
PRIMARY KEY (id),
KEY i_cat (cat),
FULLTEXT KEY i_nom (nom)
) TYPE=MyISAM;

Reply

Marsh Posté le 02-02-2004 à 01:35:01

le problème est le même avec cat, un ORDER BY cat n'utilise pas d'index... :-/

Reply

Marsh Posté le 02-02-2004 à 01:38:18

Effectivement, il a pas l'air d'utiliser la clé pour le tri [:figti]

Reply

Marsh Posté le 02-02-2004 à 09:26:32

dweis a écrit :

euh non, désolé mais ça a aucun rapport avec mon problème :-/
Bah si, justement, ca a complètement rapport avec ton problème

Enfin pour mon problème, je suis entrain de me demander si c'est pas simplement un bug du EXPLAIN parce que les requetes vont drôlement vite alors je pense qu'elles utilisent quand même l'index
Ce n'est pas parce que c'est rapide qe ça utilise un index, ça peut même être le contraire.

Reply

Marsh Posté le 02-02-2004 à 09:29:01

gizmo a écrit :

Bah si, justement, ca a complètement rapport avec ton problème

Non puisque comme je l'ai dit, j'ai le même problème avec ORDER BY cat qui n'est pas la clé primaire

Reply

Marsh Posté le 02-02-2004 à 09:30:25

gizmo a écrit :

Ce n'est pas parce que c'est rapide qe ça utilise un index, ça peut même être le contraire.

Ouais mais bon s'il me tri 700.000 éléments en moins de 0.01s, j'ai quand même des doutes...

Reply

Marsh Posté le 02-02-2004 à 09:30:25

Reply

Marsh Posté le 02-02-2004 à 12:36:59

Ils sont déjà trié. C'est ce que veut dire Gizmo. Un primary key est un index de type "UNIQUE" et "CLUSTERED".

UNIQUE implique qu'il n'y a pas de doublon (donc PK) et CLUSTERD indique que les champs sont physiquement triés dans le fichier de la base, donc pas besoin de lire l'index pour retrouver les champs dans l'ordre.

Si tu crées un autre index clustered ne faisant pas appel à ID, alors à ce moment tu verras qu'il utilise l'index pour retrouver l'ordre sur l'ID, car il ne seront plus dans l'ordre.

Reply

Marsh Posté le 02-02-2004 à 12:45:53

Je suppose que par défaut les indexes sont de type hachage (qui permet de chercher *une* valeur en temps constant), donc sans ordre, il faut forcer ton index à BTREE (arbre binaire) pour qu'il soit utile à tout ce qui est ordre, mais je sais pas comment on fait dans MySQL.

---------------
trainoo.com, c'est fini

Reply

Marsh Posté le 02-02-2004 à 12:49:18

non les index sont bien en btree

Reply

Marsh Posté le 02-02-2004 à 12:50:49

MagicBuzz a écrit :

Ils sont déjà trié. C'est ce que veut dire Gizmo. Un primary key est un index de type "UNIQUE" et "CLUSTERED".

UNIQUE implique qu'il n'y a pas de doublon (donc PK) et CLUSTERD indique que les champs sont physiquement triés dans le fichier de la base, donc pas besoin de lire l'index pour retrouver les champs dans l'ordre.

Si tu crées un autre index clustered ne faisant pas appel à ID, alors à ce moment tu verras qu'il utilise l'index pour retrouver l'ordre sur l'ID, car il ne seront plus dans l'ordre.

oui mais non puisque le problème est le même pour le champ cat et ce n'est donc pas le champ primary key

Reply

[MySQL] Pourquoi il n'utilise pas l'index sur cet order by ?

Sujets relatifs:

Leave a Replay