Discussion :

[grunk]

Bonjour à tous,

Je vais être amener à travailler avec des bases (relativement) importantes , pouvant sans doute atteindre quelques millions de lignes par tables.

Mon but est d'avoir une recherche la plus rapide sur ces grosses tables. A priori les requêtes devrait rester assez simple du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT champ FROM matable WHERE autrechamp = "reference";

Comment puis je dimensionner le plus justement possible la RAM à utiliser sur le serveur pour que mysql stock ses index intégralement en RAM ?

Quel sont les paramètres à regarder en priorité dans la config mysql ?

Y'a t'il des particularités au niveau de l'index à utiliser sachant que la référence servant à la recherche sera très certainement unique (une chaine de 10 caractères) ?

Plus généralement avez vous des conseils pour travailler sur des gros volumes de données ? (plus en nombre de ligne qu'en poids de base)

merci

[SQLpro]

Il est parfaitement stupide de vouloir stocker l'intégralité d'un index en ram !

Avant d'émettre de telle hypothèse commencer par vous former et comprendre comment fonctionne un SGBDR, son cache et ce qu'est un index. Vous comprendrez alors ma première phrase...

Quelques pistes :
http://sqlpro.developpez.com/cours/quoi-indexer/
http://blog.developpez.com/sqlpro/p9...ut_sur_l_index
http://blog.developpez.com/sqlpro/p1...sql_sargable_c
http://blog.developpez.com/sqlpro/p5...t_ce_que_c_est
http://blog.developpez.com/sqlpro/p6..._oui_mais_quoi

et plus particulièrement le chapitre de mon livre sur SQL consacré à l'indexation.

A +

[grunk]

C'est suite à la lecture de la doc de mysql que je m'interrogeais :

Les blocs d'index des tables MyISAM et ISAM sont mis en buffer et partagés par tous les threads. key_buffer_size est la taille du buffer utilisé

http://dev.mysql.com/doc/refman/5.0/...variables.html

Donc pour moi c'est sous entendu que tant que mysql à de la place (dans la limite de key_buffer_size) il colle les index à utiliser en ram. Et donc si l'index est en ram on économise un accès disque , d'autant plus intéressant si l'index est couvrant.

Ou alors j'ai rien compris ?

[SQLpro]

Je confirme :
1) vous avez rien compris
2) vous avez une excuse, la doc de MySQL est farcie de conneries en particulier dans sa version française... Je me souvient d'une traduction qui disait que MySQL ne verrouille jamais !!! Je l'avais cité en exemple du crétinisme qui règne sur Internet....

Pour mettre un index en RAM il fait lire le disque, ce qui coute cher. Quel est donc l'intérêt de mettre la totalité d'un index en RAM si vous n'utilisez pas tout l'index ? Et quand vous n'aurez plus assez de RAM parce que votre index aura grossit, que ferez vous ?

A +