por - Cardinalidad del índice de MySQL-rendimiento vs eficiencia de almacenamiento

metodos de calculo de lamina de riego

Question

Supongamos que tiene una tabla MySQL 5.0 MyISAM con 100 millones de filas, con un índice (distinto de la clave principal) en dos columnas de enteros.

Desde mi conocimiento deficiente de la estructura del árbol B, creo que una cardinalidad más baja significa que la eficiencia de almacenamiento del índice es mejor, porque hay menos nodos principales. Mientras que una cardinalidad más alta significa un almacenamiento menos eficiente, pero un rendimiento de lectura más rápido, porque tiene que navegar a través de menos sucursales para llegar a los datos que está buscando para reducir las filas de la consulta.

(Nota: por "bajo" frente a "alto", no me refiero, por ejemplo, a 1 millón frente a 99 millones por una tabla de 100 millones de filas. Me refiero a más como 90 millones frente a 95 millones)

¿Mi entendimiento es correcto?

Pregunta relacionada: ¿Cómo afecta la cardinalidad al rendimiento de escritura ?

Answer 1

Mientras que una cardinalidad más alta significa un almacenamiento menos eficiente, pero un rendimiento de lectura más rápido, porque tiene que navegar a través de menos sucursales para llegar a los datos que está buscando para reducir las filas de la consulta.

Una cardinalidad más alta significa un mejor rendimiento de lectura porque, por definición, hay menos registros para leer.

Para procesar una consulta como esta:

SELECT  *
FROM    mytable
WHERE   indexed_col = @myvalue

, el motor debe hacer los siguientes pasos:

1. Encuentra la primera entrada que cumpla la condición.

   Esto se hace atravesando el B-Tree , comenzando desde la entrada raíz.

   En todas las páginas, la búsqueda se realiza siguiendo B-Tree enlaces de B-Tree ; dentro de una página, la búsqueda se realiza mediante la búsqueda binaria (a menos que sus claves estén comprimidas, en cuyo caso es una búsqueda lineal).

   Este algoritmo tiene la misma eficiencia para las columnas de cardinalidad alta y baja. Encontrar los primeros 3 (a diferencia de 3 ) en estas listas:

   1  2  3  4  5  6  7  8  9  10
   
   3  3  3  3  3  3  3  3  4  4

   requiere los mismos pasos O(log(n)) .

2. Atravesando el índice hasta que cambie el valor clave. Esto, por supuesto, requiere tiempo lineal: cuantos más registros tenga, más necesitará recorrer.

Si solo necesitas el primer registro:

SELECT  *
FROM    mytable
WHERE   indexed_col = @myvalue
LIMIT 1

, la cardinalidad de la columna no afecta el rendimiento de lectura.

¿Cómo afecta la cardinalidad al rendimiento de escritura?

Cada clave de índice tiene un valor adicional oculto: un puntero de registro. Este es el punto central de tener un índice: necesita saber a qué registro apunta.

Dado que un puntero de registro, por definición, es único, cada clave de índice también es única. Las entradas de índice que comparten el mismo valor de clave están ordenadas por el puntero de registro.

Esto es para hacer que el índice se pueda mantener: si elimina un registro con un valor de una columna indexada compartida por un millón de otros registros, el registro del índice correspondiente también debe eliminarse. Pero el millón completo de los registros del índice no se está revisando: en su lugar, el puntero del registro se utiliza como una condición de búsqueda adicional.

Cada clave de índice es de hecho única (incluso si no define el índice como único) y, por lo tanto, tiene la máxima cardinalidad posible.

Entonces, la respuesta a sus preguntas es: no, la cardinalidad de la columna no afecta el rendimiento de escritura del índice.