Estoy tratando de descubrir por qué mysqld a veces satura la CPU y los puestos.diagnosticar y evitar puntas de CPU MySQL
Sospecho que tiene algo que ver con actualizar los índices u otro tipo de mantenimiento. Me gustaría probar esta hipótesis y analizar las opciones para evitarla.
Aquí está la situación. Tengo docenas de tablas, pero de acuerdo con la actividad, parece que hay al menos dos que constantemente sufren de esto. Vamos a llamarlos Big y Small. Big contiene aproximadamente 6,000 filas que suman 1Mb (así que no es tan grande) y Small tiene docenas de filas, alrededor de 50 bytes cada una. Big tiene una clave externa a Small (InnoDB, en cascada de eliminación, no nulo).
Existen dos situaciones que parecen desencadenar el problema: a) una modificación de un valor Big.small_id, o b) la adición de una fila a Small.
Me intuitivamente esperaría a) a ser muy muy rápido, O(log(size of Big)) y b) para ser virtualmente instantánea porque Small es tan pequeño y ninguna de las referencias Big 's a que han cambiado.
En cada caso, el SELECT siguiente toma algo así como veinte gigaciclos (!); el uno después de eso no toma tiempo en absoluto. Hay otras tablas que tienen claves foráneas para ambas tablas, pero todas son bastante pequeñas y supongo que no son responsables de este aumento.
¿Cómo puedo saber qué índices está actualizando MySQL y cuánto tiempo tarda cada uno?
O, si no está actualizando los índices, ¿cómo puedo saber qué más está tardando tanto?
Finalmente, ¿puedo configurar mysqld para dar una prioridad de subproceso más bajo a este trabajo, y/o deshabilitar temporalmente el índice para permitir que las selecciones no indexadas (no bloqueantes) sucedan simultáneamente con la tarea de mantenimiento?
SHOW PROCESSLIST muestra que una consulta se encuentra en estado "Enviando datos" durante mucho tiempo. No es más descriptivo que eso. Dudo que sea una etiqueta justa porque estoy en localhost, transmisison no debería ser un cuello de botella. ¿A donde voy desde aqui? Gracias – spraff