Baja Tasa de aciertos de la caché de tabla MySQL

Question

He estado trabajando en la optimización de mi sitio y bases de datos, y he estado usando mysqltuner.pl para ayudar con esto. He obtenido casi todo lo correcto, a excepción de la tasa de aciertos de la memoria caché de tablas, no importa qué tan alto la eleve en mi.cnf, todavía estoy alcanzando el 0% (284 abiertos/79k abiertos).

Mi problema es que realmente no entiendo exactamente lo que afecta esto, así que realmente no sé qué buscar en mi estructura de las consultas/bases de datos para solucionarlo.

Answer 1

Se supone que una memoria caché debe mantener copias de datos calientes. Los datos calientes son datos que se usan mucho. Si no puede recuperar datos de una determinada memoria caché, significa que la base de datos debe ir al disco para recuperarla.

--edit--

lo siento si la definición parecía un poco desagradable. un caché específico a menudo cubre una gran cantidad de entidades, y estas son específicas de la base de datos, primero debe averiguar qué está almacenado en la memoria caché de la tabla.

--edit: un poco de investigación -

Ok, it seems (a partir de la respuesta a esta entrada), que MySQL utiliza el caché de la tabla de las estructuras de datos utilizadas para representar una tabla. las estructuras de datos también (a través de la encapsulación o al tener entradas de tabla duplicadas para cada tabla) representan un conjunto de descriptores de archivos abiertos para los archivos de datos en el sistema de archivos. El motor de MyIsam usa uno para una tabla y uno para cada índice, adicionalmente cada elemento de consulta activo requiere sus propios descriptores.

Un descriptor de archivo es una entidad de kernel utilizada para el archivo IO, representa el contexto de bajo nivel de un archivo en particular de lectura o escritura.

Creo que está interpretando el valor incorrectamente o que deben interpretarse de manera diferente en este contexto. 284 es la cantidad de tablas activas en la instancia que tomó la instantánea y el segundo valor representa la cantidad de veces que se adquirió una tabla desde que inició Mysql.

Me atrevo a adivinar que necesita tomar múltiples instantáneas de esta lectura y ver si el primer valor (fd activo en esa instancia) excede alguna vez la capacidad de su tamaño de caché.

p.s., el núcleo generalmente tiene un límite superior en la cantidad de descriptores de archivos que permitirá que se abra cada proceso, por lo que es posible que deba ajustarlo si es demasiado bajo.

Answer 2

El table cache define la cantidad de descriptores de archivos simultáneos que MySQL ha abierto. Por lo tanto, la tasa de aciertos de caché de tabla se verá afectada por la cantidad de tablas que tenga en relación con su límite y la frecuencia con la que vuelve a referenciar las tablas (teniendo en cuenta que no cuenta solo una conexión, sino conexiones simultáneas)

Por ejemplo, si su límite es 100 y tiene 101 tablas y consulta cada una en orden, nunca obtendrá ningún golpe de caché de tabla. Por otro lado, si solo tiene 1 tabla, generalmente debería obtener una tasa de aciertos cercana al 100%, a menos que ejecute FLUSH TABLES mucho (siempre que su table_cache esté configurado más alto que el número de conexiones típicas simultáneas).

Por lo tanto, para sintonizar, necesita ver cuántas tablas distintas puede referenciar por un proceso/cliente y luego ver cuántas conexiones simultáneas puede tener normalmente.

Sin más detalles, no puedo adivinar si su caso se debe a demasiadas conexiones simultáneas o demasiadas tablas a las que se hace referencia con frecuencia.