¿Por qué esta simple consulta de MySQL es tan lenta?

Question

Así que aquí es una tabla muy simple 'TBL':

+---------+---------------------+------+-----+---------+----------------+ 
| Field | Type    | Null | Key | Default | Extra   | 
+---------+---------------------+------+-----+---------+----------------+ 
| val  | varchar(45)   | YES | MUL | NULL |    | 
| id  | bigint(20) unsigned | NO | PRI | NULL | auto_increment | 
+---------+---------------------+------+-----+---------+----------------+ 

e índices para ello:

+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | 
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 
| tbl |   0 | PRIMARY |   1 | id   | A   | 201826018 |  NULL | NULL |  | BTREE  |   | 
| tbl |   1 | val  |   1 | val   | A   |  881336 |  NULL | NULL | YES | BTREE  |   | 
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 

Estoy tratando este sencillo selecto:

select val from tbl where val = 'iii'; 

resultado: 86208 filas en el conjunto (0.08 seg)

Pero cuando quiero modificarlo ligeramente:

select id, val from tbl where val = 'iii'; 

el resultado es: 86208 filas en el conjunto (47.30 segundos)

que tienen un índice derecho en el que coumn donde los puntos a, todo lo que la modificación es la representación filas de resultados. ¿Por qué hay un retraso tan aterrador? (Debo decir que no puedo reproducir este retraso cada vez que quiero: incluso después de 'reiniciar la caché de consultas' o establecer el comando 'query_cache_type = off' se puede hacer rápidamente).

Answer 1

Sin examinar realmente la configuración de su servidor es difícil de decir, pero aquí hay una conjetura. En primer lugar, MySQL puede satisfacer su consulta sin leer realmente los datos de la tabla. Toda la información que ha solicitado se puede recuperar solo del índice. Observe que la cardinalidad del índice val es solo del orden de 10 filas, y las filas serán muy cortas en el índice.

En el segundo caso, ha solicitado datos NO en el índice en val. Ahora el motor tiene que encontrar y leer filas de los datos. Aquí la cardinalidad es aproximadamente 250 veces mayor, y dado que el índice recuperará las filas ordenadas por val, encontrar los valores id correspondientes requerirá MUCHO saltar en varios cientos de gigas de datos en el disco. Esto va a ser mucho más lento.

Answer 2

Intente agregar un ORDER BY y `LIMIT a la consulta. Eso debería ayudar mucho.

Creo que si se cambia la consulta a este que será más rápido:

select id, val from tbl where val = 'iii' order by val limit 10; 

Answer 3

Estás haciendo un selecto basado en dos columnas, pero no hay ningún índice de ambos. Intente agregar un nuevo índice que conste de ambos id y val.