Índice mysql principio subyacente

Paso a paso, la estructura de datos subyacente se deriva índice MySQL.

MySQL como base de datos de Internet es muy popular, diseñar el motor de almacenamiento y recuperación de datos del motor que subyace es muy importante, sobre todo formato de almacenamiento de datos MySQL y el diseño de índice, determinar el rendimiento de la recuperación de datos de MySQL en general.

Sabemos que el papel del índice es hacer la recuperación de datos rápida, y darse cuenta de la naturaleza de la rápida recuperación de la estructura de datos. Mediante la selección de diferentes estructuras de datos, una variedad de datos para lograr una rápida recuperación. En la base de datos, eficiente algoritmo de búsqueda es muy importante porque una gran cantidad de datos almacenados en la base de datos, un índice eficiente puede ahorrar gran cantidad de tiempo. Por ejemplo, la siguiente hoja de datos, si no se logra algoritmo de indexación de MySQL, y luego busque id = 7 estos datos, sólo puede tomar violenta búsqueda de recorrido orden, encontrar id = 7 necesidad de comparar los datos de siete veces, si la tabla se almacena en un 1000W de datos Encuentra id = 1000W estos datos se compararía 1000W veces, esta tasa es inaceptable.

A, índice Mysql subyacente estructura de datos de selección

1. tabla hash (hash)

tabla hash es hacer una herramienta eficaz para la rápida recuperación de datos.

algoritmo de Hash: También llamado algoritmo de hash es valor arbitrario (clave) se convierte en clave dirección de longitud fija a través de una función hash, una de datos específica estructura de datos por esta dirección.

Considere este usuario de base de datos de mesa, un total de siete tablas de datos, que necesitamos para recuperar los datos de identificación = 7, la sintaxis SQL es:

select \* from user where id=7;

Algoritmo de hash calcula en primer lugar la memoria física dirección addr 7 id = data = almohadilla (7) = 4231, y 4231 es asignación de dirección física id = 0x77,0x77. 7 es una dirección física de los datos almacenados en la cantidad, por el cual la dirección independiente encontrar el nombre_usuario correspondiente = 'g' de estos datos. Este es el algoritmo de hash para recuperar rápidamente los datos en el proceso de cálculo.

Pero hay problemas de datos de colisión algoritmo de hash, que se calcula con una función hash puede ser el resultado de valorar las claves diferentes, tales como almohadilla (7) puede ser tan calculados con el (199) resultado de control, que es un diferentes mapas de teclado al mismo resultado, esta es la colisión. Un enfoque común es resolver el problema de las colisiones método de dirección de la cadena, que utiliza una colisión lista de datos vinculados tras otro hacia arriba. Después de calcular el valor hash, también es necesario comprobar si hay una colisión del valor hash de la lista de datos, se han atravesado hasta el final de la lista, encontrar acceso directo a la verdadera clave hasta que los datos correspondientes.

A partir de la complejidad de tiempo del análisis, el tiempo de algoritmo de hash complejidad es O (1), muy rápido de recuperación. Id = 7 como la búsqueda de los datos, índice hash se calcula sólo una vez para obtener los datos correspondiente se recupera muy rápido. Mysql pero no tomó como su algoritmo de hash subyacente, que es la razón?

Teniendo en cuenta que hay un medio común de recuperación de datos es encontrar el intervalo, por ejemplo, la siguiente instrucción SQL:

select \* from user where id \>3;

Para la declaración anterior, que queremos hacer es averiguar id> 3 de datos, que está típicamente en el rango de aspecto. Si utiliza un algoritmo de hash índice, que van hallazgo cómo hacerlo? Una idea simple es averiguar una vez que todos los datos se cargan en la memoria, y luego filtrar los datos de detección dentro del rango meta en la memoria. Sin embargo, este método es demasiado engorroso para encontrar el rango, no tiene sentido en términos de eficiencia.

Así, utilizando un algoritmo de hash aunque el índice se puede hacer rápidamente recuperar los datos, pero no pudo encontrar el rango de eficiencia de los datos, y por lo tanto no es adecuado índice hash como la estructura de datos Mysql índice subyacente.

