¿Hay algún problema de rendimiento en el escaneo completo de la tabla MySQL?

Para encontrar una fila de datos en una tabla, ¿cuántos métodos de implementación tiene la base de datos?

Hay dos respuestas, exploración de tabla completa o búsqueda de índice .

El análisis de tabla completa consiste en obtener resultados de consulta mediante la lectura de los datos de toda la tabla. El mayor problema de este método es que, a medida que aumenta la cantidad de datos, el rendimiento del análisis de datos del disco disminuye considerablemente. Para MySQL, podemos usar el comando EXPLAIN para ver el plan de ejecución de la instrucción SQL, por ejemplo ( datos de muestra ):

EXPLAIN
SELECT *
FROM employee;

Name         |Value   |
-------------+--------+
id           |1       |
select_type  |SIMPLE  |
table        |employee|
partitions   |        |
type         |ALL     |
possible_keys|        |
key          |        |
key_len      |        |
ref          |        |
rows         |25      |
filtered     |100.0   |
Extra        |        |

A partir del resultado del plan de consulta anterior, se puede ver que el valor del campo de tipo es TODO, lo que significa exploración completa de la tabla.

La búsqueda de índice es para localizar rápidamente datos a través de índices (generalmente árboles B+, árboles B*). El siguiente ejemplo busca información de empleados por clave principal:

EXPLAIN
SELECT *
FROM employee
WHERE emp_id = 10;

Name         |Value   |
-------------+--------+
id           |1       |
select_type  |SIMPLE  |
table        |employee|
partitions   |        |
type         |const   |
possible_keys|PRIMARY |
key          |PRIMARY |
key_len      |4       |
ref          |const   |
rows         |1       |
filtered     |100.0   |
Extra        |        |

El valor del campo de tipo en la salida es const, lo que indica que los datos se buscan a través de la clave principal o el índice único, y se devuelve como máximo un registro. Este es un método de acceso muy rápido, por lo que es equivalente a una constante (constante).

Los escaneos de rango de índice también se pueden usar al buscar datos a través de un índice. Por ejemplo:

EXPLAIN
SELECT *
FROM employee
WHERE emp_id BETWEEN 10 AND 12;

Name         |Value      |
-------------+-----------+
id           |1          |
select_type  |SIMPLE     |
table        |employee   |
partitions   |           |
type         |range      |
possible_keys|PRIMARY    |
key          |PRIMARY    |
key_len      |4          |
ref          |           |
rows         |3          |
filtered     |100.0      |
Extra        |Using where|

El valor del campo de tipo en la salida es rango, lo que indica que los datos se obtienen a través de la exploración de rango del índice de clave principal.

En términos generales, encontrar datos a través de la indexación es más eficiente que escanear una tabla completa. Para obtener un análisis específico, consulte este artículo . Sin embargo, todavía hay algunos casos en los que una exploración completa de la tabla es una mejor opción, entre ellos:

  • La cantidad de datos en la tabla es tan pequeña que una exploración completa de la tabla es más rápida que una búsqueda de índice. Especialmente el escaneo de rango basado en el índice auxiliar, porque después de escanear el índice, debe volver a la tabla para consultar los datos, que son E/S aleatorias. Por ejemplo, una tabla de configuración con menos de 10 entradas de datos puede obtener datos rápidamente a través del escaneo completo de la tabla.
  • No hay una condición de filtro basada en el campo de índice en la instrucción de consulta, o la condición de consulta basada en el índice debe devolver una gran parte de los datos de la tabla, lo que da como resultado un análisis completo de la tabla más rápido. Un escenario de aplicación es el análisis de agregación en almacenes de datos, que generalmente necesita resumir los datos en la tabla completa.
  • La cardinalidad (valores distintos) del índice es demasiado pequeña, como un índice separado para el campo de género. En este caso, MySQL pensará que el índice necesita encontrar muchos registros y que el rendimiento no es tan bueno como el de una exploración completa de la tabla.

Un escaneo completo de la tabla en el plan de ejecución no significa necesariamente que haya un problema de rendimiento en la consulta, pero también puede ser la elección correcta después del análisis por parte del optimizador de MySQL. Si confirmamos que el escaneo completo de la tabla no es el método óptimo, se pueden usar algunos medios técnicos para ayudar al optimizador a elegir otros métodos de implementación, como usar el comando ANALYZE TABLE para actualizar las estadísticas, usar la sugerencia de índice FORCE INDEX para forzar el uso de un índice o usar la variable de sistema max_seeks_for_key para controlar la cantidad máxima de registros que busca el escaneo del índice.

Supongo que te gusta

Origin blog.csdn.net/horses/article/details/131228811
Recomendado
Clasificación