Quel est le plus rapide, key_cache ou cache du système d'exploitation?

Question

Dans un tb avec 1 mil. lignes si je fais (après je redémarre l'ordinateur - donc rien il est mis en mémoire cache):
1. SELECT price,city,state FROM tb1 WHERE zipId=13458;
le résultat est 23rows à 0.270s

après que je lance « INDEX DE LA CHARGE EN CACHE TB1 » (key_buffer_size = 128M et indice total taille pour tb est 82M): 2. SELECT price,city,state FROM tb1 WHERE zipId=24781;
le résultat est 23rows dans 0.252s, Key_reads reste constante, Key_read_requests est incrémenté avec 23

BUT après je charge 'zipId' dans le cache du système d'exploitation, si je fais tourner de nouveau la requête:
2. SELECT price,city,state FROM tb1 WHERE zipId=20548;
le résultat est 22rows en 0.006s

Ceci est juste un exemple simple, mais je cours des dizaines de tests et de combinaisons. Mais les résultats sont toujours les mêmes.
J'utilise: MySql avec MyISAM, WINDOWS 7 64, et le query_cache est 0; zipId c'est un index régulier (pas la clé primaire)

DEVRAIT PAS key_cache être plus rapide que le cache du système d'exploitation ??
NE DEVRAIT PAS être une énorme différence de vitesse, après avoir chargé l'index dans le cache ??
(dans mon test c'est presque pas de différence).

J'ai lu beaucoup de sites Web, de tutoriels et de blogs à ce sujet, mais aucun d'entre eux ne parle vraiment de la différence de vitesse. Donc, toutes les idées ou les liens seront grandement appréciés.
Merci.

Answer 1

Sous le traitement de requête normal, MySQL analyse l'index pour les valeurs de la clause where (c'est-à-dire zipId = 13458). Utilise ensuite l'index pour rechercher les valeurs correspondantes de la table principale MyISAM (un second accès au disque). Lorsque vous chargez la table en mémoire, les accès au disque sont tous effectués en mémoire, pas en lisant un vrai disque.

La partie lente de la requête est la recherche de l'index dans la table principale. Ainsi, le chargement de l'index en mémoire peut ne pas améliorer la vitesse de la requête.

Une chose à essayer est Explain Select sur vos requêtes pour voir comment l'index est utilisé.

Modifier: Puisque je ne pense pas que les réponses à vos commentaires s'inséreront dans un espace de commentaire. Je vais leur répondre ici. MyISAM n'a pas de cache en lui-même.

Il repose sur le système d'exploitation pour effectuer la mise en cache du disque. La quantité de votre table mise en cache dépend de ce que vous utilisez dans le système et de la quantité de données que vous lisez. Windows en particulier ne permet pas à l'utilisateur de contrôler les données mises en cache et pendant combien de temps.

Le système d'exploitation met en cache les blocs de disque (fragments 4K ou 8K) du fichier d'index ou du fichier de table complet.

SELECT indexed_col FROM tb1 WHERE zipId+0>1 

requêtes comme celle-ci où vous utilisez des fonctions sur le prédicat (clause Where) peut causer MySQL pour faire des analyses complètes de table plutôt que d'utiliser un indice. Comme je l'ai suggéré ci-dessus, utilisez EXPLAIN SELECT pour voir ce que fait MySQL.

Si vous souhaitez plus de contrôle sur le cache, essayez d'utiliser une table INNODB.Le InnoDB engine crée son propre cache que vous pouvez dimensionner, et fait un meilleur travail en conservant les éléments les plus récents.