Qu'est-ce que MySQL "Key Efficiency"
MySQL Workbench rapporte une valeur appelée "Key Efficiency" en association avec la santé du serveur. Qu'est-ce que cela signifie et quelles sont ses implications?
De MySQL.com , "Efficacité clé" est:
... une indication du nombre de
key_read_requestsqui a abouti à une réellekey_reads.
Ok, alors qu'est-ce que ça veut dire. Que me dit-il sur la façon dont je suis censé régler le serveur?
"Key Efficiency" est une indication de la valeur que vous obtenez des caches d'index conservés dans la mémoire de MySQL. Si votre efficacité de clé est élevée, alors MySQL effectue le plus souvent des recherches de clés à partir de l'espace mémoire, ce qui est beaucoup plus rapide que d'avoir à récupérer les blocs d'index pertinents du disque.
Le moyen d'améliorer l'efficacité des clés consiste à consacrer davantage de mémoire de votre système aux caches d'index de MySQL. La manière de procéder dépend du moteur de stockage que vous utilisez. Pour MyISAM, augmentez la valeur de key-buffer-size. Pour InnoDB, augmentez la valeur de innodb-buffer-pool-size.
Cependant, comme le souligne Michael Eakins, le système d'exploitation contient également des caches de blocs de disque auxquels il a accédé récemment. Plus votre système d'exploitation dispose de mémoire, plus il peut mettre en cache de blocs de disque. De plus, les disques durs eux-mêmes (et les contrôleurs de disque dans certains cas), ont également des caches - qui peuvent encore accélérer la récupération des données du disque. La hiérarchie est un peu comme ça:
- le plus rapide - récupérer les données d'index à partir du cache d'index de MySQL. Le coût est de quelques opérations de mémoire.
- récupérer les données d'index conservées dans le cache du système de fichiers du système d'exploitation. Le coût est un appel système (pour la lecture) et certaines opérations de mémoire.
- récupération des données d'index conservées dans le cache du système de disque (contrôleur et lecteurs). Le coût est un appel système (pour la lecture), la communication avec le périphérique de disque et certaines opérations de mémoire.
- le plus lent - récupération des données d'index à partir de la surface du disque. Le coût est un appel système, communication avec l'appareil, mouvement physique du disque (mouvement du bras + rotation).
En pratique, la différence entre 1 et 2 est presque imperceptible, sauf si votre système est très occupé. De plus, il est peu probable (à moins que votre système n'ait moins de réserve RAM que votre contrôleur de disque)) que le scénario 3 entre en jeu.
J'ai utilisé des serveurs avec des tables MyISAM avec des caches d'index relativement petits (512 Mo), mais une mémoire système massive (64 Go) et j'ai eu du mal à démontrer la valeur d'augmenter la taille du cache d'index. Je suppose que cela dépend de ce qui se passe sur votre serveur. Si tout ce que vous exécutez est une base de données MySQL, il est fort probable que le cache du système d'exploitation soit assez efficace. Cependant, si vous exécutez d'autres travaux sur le même serveur et que ceux-ci utilisent de nombreux accès mémoire/disque, ceux-ci peuvent expulser les précieux blocs d'index mis en cache conduisant à MySQL frapper le disque plus souvent.
Un exercice intéressant (si vous avez le temps) est de bricoler votre système pour le ralentir. En exécutant une charge de travail standard sur de grandes tables, réduisez les tampons MySQL jusqu'à ce que l'impact devienne perceptible. Videz le cache de votre système de fichiers en pompant d'énormes quantités (supérieures à la RAM) de données non pertinentes via votre système de fichiers (cat large-file>/dev/null). Regardez iostat pendant l'exécution de vos requêtes.
"L'efficacité des clés" n'est PAS une mesure de la qualité de vos clés. Des touches bien conçues auront un impact beaucoup plus important sur les performances qu'une "efficacité des clés" élevée. Malheureusement, MySQL n'a pas grand-chose pour vous y aider.
Key_read_requests est le nombre de demandes de lecture d'un bloc de clé dans le cache. Tandis que key_reads est le nombre de lectures physiques d'un bloc clé à partir du disque. Ces 2 variables peuvent donc augmenter indépendamment. ( http://bugs.mysql.com/bug.php?id=28384 )
Ce qui est toujours aussi clair que de la boue.
Passons à l'explication suivante:
Une utilisation partiellement valide de Key_reads
Il existe une raison partiellement valable d'examiner Key_reads, en supposant que nous nous soucions du nombre de lectures physiques qui se produisent, car nous savons que les disques sont très lents par rapport aux autres parties de l'ordinateur. Et voici où je reviens à ce que j'ai appelé "principalement factuel" ci-dessus, car Key_reads n'est en fait pas du tout des lectures de disque physique. Si le bloc de données demandé n'est pas dans le cache du système d'exploitation, alors un Key_read est une lecture de disque - mais s'il est mis en cache, alors c'est juste un appel système. Cependant, faisons notre première hypothèse difficile à prouver:
Hypothèse difficile à prouver # 1: Un Key_read peut correspondre à une lecture de disque physique, peut-être. Si nous considérons cette hypothèse comme vraie, alors quelle autre raison pourrions-nous avoir à nous soucier de Key_reads? Cette hypothèse conduit à "un échec de cache est beaucoup plus lent qu'un hit de cache", ce qui est logique. S'il était tout aussi rapide de faire un Key_read qu'un Key_read_request, à quoi servirait le tampon de clé de toute façon? Faisons confiance aux créateurs de MyISAM sur celui-ci, car ils ont conçu un hit de cache pour être plus rapide qu'un miss. ( http://planet.mysql.com/entry/?id=23679 )