motor de almacenamiento MyISAM
motor MyISAM utilizado como una estructura de índice B + Árbol, nodo de hoja se almacena en el campo de datos de dirección del registro de datos. La figura es un diagrama esquemático de índice MyISAM: 
aquí proporcionan un total de tres tablas, suponemos clave primaria Col1, el índice primario es un tablas figura MyISAM (clave primaria) esquemáticamente. Se puede ver archivo de índice MyISAM sólo se ahorra los registros de datos de direcciones. En MyISAM, el índice principal y un índice secundario (clave secundaria) sin ninguna diferencia en la estructura, pero el principal requisito clave de índice es único, y el índice de clave auxiliar pueden repetirse. Si construimos un índice secundario en Col2, se muestra el índice de esta estructura a continuación: 
es también un árbol B +, los datos de dirección almacenados en el campo de datos se registra. Por lo tanto, buscar el índice MyISAM algoritmo de primer algoritmo de búsqueda de acuerdo con el índice de búsqueda B + Árbol, si la clave está presente, el valor de su campo de datos llevado a cabo, a continuación, el valor del campo de datos de direcciones, lee el registro de datos correspondiente.
Modo de índices MyISAM también se llama "no agrupado", la razón de la llamada a distinguir el InnoDB índice agrupado.
motor de almacenamiento InnoDB
Aunque InnoDB también ser utilizado como una estructura de índice B + Árbol, pero la manera implementación específica, pero con diferente MyISAM.
La primera diferencia importante es que el archivo de datos InnoDB en sí es un archivo de índice. Conocido de lo anterior, el archivo de índice MyISAM y archivo de datos son independientes, sólo la dirección del archivo de índice se almacena en el registro de datos. En el archivo de datos InnoDB sí mismo es una estructura de índice B + Árbol de presión de la organización, campo de datos nodo hoja de este árbol tiene un registro de datos completo. Este índice es la clave principal de las tablas de datos clave, por lo que el archivo de datos InnoDB en sí es el índice principal. 
InnoDB es un diagrama esquemático del índice principal (también un archivo de datos), se puede ver el nodo hoja contiene un registro completo de datos. Este índice se llama el índice agrupado. Debido propio archivo de datos InnoDB agregación clave principal YAOAN, por lo que InnoDB requiere tabla debe tener una clave principal (MyISAM no puede), si no se especifica de forma explícita, el sistema de MySQL seleccionará automáticamente una columna como la clave principal identifica de forma única un registro de datos, si no hay esta columna, MySQL genera automáticamente un campo oculto como las tablas InnoDB clave primaria, este campo es de 6 bytes de longitud, siempre y tipo entero.
La segunda diferencia es que el índice MyISAM InnoDB de campo de índice secundaria almacena registros de datos correspondiente al valor de clave principal en lugar de una dirección. En otras palabras, todo el índice secundario InnoDB se citan como el campo de datos de clave primaria. Por ejemplo, la siguiente figura muestra la definición de un índice secundario en el Col3: 
aquí los caracteres ingleses en código ASCII como criterios de comparación. Este índice de aplicación en clúster hace que la búsqueda altamente eficiente de prensa clave primaria, pero las necesidades de índice de búsqueda de artículos secundarios para ser recuperada dos veces: primero recuperar se obtiene el índice de clave principal auxiliar, y luego usar el índice principal de la clave principal para recuperar los registros obtenidos.
Aprender de índice diferentes implementaciones del motor de almacenamiento para un uso adecuado y los índices Optimizar son muy útiles, por ejemplo, sabemos que el InnoDB después de que el índice de lograr, es fácil ver por qué no recomienda el uso del campo siempre que la clave principal, ya que todos los índices secundarios son la principal referencia índice, durante mucho tiempo el principal índice hará índices secundarios se vuelven demasiado grandes. Como otro ejemplo, un campo no monótona como la clave principal en InnoDB no es una buena idea porque el archivo de datos InnoDB en sí es un B + Árbol, clave primaria no monótona dará lugar a la inserción de un nuevo archivo de datos de registro con el fin de mantener + Árbol característica B y dividir frecuentes ajustado, muy ineficiente, y el campo de utilización de incremento automático como la clave principal es una buena opción.
InnoDB claves principales de la subasta
Discutidos anteriormente índice InnoDB implementarse, utilizando InnoDB agrupado índice, los datos en sí se almacena en el registro en el índice principal (a B + Árbol) nodos hoja. Esto requiere la misma dentro de una hoja nodo los datos respectivos (el tamaño de una página de memoria o la página de disco) registros almacenados secuencia de clave primaria, por lo que cada vez que hay un nuevo registro se inserta en, MySQL de acuerdo con su clave primaria que se inserta en el nodo apropiado y la ubicación, si el factor de carga de la página alcanzado (InnoDB como el valor predeterminado 15/16), una nueva página (nodo) está abierta.
Si la tabla utilizando la subasta clave primaria, cada vez que se inserta un nuevo registro, que registrará una secuencia posterior agregado a la posición actual del nodo de índice, cuando un lleno, se abrirá automáticamente una nueva página. Como se muestra a continuación:
Esto formará una estructura de índice compacto para llenar la aproximación de orden. Debido a que cada no es necesario para mover los datos existentes se inserta, por lo que la eficiencia es muy alta, no va a añadir un montón de gastos en el mantenimiento de un índice.
Si la clave primaria no incremento (si el número de identificación o número de estudiante, etc.), porque cada clave primaria valores similares a la inserción aleatoria, cada vez que se inserta un nuevo registro en una página de índice existente debe tener una cierta posición intermedia:
En este punto MySQL tuvo que pedir un nuevo registro en los datos de posición y movimiento adecuado, incluso la página de destino puede haber sido escrito de nuevo a disco y borrado de la memoria caché, entonces usted tiene que leer de nuevo desde el disco, lo que añade un montón de gastos generales mientras que los movimientos frecuentes, operación de paginación causó un montón de escombros, no era compacta estructura del índice, el seguimiento tuvo que reconstruir la tabla por Optimizar y rellenos de tabla Optimizar la página.
Por lo tanto, si es posible, debe ser diseñado para auto-energizar a primarias campos clave en InnoDB.
