MySQL extremadamente lento en consultas SELECT muy simples

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)

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?

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);

2. 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.

3. 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