Pb de temps d'execution pour trouver le dernier enregistrement [Résolu]

[Nathan]

Salut,
Voila mon pb:
J'ai un table "T1" qui à environ 1,5 million de lignes et les colonnes suivantes :
IDENT(texte)
DONNEES(texte)
EVENT(num)
DATE(date)
Il n'y a pas de clé primaire. Il y a plusieurs enregistrement avec le même IDENT.
J'ai créé les index suivants :
IDENT
DATE
EVENT
IDENT + EVENT + DATE
IDENT + EVENT
Je cherche les données (DONNEES) du dernier enregistrement (selon DATE) pour un identifiant donné (IDENT) et un lot d’événements (EVENT).
J'ai donc pondu cette requête :

Code :

1
2
3
4
5
6
SELECT DONNEES 
FROM T1 
WHERE IDENT="toto" 
AND EVENT IN (8,45,46,47,205,206)
ODRER BY DATE DESC
LIMIT 1

Jusque là tout vas bien!
Mais en fonction de l'identifiant que je rentre j'ai des temps de réponse carrément anarchiques.
Par exemple pour l'identifiant "toto" qui à 38000 lignes la requête s’exécute en 0,3 secondes tandis que pour l’identifiant "titi" qui à 3500 lignes elle met 20 secondes !!!?
Comment ça se fait d'après vous??

[CinePhil]

Si tes IDENT font moins de 256 caractères, passe la colonne en VARCHAR.

Comment as-tu créé l'index sur la colonne IDENT ?

Envoyé par Doc MySQL

Pour les colonnes BLOB et TEXT la longueur d'index est obligatoire. La requête suivante crée un index en utilisant les 10 premiers caractères de la colonne name :
mysql> CREATE INDEX part_of_name ON customer (name(10));

[Nathan]

En fait mon IDENT est déjà un varchar(100).
Par contre je n'ai pas précisé la longueur lorsque j'ai créé l'index (avec phpmyadmin) mais dans les faits tous mes IDENT font 10 caractères pour le moment.
Pense tu qu'il faut que je re-crée l'index en précisant la longueur?

[CinePhil]

Envoyé par Nathan

En fait mon IDENT est déjà un varchar(100).
Pense tu qu'il faut que je re-crée l'index en précisant la longueur?

Non, par contre tu peux réduire la taille du VARCHAR si tu es sûr que tous tes IDENT font maxi 10 caractères et n'en feront jamais plus.

Peut-être aussi que l'absence de clé primaire est préjudiciable.

[Nathan]

Alors,
J'ai supprimé puis recréé l'index sur le IDENT en précisant la longueur (100 car ils ne font que 10 pour le moment mais ça vas changer).
J'ai aussi ajouté une colonne ID en auto-incrément et clé primaire.
Mais tout cela n'a rien changé.....
J'ai lancé une défragmentation de la table avec Phpmyadmin pour voir ...
Je vous tend au courant.

[CinePhil]

On peut avoir le résultat de l'EXPLAIN de ta requête ?

[Nathan]

Après un silence de quelques jours, je reviens à la charge pour vous donner ma solution.
J'ai fait des tests dans tous les sens, avec des clé primaires, des FORCE INDEX, avec un ORDER BY ASC et DESC, sans le LIMIT, des OR à la place du IN, etc...
Résultat, toujours pareil les temps de réponse sont complètements aléatoires!
Mais je me suis aperçus que mes table étaient en INNODB (je ne savais même pas ce que ça voulait dire).
Je me suis un peut renseigner sur internet pour comprendre les différences entre INNODB et MYISAM pour finalement m’apercevoir que comme je n'utilise pas de transaction, je n'ai pas besoin que mes table soit en INNODB.
Et qu'en plus les SELECT "complex" sont plus rapide en MYISAM.
J'ai donc passé mes tables en MYISAM et ... Oh miracle, les temps de réponse sont de quelques millisecondes!
Voila, en espérant que ça servira à quelqu'un d'autre ...
Merci.

[Maljuna Kris]

Saluton,
Il y a bien d'autres différences entre MyISAM et InnoDB, notamment les recherches FULL-TEXT non supportées en InnoDB qui, par contre, implémente les FOREIGN KEYS.