Création d'index... Un peu de mal...

[Julia41]

Cela fait un moment que j'optimise dans tous les sens mes requêtes, mais là, je n'arrive pas à créer un index correct :/

La requete est :

SELECT id, name, see + lee AS num, UNIX_TIMESTAMP(added) AS ts FROM to ORDER BY info_hash;

id ==> int(10)
name ==> varchar(255)
see ==> int(10)
lee ==> int(10)
added ==> datetime
info_hash ==> blob

Résultat d'un explain :

id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	         Extra
1 	SIMPLE 	           to 	         ALL 	NULL 	        NULL    NULL 	NULL  7533 	Using filesort

J'ai tenté plusieurs combinaison pour créer un index correct, mais rien n'y fait...

Je débute pour tout ce qui est index, jointures, lors d'un simple select, cela va, mais là, c'est en dehors de mes "connaissances"...

Je ne sais pas si c'est le "info_hash" qui est un blob (binaire) qui pose problèmes...

S'il manque des informations, n'hésitez pas à me le dire (et aussi comment les trouver si c'est des questions plutôt spécifiques)...

 

[julienr]

d'après la doc les index sur une colonne blob ne pose plus de problème depuis la version 3 et quelques !
seulement il faut préciser la taille :

CREATE INDEX blob_index ON to (info_hash(10));

pour connaitre la taille max de ton blob :

select max( lenght( info_hash ) ) from to

ensuite tu pourras au pire explicitement demander à mysql d'utiliser cette index s'il ne le fait pas de lui même avec un

use index blob_index

voir

force index blob_index

à toi de jouer now

 

[BadProcESs]

Attendez, vous collez un index sur un blob ? Z'ètes pas fou ? Vous allez exploser la taille de la base avec ca, ainsi que les perfs, bref, tout l'effet escompté je pense. :roll:

Un index doit rester cantonner aux seuls champs numeriques, voir char(255).

 

[julienr]

ça doit pas être bien pire qu'un index fulltext... et puis ça dépend grandement de la taille sur lequel il est défini

 

[Julia41]

Bon, il fait 40 (octet je pense) mais l'index est déjà créer...
Je comprends mieux d'où venait ce "40"

Mais toujours ces KEYs à null sur un EXPLAIN :/

Pour BadProcESs, la table fait 40Mo et 3Mo sont reservés aux index (je ne trouve pas ça énorme) pour 8000 enregistrements...

 

[julienr]

j'ai fais un test sur une table de 400 000 lignes
order by sur une colonne ou il y a un index
résultat de la requete 0,007 s donc forcément que l'index a été utilisé
par contre dans le explain j'ai pareil que toi NULL ds possible_keys key key_len
par contre en utilisant force index ( index_colonne )
j'ai dans le explain :
key key_len de setter à mon index
mais bon le résultat d'éxécution est le même...

 

[Julia41]

j'ai fais un test sur une table de 400 000 lignes
order by sur une colonne ou il y a un index
résultat de la requete 0,007 s donc forcément que l'index a été utilisé
par contre dans le explain j'ai pareil que toi NULL ds possible_keys key key_len
par contre en utilisant force index ( index_colonne )
j'ai dans le explain :
key key_len de setter à mon index
mais bon le résultat d'éxécution est le même...

Donc mon index est utilisé ou alors je devrais forcer l'index dans le code ?

Je fais quelques tests en ce moment (avec tes idées)

Affichage des enregistrements 0 - 29 (7 545 total, Traitement en 0.0506 sec.)

Pas trouvé comment forcer l'index par contre

 

[julienr]

comme ceci :

SELECT id, name, see + lee AS num, UNIX_TIMESTAMP(added) AS ts FROM to FORCE INDEX( ton_index_blob) ORDER BY info_hash;

 

[Julia41]

Arf ouais, aucun changement de perfs :/

J'avais tenté de l'innoDB pour cette table, mais vu le nombre de SELECT aucun gain de perfs :/

Mais si j'EXPLAIN ta requete, j'ai toujours des NULL dans les colonnes Keys :/

Merci quand même pour vos infos, même si ça n'a pas l'air de marcher pour ce que je souhaite faire j'apprends pas mal
Rien que pour le "max lenght" je ne savais pas d'où venait cette valeur

Et quelques commandes que je ne m'étais jamais servit

 

[julienr]

arf
tente un

optimize table to

ça pourra qu'améliorer les perfs...

 

[Julia41]

arf
tente un

optimize table to

ça pourra qu'améliorer les perfs...

lol ça c'est en cron