1. Árbol binario de búsqueda (BST)

El árbol es una búsqueda binaria para encontrar rápidamente la estructura de datos de soporte de datos, como se muestra en la figura:

La búsqueda binaria tiempo árbol complejidad es O (LGN), como por encima de este árbol binario, tenemos que calcular los comparativos tres veces que se puede recuperar de identificación de datos = 7, en lugar de atravesar directamente la consulta Guardar la mitad del tiempo, desde la búsqueda la eficiencia parece ser capaz de hacer la recuperación de alta velocidad. Por otra estructura de árbol binario no puede resolver la función de búsqueda de artículos gama de hash no puede proporcionarla?

La respuesta es sí. La figura observó anteriormente, los nodos de hoja del árbol binario están dispuestas secuencialmente, en orden ascendente de izquierda a derecha, si tenemos que encontrar ID> 5 de datos, entonces eliminar el nodo y un nodo 6 que puede ser un subárbol derecho , encontrar el rango puede considerarse relativamente fácil de implementar.

Pero árbol binario de búsqueda ordinaria tiene un defecto fatal: casos extremos, degenerar en lista lineal, búsqueda binaria degenerará que atravesar para encontrar el tiempo complejidad reducida a O (N), una fuerte disminución de rendimiento de la recuperación. Por ejemplo, el siguiente este caso, el árbol binario ha sido extremadamente desequilibrada, ha degenerado en una lista enlazada, la velocidad de recuperación se reduce considerablemente. En este momento, el número de cálculos necesarios para recuperar la identificación de datos = 7 ha cambiado a un 7.

En la base de datos, los datos de la subasta es una forma muy común, tales como la clave principal de una tabla es la identificación y la clave principal suele ser el valor predeterminado incrementado automáticamente, si se toma una estructura de datos de árbol binario como un índice, que la descripción anterior al desequilibrio problemas causados ​​por el estado de búsqueda lineal de la inevitable. De este modo, un simple árbol de búsqueda binaria de recuperación problema del desequilibrio de la degradación del rendimiento, no se puede utilizar directamente para lograr Mysql índice subyacente.

1. árboles AVL y árbol rojo-negro

Existe un desequilibrio árbol binario de búsqueda, por lo que los estudiosos de auto-rotación y ajustar los nodos del árbol, por lo que siempre mantener el estado del árbol binario equilibrado básica, que será capaz de mantener el árbol de búsqueda binaria óptima para encontrar el rendimiento. Hay árboles AVL y árbol rojo-negro basado en esta idea de árbol binario equilibrio autoajustable.

En primer lugar, una breve rojo-negro árbol, que árbol es un árbol se ajustará automáticamente la morfología, como cuando un árbol binario en un estado de desequilibrio, de forma automática rojo-negro nodo de árbol y la forma de árbol de ajuste de color de nodo de uso de las manos, de modo que para mantener su equilibrio básico (tiempo de complejidad es O (log n)), se asegurará de que la eficiencia de la búsqueda no se reduce significativamente. Tales como la inserción de datos desde el nodo de 1-7 en orden ascendente, si un árbol binario de búsqueda ordinaria degenerará en una lista enlazada, pero continuará para ajustar árboles negros forman un árbol, queda estado sustancialmente de equilibrio, como se muestra en la figura. El siguiente árbol rojo-negro para encontrar el id = 7 para comparar el número de nodos 4, el mantenimiento de una buena eficiencia de búsqueda binaria árbol.

árbol rojo-negro tiene un promedio de buena eficiencia de búsqueda, no hubo caso extremo de O (n), que árbol rojo-negro como MySQL si el índice subyacente puede lograrlo? De hecho, rojo-negro árbol hay algunos problemas, observar el siguiente ejemplo.

secuencia de inserción de árbol Red-negro 1-7 nodos, los nodos necesitan encontrar id = 7 se calcula 4.

