Bonjour,
 
 
Après une rapide recherche j'ai pas trouvé mon info, donc je pose la question :
 
J'ai une table (MySQL) qui fait à peu près 115 000 enregistrements.
La clé primaire est sur 4 champs.
Histoire d'accélérer le tout, j'avais créer un index sur ces même 4 champs.
 
Et je viens de remarquer que lors d'un insert dans cette table, la relecture après (des gros select) mettent du temps à s'exécuter. Après c'est bon. Un nouveau insert, et de nouveau, mes premiers select sont lents... etc.
 
Bref, 2 questions :
- Est-ce que mon index qui est sur les même champs que la clé primaire est judicieux ? Car une clé primaire est censé déjà indexer, donc n'y-a-t-il pas double index dans ma table ?
- Sur quelle champs metteriez-vous les index ?
 
Voilà, s'il y a un spécialiste SGBD dans le coin, suis preneur de ses conseils éclairés !

la cle primaire est effectivement deja indexee
j aurais mis un index sur les autres champs presentant une cardinalite importante et souvent utilises dans tes criteres

La plupart du temps, c'est des select avec des where sur les 4 champs (vu que pour avoir un enregistrement unique, il faut que je recherche sur ces 4 champs).
 
Et j'ai comme cardinalité 115814 pour la clé primaire et l'index ce qui est tout à fait logique et ce qui me fait aussi dire que mon index sert pas à grand chose...

oui ton index supplementaire est inutile voire encombrant

Ouais mais qque chose me dit qu'il y a moment d'optimiser tout ça quand même car des select sur 115 000 recs ca commence à devenir bourrin. Et 1 index par champs, je vois pas trop l'intérêt.

Je pensais à un truc
Peut être ajouter une colonne (indexée) qui contient une valeur quasi-unique, de faible taille (un entier sur 4 octets, voire sur 2), calculée depuis les 4 champs de la clé.
Lors d'une recherche, calculer cette valeur et l'ajouter au WHERE, en faisant en sorte que la recherche se fasse d'abord sur cette valeur. L'index correspondant étant de faible taille (à 2 octets par ligne, même 115000 lignes représentent une volumétrie assez faible), ca devrait aller assez vite.
Si le calcul de cette valeur est bien étudié, la recherche sur l'index devrait renvoyer très peu de lignes, le SGBD n'aura plus qu'à regarder laquelle correspond aux 4 champs de la clé  
(venez pas me dire que je ré-invente le hash-code, ca me vexerais   )
 
C'est peut être idiot comme approche mais je pense que ca mérite d'être exploré

vérifie que ton index par défaut sur ta clé primaire est bien utilisé, check peut etre si les types utilisés dans ton where sont bien ceux des champs de la db, par exemple alpha numérique <> numérque, '0000' <> 0000 dans ce cas la par exemple ton index ne sera pas utilisé.
en mysql je ne sais pas comment vérifier cela par contre, faudrait trouver l'execution plan.
 
parceque j'ai l'impression qu'il se passe:
 
select 1 - full scan de la table
select 2 - plus rapide car les données de select 1 sont dans le cache
insert 1
select 3 - re fullscan
 
 
 
un champ hashcodé est utile pour relier deux tables mais la par contre il serait bien embeté pour son filtre dessus, et 2 octets pour 115000 records ca va etre sport ^^

Merci pour vos réponses !
 
 
Pas bête ton idée mrbebert même si mes where sont basés le plus souvent sur 2 id + 2 timestamp (de mémoire) qui permet de rendre l'enregistrement unique. Donc pour trouver le 'hash' qui va bien pour tenir compte de ces infos, va falloir que je me creuse les méninges mais ué pourquoi pas. Solution à approfondir.
 
Sinon casimir, pour la vérif des types, j'en avais jamais entendu parler. Donc d'après ce que tu me dis, quelque chose du genre where id_truk = '23' (en supposant que id_truk soit une clé primaire) ferait que le SGBD n'utiliserait pas l'index ? Ca me parait bizarre car je pense que la conversion alpha > int se fait en interne dans ce cas là.
id_truk = 23 doit marcher (c'est du PHP) mais bon je ne pense pas que ca interagisse sur l'utilisation de l'index ou non. Ceci dit je parle sans savoir...
A moins que tu parles d'autres choses que la syntaxe elle-même.
 
Pour l'histoire de cache, en fait, j'avais plutôt l'hypothèse suivante :
- select 1 : création de l'index (lent)
- select 2 (différent) : utilisation de l'index (rapide)
- select 3 (différent) : utilisation de l'index (rapide)
- insert 1
- select 4 : recréation de l'index (lent)
etc.
 
Je testerai l'histoire des types, sait-on jamais.

Laisse béton ta solution merdique d'un champ unique qui remplace la clé primaire. ca sert à rien de toute façon.
 
Déjà, quand tu fais un select qui porte sur les 4 champs de ta clé composite, quelque soit le nombre de lignes (même avec 1000 fois plus) ça ne devrait pas exceder quelques millisecondes, même sur un 386 ashmatique avec 4 Mo de mémoire.
 
donc si t'as des problèmes de lenteur dans ton cas, c'est que tu ne nous donne pas toutes les infos.
 
file-nous la structure de ta table.
file-nous des exemples de requêtes effectuées dedans.
est-ce un serveur mutualisé ? fait-il d'autre traîtements lourd en parallèle ?