La estructura de datos del índice Mysql
Tabla de contenido
1.2.1. MyISAM (porque los datos y el índice no están juntos, por lo que es un índice no agrupado)
1.2.2. InnoDB (debido a que el índice y los datos están juntos, también se denomina índice agrupado)
1. Índice
Un índice es una estructura de datos ordenada que ayuda a MySQL a obtener datos de manera eficiente.
1.1. Estructura de los datos
1.1.1. Árbol binario
El árbol binario es un tipo importante de estructura de árbol. La estructura de datos extraída de muchos problemas prácticos a menudo tiene la forma de un árbol binario, incluso un árbol general se puede convertir fácilmente en un árbol binario, y la estructura de almacenamiento y el algoritmo del árbol binario son relativamente simples, por lo que el árbol binario es particularmente importante. La característica del árbol binario es que cada nodo solo puede tener dos subárboles como máximo, y hay subárboles izquierdo y derecho.
Primero analice de acuerdo con los problemas reales:
Cuando no utilicé la consulta de declaración de índice SQL es la siguiente:
select * from table where Col2 = 23Una simple consulta SQL requiere 7 operaciones de E / S de disco (una a una consulta descendente), lo que sin duda es consumo, por lo que se introduce un árbol binario para solucionar este problema.
Cuando utilizo un árbol binario para el almacenamiento de datos, este Col2 se clasificará en este tipo. Cuando consultamos 23, esta vez solo se necesitan 4 IO de disco para encontrar los datos correspondientes.
Esto no es más que resolver el problema de la consulta directa de tabla completa que encontramos, pero el uso de árboles binarios puede ir acompañado de nuevos problemas.
1.二叉树的定义是每个节点只有两个字数，那么每一层的存储是有限的（当面对MySQL大的数据量的情况下，子叶数据过多，层级过多也会导致大量的IO产生）
2.在特殊情况下，二叉树是存在问题的（如下图所示） 
Cuando se utiliza una secuencia ordenada de incremento automático, el árbol binario tendrá la siguiente estructura.
Supongamos que uso Col1 como índice, el árbol binario tendrá el problema como se muestra en la figura anterior, por lo que el significado de usar el árbol binario no es muy bueno.
1.1.2. Árbol rojo-negro
Red Black Tree es un árbol de búsqueda binario autoequilibrado, una estructura de datos utilizada en ciencias de la computación, y su uso típico es implementar matrices asociativas.
El árbol rojo-negro es un árbol AVL especializado (árbol binario balanceado), que mantiene el equilibrio del árbol de búsqueda binaria a través de operaciones específicas durante la inserción y eliminación, para obtener un mayor rendimiento de búsqueda.
红黑树和平衡二叉树的区别，红黑树在结构的变化上还算是比较稳定的。
所以就会导致平衡二叉树相对于红黑树保持更加严格的平衡,所以平衡二叉树的查询是比较快的（但是以多旋的方式保持平衡增加可新增、修改、删除的开销）
这也就是HashMap的树使用的是红黑树而不使用平衡二叉树的原因。Primero, usamos el árbol rojo-negro para ver el índice de Col2.
Verifique nuevamente la clasificación de índice de Col1
El árbol rojo-negro resuelve el problema del incremento automático del número de serie en el árbol binario, y se lleva a cabo el método de optimización de giro, pero aún no resuelve el problema cuando la cantidad de datos es demasiado grande (el problema de más nodos de hoja, más capas y más IO).
1.1.3.Hash tree
Un árbol hash (o hash trie) es una estructura de datos persistente que se puede utilizar para implementar colecciones y asignaciones y está destinada a reemplazar las tablas hash en la programación funcional pura. En su forma básica, un árbol hash almacena el valor hash de su clave (considerada una cadena de bits) en el trie, donde la clave real y el valor (opcional) se almacenan en el nodo "final" del trie.
En primer lugar, la configuración del árbol Hash puede cumplir con los requisitos del objetivo y ubicar rápidamente la ubicación especificada de acuerdo con el valor Hash.
En la elección del método de indexación, se permite la elección de Hash, pero incluso si la consulta es rápida, rara vez se utiliza en la situación de indexación real.
En primer lugar, resuelve el problema de la consulta lenta, pero si encuentra un rango de valores, Hash no puede hacer nada. Solo los escaneos completos de la tabla se pueden comparar uno por uno. Esto no es lo que queremos ver.
1.1.4.BÁrbol
Antes de explicar la definición de BTree, primero podemos mirar el diagrama esquemático de Btree, que es el siguiente:
Características de BTree
叶节点具有相同的深度，叶节点的指针为空
所有索引元素不重复
节点中的数据索引从左到右递增排列El valor predeterminado en Mysql es que el tamaño de cada bloque de cotiledón es 16K
Btree puede resolver perfectamente nuestra situación actual actual, pero debemos observar que habrá datos correspondientes debajo de cada índice. Cuando hay pocos campos de datos en la tabla, se puede aceptar de mala gana, pero si hay muchos campos, el índice que Se puede almacenar en cada bloque de hojas también es muy pequeño, por lo que esto no es muy satisfactorio.
1.1.5.B + Árbol
Antes de explicar B + Tree, debemos mirar el diagrama esquemático de B + Tree, como se muestra a continuación.
Las características de B + Tree son las siguientes:
非叶子节点不存储data，只存储索引(冗余)，可以放更多的索引
叶子节点包含所有索引字段
叶子节点用指针连接，提高区间访问的性能¿B + Tree resuelve el problema real?
第一：每一个叶子节点不会专门的带有Data的数据了，那么每个叶子节点存放的数据就会更多，估计到了第三层的时候就能打倒2000W左右的数据存储（解决了二叉树、红黑树、BTree问题）
第二：解决了二叉树连续递增的问题（不仅解决了，这里之后还更加依赖了整形类的数据递增，因为这样的话，才能更好的组装B+Tree的结构，不是递增的情况下有中位数据的产生，有可能导致
数据结构的变化，对于数据库来说也是很大的开销）（解决了二叉树问题）
第三：在最底层的时候会有环行链（首尾相连）的结构在里面，解决了Hash树的范围查询的问题（解决了Hash树问题）1.2. Motor de índice
Hay dos motores de búsqueda convencionales en el motor de indexación de MySQL, uno es MyISAM y el otro es InnoDB
1.2.1. MyISAM (porque los datos y el índice no están juntos, por lo que es un índice no agrupado)
Primero mire la forma en que MyISAM se almacena esencialmente en los datos
Mi tabla de usuario se define como tipo MyISAM, habrá tres archivos en los datos de DATOS
*.frm 存储表结构
*.MYD 存储表数据
*.MYI存储表索引La lógica de consulta real se muestra en la siguiente figura:
Primero, consulte los datos de MYI para determinar la ubicación del almacenamiento de datos y luego ubique todos los datos de acuerdo con la información de ubicación (0x07).
Luego busque el archivo MYD a través de la información de ubicación y obtenga el contenido de los datos directamente.
1.2.2. InnoDB (debido a que el índice y los datos están juntos, también se denomina índice agrupado)
Compruebe cómo se almacena InnoDB
La tabla sys_uesr_role está definida por InnoDB, habrá dos datos de archivo en Data
*.frm 存储表结构
*.idb 存储的是索引和数据La lógica de implementación real se muestra en la siguiente figura:
Índice de clave principal:
Índice de clave no principal:
problema:
为什么InnoDB表必须有主键，并且推荐使用整型的自增主键？
答：没有主键的话，系统会默认的使用 rowid作为主键进行排序，但是rowid是默认的，大小是不确定的，在插入的时候可能会导致索引树结构的变更。这也同时回答了为什么用整数自增型来作为主键
为什么非主键索引结构叶子节点存储的是主键值？(一致性和节省存储空间)
答：非主键这么存储的原因是因为，为了只是维护一份数据，假设如果非主键数据也存在Data,idb的数据是按照倍数增加，而且如果非主键索引存储了数据，
就会包含一致性事务在里面，白白浪费了很多无用的开销。1.3. Índice conjunto
El índice de articulación tiene el principio más a la izquierda.