MySQL extremadamente lento en consultas SELECT muy simples

10

Tenemos una aplicación web simple que se ejecuta en una máquina virtual que guarda sus datos en una base de datos MySQL 5.5 con el motor InnoDB. Todo funcionó bien durante unos tres años, pero de repente se volvió extremadamente lento.

Por ejemplo, tengo una tabla muy simple que contiene direcciones:

CREATE TABLE `addresses` (
  `address_id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) CHARACTER SET latin1 NOT NULL,
  `firstname` varchar(64) CHARACTER SET latin1 NOT NULL,
  `street` varchar(64) CHARACTER SET latin1 NOT NULL,
  `housenumber` varchar(16) CHARACTER SET latin1 NOT NULL,
  `zip` varchar(5) CHARACTER SET latin1 NOT NULL,
  `city` varchar(64) CHARACTER SET latin1 NOT NULL,
  `email` varchar(64) CHARACTER SET latin1 NOT NULL,
  `phone` varchar(16) CHARACTER SET latin1 NOT NULL,
  `birthdate` date NOT NULL,
  PRIMARY KEY (`address_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Esta tabla contiene alrededor de 800 entradas, lo que realmente no es mucho. Pero ejecutando la consulta

SELECT * FROM addresses

para fines de prueba, parece que nunca termina. Verifiqué esto con la CLI de mysql en el propio servidor: genera algunas filas de la tabla y luego espera mucho tiempo hasta que genera las siguientes filas.

Entonces, tal vez sea un problema en la fase de envío de datos, pero no estoy seguro.

La VM tiene 2 GB de RAM y solo se utilizan 320 MB. La CPU también funciona a muy bajo 1 a 2%. mytop no muestra ninguna otra consulta que esté bloqueando el servidor. El administrador de TI dijo que no cambiaron nada en el lado del hardware.

Ya probé algo como reiniciar el servidor de la base de datos, reiniciar la máquina virtual. Nada ayudó

editar:

EXPLAIN SELECT * FROM addresses

me da este resultado:

+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
| id | select_type | table     | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | addresses | ALL  | NULL          | NULL | NULL    | NULL |  793 |       |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
1 row in set (0.00 sec)
pestaña
fuente
Virtual Box, Xen o algo más? ¿Cómo se configura el disco host? ¿hay otras máquinas virtuales en la misma caja que también funcionan lentamente? Responder esas preguntas podría revelar la respuesta
Matt
No soy el propietario del hipervisor, por lo que realmente no puedo responder esto. Ya le pregunté al administrador del hipervisor si conocen algún cambio reciente, pero él dijo que no.
pestaña
si puede, cierre mysql y ejecute un disco y un punto de referencia de memoria. No tiene que ser complicado. La idea es simplemente aislar si es un problema con mysql, quizás un problema de índice como se indica en la respuesta a continuación, o más generalizado.
Matt
Buen punto, experimenté que probablemente no sea un problema mysql. La ejecución mysql -u username -ppassword mydb -e 'SELECT * FROM addresseses lenta, pero agregando `> test.txt`, se ejecuta muy rápido. ¡¿Ahora esta probablemente sería una pregunta diferente ?! ¿Cómo podría investigar sobre esto?
pestaña
Póngase en contacto con el propietario del hipervisor y pídale que verifique los registros en busca de errores. Específicamente errores de disco. Cuéntale tus síntomas. Copia ahora.
Matt

Respuestas:

13

Si la carga de la CPU es baja, esto indica que no hay problemas con los índices faltantes, si ese fuera el caso, la consulta solo necesitaría tomar más CPU y acceso al disco. También dijiste que funcionó bien durante 3 años.

¿Verificó la velocidad general de acceso al disco (específicamente en la partición donde se encuentra la base de datos)? Por ejemplo, usando dd como aquí . Lo que estás describiendo suena como un disco muerto o una incursión medio muerta. ¿Tengo copias de seguridad, espero?

usuario3648611
fuente
Ese es un buen punto. Podría ser algo tan simple como un error de disco en el host.
Matt
9

Puedes probar un par de cosas,

  1. ¿Tienes índices configurados?

La indexación hace que sea posible encontrar registros rápidamente sin hacer primero un escaneo completo de la tabla, reduce drásticamente los tiempos de ejecución.

CREATE INDEX idx_name ON addresses(name);
  1. Antes de ejecutar la consulta, use primero la palabra clave EXPLAIN,

Cuando se usa frente a una consulta SELECT, describirá cómo MySQL intenta ejecutar la consulta y el número de filas que necesitará procesar antes de que finalice.

  1. Realice algunos cambios en su mysql.ini, si es una VM, aumente la RAM y configure su mysql.ini para ver si aumenta el rendimiento.

Existen muchos optimizadores MySQL que pueden guiarte.

Ayuda esto ayuda

Anthony Fornito
fuente
De acuerdo, pero crear un índice en una tabla bastante pequeña (<800 filas) parece no ser tan útil como lo necesitaría. Tarda más de un minuto en finalizar la consulta citada anteriormente. Un escaneo completo de una mesa tan pequeña no debería llevar tanto tiempo.
pestaña
Entonces ... ¿agregaste los índices? Si no está seguro de cuál es el problema, comenzaría de manera básica y bajaría. Agregar índices solo aumentará el rendimiento si se realiza correctamente.
Anthony Fornito
Sí, agregué un índice en la columna de nombre. Pero mi consulta anterior ni siquiera tiene ninguna cláusula WHERE restrictiva, por lo que tendrá que leer toda la tabla e imprimirla. Agregó que el índice no ayudó.
pestaña
Agregué el resultado de la consulta EXPLAIN anterior. Esto me parece bien, pero el rendimiento sigue siendo muy bajo. No puedo aumentar la RAM ya que no soy el administrador del administrador de virtualización. Pero htopmuestra que solo se usan 307 MB de 2050 MB de RAM.
pestaña
Acerca de los índices, realmente necesita pensar qué columnas indexar, no desea indexar todo, indexar las que tienen la mayor cantidad, estoy haciendo algunas suposiciones sobre esto, pero comenzaría con name'nombre'. Segundo, ¿estás seguro de que hiciste la indexación correctamente? possible_keys: NULL si la columna es NULL, indica que no se pudieron encontrar índices relevantes.
Anthony Fornito