1 insertado en el orden rojo-negro árbol de 16 nodos, búsqueda de ID de = 16 nodos para ser comparados por seis veces. Vistazo a la forma del árbol, no lo es cuando se han insertado los datos en el orden, la forma del árbol ha sido en la tendencia de "derecha" en ella? Desde el punto de vista fundamental, el árbol rojo-negro no resuelve completamente el árbol de búsqueda binaria, aunque esta tendencia "derecho" está lejos de ser un binario degenerados árbol de búsqueda en lista lineal de manera exagerada, pero básicamente la clave principal en el operador de incremento de base de datos, por lo general la clave primaria millones de decenas de millones de árbol rojo-negro si hay un problema tal, aspecto para el rendimiento es un consumo enorme, nuestra base de datos no pueden tolerar esta espera sin sentido.

Consideremos ahora otro árbol binario de auto-equilibrio árbol AVL más estrictas. Debido a que el árbol AVL es un árbol binario equilibrado absoluta, por lo que se consume en la forma de un árbol binario de ajuste será más rendimiento.

árboles AVL 1-7 secuencia nodo insertado, el número de operaciones de búsqueda id = 7 al nodo de comparación es de tres.

secuencia de inserción de árbol AVL 1 a 16 nodos, de búsqueda de id = 16 nodos que deben compararse a 4. En términos de eficiencia de búsqueda, árbol AVL velocidad de las operaciones de búsqueda buscar la eficiencia de árbol rojo-negro (árbol AVL es cuatro veces en comparación con el árbol rojo-negro es de 6 comparaciones). A partir de la forma de la vista de árbol, árbol AVL, árbol rojo-negro no existe problema de "derecha". En otras palabras, un gran número se inserta en el orden no conduce a una disminución en el rendimiento de las consultas. Esto resuelve el problema de árbol rojo-negro fundamentalmente.

Resume el árbol AVL ventajas:

1. Encontrar un buen rendimiento (O (log n)), casos extremos ineficiente buscando no existe.
2. Encuentre un rango se puede lograr, clasificación de datos.

Parece AVL estructura de datos de árbol ya que los datos se ven realmente bien, pero no es adecuado para la estructura de datos de árbol AVL índice de base de datos MySQL debido a examinar esta cuestión:

cuello de botella de datos de consulta de base de datos que S de disco, si está utilizando el árbol AVL, cada uno de los árboles de nodos almacena sólo uno de datos, en primer lugar S de disco sólo puede sacar una carga de datos en el nodo a la memoria, y que tales consultas id = 7 los datos que tenemos para el disco IO tres veces, esta es la forma de consumir vez sí. Así que tenemos que diseñar los índices de bases de datos en primer lugar considerar la forma de reducir el número de disco IO como sea posible.

Hay un disco IO tiene una función que lee los datos de datos y tiempo de 1 KB 1B consumida es básicamente el mismo desde el disco, podemos de acuerdo con esta idea, podemos almacenar más datos en un nodo de árbol, un disco IO en los datos de múltiples puntos cargados en la memoria, este es el principio de diseño de árbol B, B + árbol del.

1. B-tree

La siguiente B-árbol, cada nodo de las más restrictivas dos de almacenamiento de claves, un nodo si más de dos clave dividirá automáticamente. Por ejemplo, los siguientes datos almacenados en los siete árbol B, sólo tienen que comprobar dos nodos puede conocer la ubicación específica ID = 7 Estos datos, que es dos veces el disco IO puede realizar consultas para especificar mejor que el árbol AVL los datos.

El siguiente es un árbol B almacenes de datos 16, también almacenar hasta 2 por nodo clave, la consulta de id = 16 necesidad de consultar los datos que comparan cuatro nodos, es decir, después de las cuatro S de disco. AVL rendimiento de las consultas árbol y tiene el mismo aspecto.

Pero teniendo en cuenta el disco IO leer los datos y la lectura de datos de 100 consume tiempo son básicamente los mismos, que nuestras ideas de optimización se pueden leer: tanto como sea posible en un disco IO leer más datos en la memoria. Esto se refleja directamente en la estructura del árbol es que cada nodo puede almacenar la clave se puede aumentar.

Cuando el número de tecla de un solo límite de nodo que se establece después de 6, una memoria 7 de los datos B de árboles, consulta id = disco IO 7 Estos datos se va a realizar dos veces.

Un 16 almacena los datos de árbol B, consulta ID = S de disco 7 de estos datos para llevar a cabo dos veces. Árbol AVL en términos relativos a la cantidad de S de disco se reduce a la mitad.

Así estructura de datos de índice de base de datos de selección en términos de, árbol B es una muy buena elección. En resumen, árbol B como una base de datos de índice tiene las siguientes ventajas:

1. Excelente velocidad de recuperación, la complejidad de tiempo: El rendimiento de las operaciones de búsqueda de árbol-B es igual a O (h * logn), en el que la altura h del árbol, cada nodo es el número de n-palabra clave;
2. IO de disco mínima, la recuperación de la velocidad;
3. Puede soportar un rango de búsqueda.
4. B + Árbol

Árbol B y B + árbol tiene qué más da?

En primer lugar, un nodo de árbol B de los datos almacenados, y el B + árbol almacenada en un índice (dirección), el B-árbol en un nodo no puede ahorrar una gran cantidad de datos, pero el nodo de árbol B + puede almacenar una gran cantidad de índice, el nodo + hojas B almacenar todos los datos.

En segundo lugar, el nodo B + hoja de árbol es una fase de datos de lista enlazada se usan juntos, fácil de encontrar la gama.

Al comparar el árbol B y los árboles B + que vemos, B + nodo del árbol almacenar el índice de capacidad de almacenamiento de un solo nodo limitado es, un único nodo puede almacenar un gran número de índice, de manera que toda la altura B + árbol se reduce, reduciendo el disco IO. En segundo lugar, el nodo de hoja B + árbol es donde el almacenamiento de datos real, los nodos de hoja están conectados con una lista enlazada, la propia lista se ordena, cuando se mira en la gama de datos, sino también con la eficiencia. Así índice de MySQL usada es B + árbol, árbol B + en la eficiencia de búsqueda, rango de operaciones de búsqueda tienen un muy buen rendimiento.

Dos, motores y motores InnoDB lograr myisam

Mysql subyacente motor de datos como un diseño de enchufe, el más común es el motor InnoDB y el motor MyISAM, los usuarios pueden elegir diferentes motores como la hoja de datos de MySQL motor subyacente de acuerdo a las necesidades individuales. Que acabamos de analizar, B + árbol como la estructura de datos del índice de MySQL es muy apropiado, pero los datos e índices en la final de cómo se organizan también necesita un poco de diseño, diferente filosofía de diseño también ha dado lugar a la aparición de Innodb y myisam de cada exhiben propiedades únicas.

MyISAM Aunque los datos se ven muy buen rendimiento, pero no se admite la transacción. Innodb mayor característica es compatible con las funciones de transacciones ACID-compatibles, pero que apoya el bloqueo de filas. Mysql creación de tablas cuando se puede especificar el motor, como por ejemplo el siguiente ejemplo, especificar que la mesa y usuario2 MyISAM e InnoDB como motor de datos de tabla de usuario.

Después de la ejecución de estas dos instrucciones, el sistema apareció el siguiente documento que describe la organización de los dos datos del motor y los índices no son lo mismo.

Después de crear una tabla InnoDB archivos generados son:

• frm: create table
• BID: los datos dentro del archivo de índice + mesa

Después de crear una tabla MyISAM generada archivos tienen

• frm: create table
• MYD: mesa dentro del archivo de datos (datos MyISAM)
• MYI: mesa dentro del archivo de índice (índice myisam)

En la vista de archivo resultante, la organización de los dos motores de los datos e índices subyacentes no son los mismos, los datos del motor MyISAM e índice separados, uno un archivo, que se denomina modo de índice no agrupado; datos INNODB e índices en el mismo archivo, que se llama el modo de índice agrupado. análisis de ángulo de estas dos motores es cómo se basan en la estructura de datos de árbol B + para organizar este motor para lograr la implementación subyacente desde abajo.

1. motor MyISAM implementación subyacente (modo de índice no agrupado)

Una realización no agrupado índice MyISAM, es decir, los datos y el índice cae en dos archivos diferentes. Cuando tabla MyISAM para construir la llave clave principal para establecer + árbol del índice B primario, los nodos hoja del árbol es la dirección física correspondiente a los datos almacenados. Después de recibir la dirección física, puede localizar el archivo de datos MyISAM directamente a los registros de datos específicos.

Cuando añadimos un índice para un campo, también vamos a generar un nodo hoja del árbol del índice correspondiente campo del árbol índice del campo también registra la dirección física correspondiente a los datos, y luego también tomó la dirección física para localizar el archivo de datos a los registros de datos específicos.

1. El INNODB implementación subyacente (modo de índice agrupado)

InnoDB es un modo de índice agrupado, por lo que los datos e índices se almacenan en el mismo archivo. Primero InnoDB crea ID clave primaria como índice de la clave B + árbol que se muestra en la figura de la izquierda más adelante, los nodos de hoja almacenados en B árboles + que son clave correspondiente a los datos de identificación, tales como cuando se realiza seleccionar * de user_info donde id = 15 Esta declaración, InnoDB ID se consulta zheke índice de clave primaria árbol B +, para encontrar el correspondiente nombre_usuario = 'Bob'.

Fue construido cuando tabla InnoDB generará automáticamente una buena clave de identificación árbol del índice principal, por lo que se deben especificar los requisitos Mysql clave primaria cuando la construcción de la tabla. Cuando añadimos un campo de la tabla será cómo los árboles de índices índice de InnoDB? Por ejemplo, damos nombre_usuario este campo está indexado, entonces InnoDB creará un índice nombre_usuario B + árbol, nodo nombre_usuario se almacena en la clave, los datos almacenados en el nodo hoja es la clave de clave primaria. Tenga en cuenta que las hojas se almacenan en CLAVE clave primaria! Obtener la clave de clave principal, InnoDB irá al árbol de índice de clave principal solo árbol de índice de clave principal encontrados en Key nombre_usuario encontrar los datos correspondientes.

La pregunta es, ¿Por qué InnoDB sólo en el nodo hoja del árbol de índice de clave principal se almacenan los datos específicos, pero otro árbol índice no guarda datos específicos aún, pero quiere preocuparse de encontrar la clave principal, y luego encontrar los datos correspondientes en los árboles índice de clave principal?

De hecho, muy simple, debido a que InnoDB necesita ahorrar espacio de almacenamiento. Una tabla puede tener muchas índice, InnoDB se añadirá a cada campo de índice de árbol índice generado, si el índice de árbol para cada campo se almacenan datos específicos, esta tabla de índice se vuelve muy grandes archivos de datos (datos la redundancia extrema). Desde el punto de vista de ahorro de espacio en disco, lo que realmente no es necesario que cada campo de árboles de índice se almacenan datos específicos, este paso parece ser "superflua", el ahorro de espacio en disco enorme a expensas de menor rendimiento de las consultas, el cual es muy valioso.

Cuando se trata de la realización de las características comparativas de InnoDB y MyISAM, MyISAM mejor consulta de rendimiento, desde el diseño de los archivos de datos de archivos de índice anteriores también puede mirar para ver por qué: MyISAM directamente a la dirección física puede ser ubicado directamente después del registro de datos, pero consulta InnoDB al nodo hoja, todavía tienen que consultar un árbol de índice de clave principal, que puede ser dirigido a datos específicos. MyISAM encontró igual al paso de los datos, sino a la de dos pasos InnoDB, MyISAM curso alto rendimiento de las consultas.

Este documento analiza la estructura de datos que es más adecuado para alcanzar el índice subyacente como MySQL, y luego presentó los dos datos de MySQL clásicos MyISAM e implementación motor InnoDB subyacentes. Finalmente, para resumir lo que su mesa cuando es necesario agregar un índice de campo es:

1. Más frecuentes a medida que el campo del índice de condiciones de consulta debe ser creado;
2. campo de singularidad no es tan malo para la creación de un índice solo, a pesar de que el campo con frecuencia como una consulta;
3. campos muy actualizados, no son adecuados para la creación de un índice.