Explicación detallada de los índices MySQL (tutorial a nivel de niñera)

1. Descripción general del índice

Los índices son estructuras de datos (ordenadas) que ayudan a MySQL  a obtener datos de manera eficiente . Además de los datos, el sistema de base de datos también mantiene estructuras de datos que satisfacen algoritmos de búsqueda específicos. Estas estructuras de datos hacen referencia (apuntan) a los datos de alguna manera, de modo que se pueden implementar algoritmos de consulta avanzados en estas estructuras de datos. Esta estructura de datos es una índice. .

2. Ventajas y desventajas de la indexación

ventaja:

• Mejore la eficiencia de la recuperación de datos y reduzca los costos de E/S de la base de datos
• Ordene los datos a través de columnas de índice para reducir el costo de clasificación de datos y reducir el consumo de CPU.

defecto:

• Las columnas de índice también ocupan espacio
• Los índices mejoran enormemente la eficiencia de las consultas, pero reducen la velocidad de las actualizaciones, como INSERTAR, ACTUALIZAR y ELIMINAR.

3. Estructura del índice

3.1 Introducción a la estructura del índice

Estructura del índice	describir
B+árbol	El tipo de índice más común; la mayoría de los motores admiten el índice de árbol B+ (predeterminado)
Picadillo	La estructura de datos subyacente se implementa mediante una tabla hash. Solo son válidas las consultas que coinciden exactamente con la columna de índice. No se admiten consultas de rango.
R-Tree (índice espacial)	El índice espacial es un tipo de índice especial del motor MyISAM, utilizado principalmente para tipos de datos geoespaciales (generalmente menos utilizados)
Texto completo (índice de texto completo)	Es una forma de hacer coincidir documentos rápidamente mediante la creación de un índice invertido, similar a Lucene, Solr, ES (generalmente menos utilizado)

 3.2 Soporte de índices por diferentes motores de almacenamiento

índice	InnoDB	MiISAM	Memoria
B+Índice de árbol	apoyo	apoyo	apoyo
índice hash	no apoyo	no apoyo	apoyo
Índice de árbol R	no apoyo	apoyo	no apoyo
Texto completo	Compatible después de la versión 5.6	apoyo	no apoyo

 Los índices a los que normalmente nos referimos, a menos que se especifique lo contrario, se refieren a índices organizados en una estructura de árbol B+.

 4. Introducción a las estructuras de datos (árbol binario, árbol rojo-negro, Btree, B+tree)

4.1 árbol binario

El árbol binario es una estructura de datos de árbol especial en la que cada nodo tiene como máximo dos nodos secundarios, llamados nodo secundario izquierdo y nodo secundario derecho. La definición de árbol binario es la siguiente:

Un árbol binario puede estar vacío (es decir, no tener nodos) o puede constar de un nodo raíz y dos árboles binarios llamados subárbol izquierdo y subárbol derecho.

Características de los árboles binarios:

1. Cada nodo tiene como máximo dos nodos secundarios, a saber, el nodo secundario izquierdo y el nodo secundario derecho.
2. El subárbol izquierdo y el subárbol derecho también son árboles binarios y pueden estar vacíos.
3. No existe un orden específico para los nodos secundarios de un árbol binario, y las posiciones de los nodos secundarios izquierdo y derecho se pueden determinar de acuerdo con la aplicación específica.

 4.2 Árbol rojo-negro

Un árbol rojo-negro es un árbol de búsqueda binario autoequilibrado que mantiene el equilibrio reorganizando los colores de los nodos después de las operaciones de inserción y eliminación. El nombre de árbol rojo-negro proviene de las marcas de color en cada nodo, que pueden ser rojas o negras.

Los árboles rojo-negros tienen las siguientes características:

1. Cada nodo es rojo o negro.
2. El nodo raíz es negro.
3. Todos los nodos de las hojas (nodos NIL) son negros.
4. Si un nodo es rojo, sus dos nodos secundarios son negros.
5. Para cualquier nodo, la ruta simple desde ese nodo hasta todos sus nodos hoja descendientes contiene la misma cantidad de nodos negros.

Estas características aseguran la propiedad clave de los árboles rojo-negro, es decir, el camino más largo desde el nodo raíz a cualquier nodo hoja no excederá el doble del camino más corto, manteniendo así el equilibrio del árbol. Este equilibrio hace que los árboles rojo-negro sean muy eficientes en aplicaciones prácticas y, a menudo, se utilizan como base para estructuras de datos como colecciones y mapeos.

 Desventajas del árbol rojo-negro: en el caso de un gran volumen de datos, la jerarquía es profunda y la velocidad de recuperación es lenta.

4.3 B-Tree (árbol de búsqueda equilibrado de múltiples rutas)

B-Tree (B-tree) es una estructura de árbol de búsqueda autoequilibrada que se utiliza para almacenar y organizar grandes cantidades de datos. Se utiliza ampliamente en campos como bases de datos y sistemas de archivos para proporcionar acceso a datos y rendimiento de consultas eficientes.

Las características del árbol B incluyen:

1. Equilibrio de rutas múltiples: cada nodo puede contener múltiples palabras clave y subnodos, lo que hace que B-Tree tenga un mejor rendimiento de equilibrio. Normalmente, todos los nodos de hoja de un árbol B se encuentran al mismo nivel.
2. Orden: las palabras clave en B-Tree están organizadas en orden ascendente, lo cual es muy eficiente al realizar consultas de rango.
3. Compatibilidad con el disco: el tamaño del nodo de B-Tree generalmente coincide con el tamaño de la página del disco duro, lo que puede minimizar las operaciones de E/S del disco y mejorar el rendimiento de lectura y escritura.
4. Adaptabilidad: B-Tree puede ajustar dinámicamente su estructura para adaptarse a operaciones dinámicas de inserción y eliminación de datos, manteniendo el equilibrio y un rendimiento estable.

Las operaciones básicas de B-Tree incluyen inserción, eliminación y búsqueda. Durante las operaciones de inserción y eliminación, B-Tree mantiene el equilibrio redistribuyendo claves y ajustando nodos. Al utilizar índices B-Tree, la eficiencia de la recuperación de datos se puede mejorar significativamente, especialmente para conjuntos de datos a gran escala.

Cabe señalar que B-Tree no se limita a la estructura de un árbol binario: cada nodo puede contener varios nodos secundarios, lo que lo hace adecuado para procesar conjuntos de datos a gran escala.

 Referencia de animación del proceso de inserción de datos del árbol B: visualización de estructura de datos

Visualización del árbol B  (si el enlace de demostración anterior no se puede abrir, cámbielo)

4.4 Árbol B+

B + Tree (B + Tree) es una estructura de árbol de búsqueda autoequilibrada similar a B-Tree, que se usa ampliamente en campos como bases de datos y sistemas de archivos. Es una variante de B-Tree. En comparación con B-Tree, tiene algunas optimizaciones en almacenamiento y rendimiento de consultas.

El árbol B+ es similar al árbol B y también tiene las características de equilibrio de rutas múltiples, orden y compatibilidad con el disco. Pero los árboles B+ tienen un diseño diferente en algunos aspectos:

1. Solo los nodos hoja almacenan datos: los nodos internos del árbol B+ solo almacenan información de índice, mientras que los registros de datos reales se almacenan en los nodos hoja, lo que puede mejorar la eficiencia de las consultas de rango.
2. Los nodos hoja están conectados mediante punteros: los nodos hoja del árbol B + están conectados mediante punteros para formar una lista vinculada ordenada, lo que facilita la consulta de rango y el recorrido secuencial.
3. Mejor rendimiento en acceso secuencial: debido a las conexiones de puntero entre los nodos hoja y la forma de una lista enlazada ordenada, los árboles B+ tienen un mejor rendimiento en acceso secuencial. Por ejemplo, para consultas de rango o recorrido de datos en orden de palabras clave, los árboles B+ son más adecuados que el árbol B.
4. Los nodos hoja no están conectados entre sí: no existe una conexión directa entre los nodos hoja del árbol B +, la navegación debe realizarse a través de nodos internos, lo que puede reducir el espacio ocupado por los nodos internos.

Los árboles B+ se utilizan a menudo como estructuras de índice en sistemas de bases de datos y son particularmente adecuados para escenarios que admiten consultas de rango y acceso secuencial a datos. Su equilibrio y compatibilidad con el disco permiten un buen rendimiento durante el almacenamiento y la recuperación de conjuntos de datos a gran escala.

  Referencia de animación del proceso de inserción de datos de B+Tree: Visualización de estructura de datos

Visualización de árbol B+ (si el enlace de demostración anterior no se puede abrir, cámbielo)

La estructura de datos del índice MySQL está optimizada para el árbol B+ clásico. Sobre la base del árbol B + original, se agrega un puntero de lista vinculada que apunta al nodo hoja adyacente para formar un árbol B + con un puntero secuencial, lo que mejora el rendimiento del acceso por intervalos.

4.5 Índice hash hash

Hash Index es una estructura de índice que se utiliza para encontrar rápidamente datos en una base de datos. Para lograr una búsqueda de datos eficiente, convierte la palabra clave (clave) en un valor hash de longitud fija (valor hash) a través de una función hash (función hash) y luego establece una relación de mapeo entre este valor hash y la ubicación de almacenamiento.

Las principales características de los índices hash incluyen:

1. Búsqueda rápida: al utilizar una función hash para asignar palabras clave a ubicaciones de almacenamiento, los índices hash pueden acceder directamente a los datos de destino en un tiempo constante, por lo que tienen una eficiencia de búsqueda muy alta.

2. Optimización de consultas de igualdad: los índices hash son adecuados para consultas de comparación de igualdad (como WHERE columna = valor). Para tales consultas, solo necesita calcular el valor hash y realizar una búsqueda sin atravesar todo el índice.

3. No se admiten consultas de rango ni clasificación: dado que los índices hash se buscan en función de valores hash, no se admiten consultas de rango (como WHERE columna > valor) ni operaciones de clasificación.

4. Manejo de conflictos: dado que la función hash puede asignar diferentes palabras clave al mismo valor hash, esta situación se denomina colisión hash. Los métodos comunes de resolución de conflictos incluyen el método de dirección abierta y el método de lista vinculada.

Cabe señalar que el índice hash puede no ser tan efectivo como el índice de árbol B en algunos escenarios porque no puede admitir consultas de rango y operaciones de clasificación, y el rendimiento puede disminuir cuando hay una gran cantidad de conflictos. Por lo tanto, al seleccionar un tipo de índice, se deben realizar consideraciones integrales basadas en las necesidades comerciales específicas y las características de los datos.

 El índice hash utiliza un determinado algoritmo hash para convertir el valor clave en un nuevo valor hash, lo asigna a la ranura correspondiente y luego lo almacena en la tabla hash.
Si dos (o más) valores clave se asignan a la misma ranura, tendrán un conflicto de hash (también llamado colisión de hash), que se puede resolver mediante una lista vinculada.

Características del índice hash:

• El índice hash solo se puede utilizar para comparación entre pares (=, in) y no admite consultas de rango (entre, >, <,...)
• No se puede utilizar el índice para completar la operación de clasificación
• La eficiencia de la consulta es alta, generalmente solo se requiere una recuperación y la eficiencia suele ser mayor que el índice B + Tree

El motor de almacenamiento admite:

• Memoria
• InnoDB: tiene una función hash adaptativa. El motor de almacenamiento crea automáticamente el índice hash en función del índice B + Tree en condiciones específicas.

---

******Preguntas de entrevista******

¿Por qué el motor de almacenamiento InnoDB elige utilizar la estructura de índice B + Tree?

• En comparación con un árbol binario: cuando se inserta un árbol binario secuencialmente, se formará una lista vinculada y el rendimiento de la consulta se reducirá considerablemente. En el caso de grandes cantidades de datos, la jerarquía es profunda y la velocidad de recuperación es lenta. El árbol B+ puede resolver el problema de la inserción secuencial con menos niveles y alta eficiencia de búsqueda.
• Comparado con el árbol rojo-negro: aunque el árbol rojo-negro resuelve el problema de la inserción secuencial para formar una lista enlazada, es esencialmente un árbol binario, en el caso de grandes cantidades de datos, el nivel es más profundo y la velocidad de recuperación es lento. El árbol B+ puede resolver el problema de la inserción secuencial con menos niveles y alta eficiencia de búsqueda.
• En comparación con B-Tree: para B-Tree, no importa si es un nodo hoja o un nodo no hoja, los datos se guardarán, lo que hará que los valores clave almacenados en una página disminuyan y los punteros también disminuir Para guardar una gran cantidad de datos, la única forma es aumentar La altura del árbol, lo que resulta en un rendimiento reducido. Los nodos internos del árbol B+ solo almacenan información de índice, mientras que los registros de datos reales se almacenan en los nodos hoja, lo que puede mejorar la eficiencia de las consultas de rango. Los nodos hoja del árbol B+ formarán una lista enlazada ordenada, lo que facilita la consulta de rango y el recorrido secuencial.
• En relación con el índice Hash: el índice Hash solo admite la coincidencia de valores iguales y no admite consultas ni clasificación de rangos. B+Tree admite operaciones de clasificación y coincidencia de rangos.

---

5. Introducción a la clasificación de índices.

5.1 Clasificación del índice

Clasificación	significado	Características	Palabras clave
índice de clave primaria	Índice creado en la clave principal de la tabla.	Creado automáticamente por defecto, solo puede haber uno	PRIMARIO
índice único	Evite la duplicación de valores en una columna de datos en una misma tabla	Puede haber múltiples	ÚNICO
índice regular	Localice rápidamente datos específicos	Puede haber múltiples
Índice de texto completo	La indexación de texto completo busca palabras clave en el texto en lugar de comparar valores en el índice.	Puede haber múltiples	TEXTO COMPLETO

5.2 Clasificación del índice del motor de almacenamiento InnoDB 

En el motor de almacenamiento InnoDB, según la forma de almacenamiento del índice, se puede dividir en los dos tipos siguientes:

Clasificación	significado	Características
Índice agrupado	Junte el almacenamiento de datos y el índice, y los nodos hoja de la estructura del índice guardan los datos de la fila.	Debe haber, y sólo uno.
Índice secundario	Almacene datos e índices por separado. Los nodos hoja de la estructura del índice están asociados con las claves primarias correspondientes.	Puede haber múltiples

Reglas de selección de índices agrupados:

• Si existe una clave principal, el índice de clave principal es un índice agrupado.
• Si no hay una clave principal, el primer índice único (ÚNICO) se utilizará como índice agrupado.
• Si la tabla no tiene una clave principal o un índice único adecuado, InnoDB generará automáticamente un ID de fila como un índice agrupado oculto.

 Suponiendo que el campo de identificación de la tabla de usuarios es un índice agrupado y el campo de nombre es un índice secundario, entonces la secuencia de consulta de seleccionar * del usuario donde nombre = 'Arm' es la siguiente:

Los datos de nombre = Arm se consultarán primero en el índice secundario, y la identificación de nombre = Arm es 10, y luego los datos de id = 10 se consultarán en el índice agrupado (los datos de fila de esta fila se almacenan en índice agrupado) La imagen es la siguiente:

Preguntas para pensar

¿Cuál de las siguientes declaraciones SQL tiene la mayor eficiencia de ejecución? ¿Por qué?

select * from user where id = 10;

select * from user where name = 'Arm';

-- 备注：id为主键，name字段创建的有索引

Respuesta: La primera declaración, debido a que la segunda declaración requiere una consulta de tabla, equivale a dos pasos. 

6. Uso de índices (crear, ver, eliminar)

Crear índice:
  CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name, ...);

La explicación es la siguiente:

• CREATE INDEX: Palabra clave para crear índice.
• [ UNIQUE | FULLTEXT ]: Parámetro opcional, especificando el tipo de índice. UNIQUESignifica crear un índice único, es decir, el valor de la columna de índice debe ser único; FULLTEXTsignifica crear un índice de texto completo para búsqueda de texto completo. Si no se especifica, el valor predeterminado es un índice normal.
• index_name:Especifique el nombre del índice.
• ON table_name: Especifique en qué tabla crear el índice, table_namecuál es el nombre de la tabla.
• (index_col_name, ...): Especifique el nombre de la columna para crear un índice. Puede especificar una o más columnas como claves del índice. Separe varias columnas con comas.

Por ejemplo, si desea userscrear un idx_usernameíndice normal nombrado en la tabla nombrada con la columna de índice username, puede usar la siguiente declaración:

        CREAR ÍNDICE idx_username EN usuarios (nombre de usuario);

Si desea crear un índice único, puede UNIQUEagregar la palabra clave a la declaración:

        CREAR ÍNDICE ÚNICO idx_email EN los usuarios (correo electrónico);

Si desea crear un índice de texto completo, puede FULLTEXTagregar palabras clave a la declaración:

        CREAR ÍNDICE DE TEXTO COMPLETO idx_content EN artículos (contenido);

Ver índice:
  SHOW INDEX FROM table_name;

Eliminar índice:
  DROP INDEX index_name ON table_name;

Caso: 

1. -- name字段为姓名字段，该字段的值可能会重复，为该字段创建索引
2. create index idx_user_name on tb_user(name);
3. -- phone手机号字段的值非空，且唯一，为该字段创建唯一索引
4. create unique index idx_user_phone on tb_user (phone);
5. -- 为profession, age, status创建联合索引
6. create index idx_user_pro_age_stat on tb_user(profession, age, status);
7. -- 为email建立合适的索引来提升查询效率
8. create index idx_user_email on tb_user(email);
10. -- 删除索引
11. drop index idx_user_email on tb_user;

7. Análisis de rendimiento de SQL

7.1 Frecuencia de ejecución de SQL (comprender)

 Una vez que el cliente My5QL se haya conectado correctamente, se puede proporcionar información sobre el estado del servidor mediante el comando show [session|global] status. A través de los siguientes comandos, puede verificar la frecuencia de acceso de INSERTAR, ACTUALIZAR, ELIMINAR y SELECCIONAR de la base de datos actual.

Después de conectarse exitosamente al servidor MySQL usando el cliente My5QL, puede obtener la información de estado del servidor usando el comando SHOW SESSION STATUSo . SHOW GLOBAL STATUSEspecíficamente, puede utilizar las siguientes instrucciones para ver la frecuencia de acceso de INSERTAR, ACTUALIZAR, ELIMINAR y SELECCIONAR en la base de datos actual:

MOSTRAR EL ESTADO DE LA SESIÓN COMO 'Com_insert';
MOSTRAR EL ESTADO DE LA SESIÓN COMO 'Com_update';
MOSTRAR EL ESTADO DE LA SESIÓN COMO 'Com_delete';
MOSTRAR EL ESTADO DE LA SESIÓN COMO 'Com_select';

En MySQL, "sesión" y "global" se utilizan para referirse a variables o parámetros en diferentes niveles.

1. Nivel de sesión: las variables o parámetros del nivel de sesión solo se aplican a la sesión actual (conexión). Esto significa que el valor establecido sólo es válido para la conexión actual y no tiene ningún efecto en otras conexiones. Por ejemplo, SETlas variables a nivel de sesión establecidas mediante declaraciones solo tienen efecto en la sesión actual y se restablecerán a sus valores predeterminados una vez finalizada la sesión.

2. Nivel global: las variables o parámetros de nivel global se aplican a toda la instancia del servidor MySQL. Esto significa que el valor establecido es válido para todas las conexiones y sesiones. Por ejemplo, una variable de nivel global establecida modificando un archivo de configuración o usando SET GLOBALuna declaración afecta todas las conexiones y sesiones.

Dentro de un comando, puede acceder a variables o parámetros en diferentes niveles usando:

• SHOW SESSION STATUS: Muestra las variables de estado del nivel de sesión actual.
• SHOW GLOBAL STATUS: muestra variables de estado de nivel global.

Tenga en cuenta que es posible que algunas variables solo se puedan ver o configurar en niveles específicos. Por lo tanto, al elegir utilizar "sesión" o "global", considere si las variables o parámetros requeridos están disponibles en ese nivel o si tienen las restricciones de permisos requeridas.

7.2 Registro de consultas lento (comprender)

El registro de consultas lentas de MySQL es un registro que registra declaraciones de consultas SQL cuyo tiempo de ejecución excede un umbral específico. Le ayuda a identificar y optimizar los cuellos de botella en el rendimiento de su base de datos.

Para habilitar el registro lento de consultas de MySQL, debe realizar los siguientes pasos:

1. Abra el archivo de configuración de MySQL (normalmente `my.cnf` o `my.ini`). Puede encontrar el archivo en:

• Linux: /etc/mysql/my.cnfo/etc/my.cnf
• Windows: en el directorio de instalación de MySQLmy.ini

2. Busque la sección `[mysqld]` en el archivo de configuración, si no existe, agréguela al final del archivo.

3. Agregue la siguiente línea en la sección `[mysqld]` para habilitar el registro de consultas lento y establezca el umbral en segundos:
   slow_query_log = 1
   slow_query_log_file = /path/to/slow-query.log
   long_query_time = 2

• slow_query_log: Configure para  1 habilitar el registro de consultas lento.
• slow_query_log_file: especifique la ruta y el nombre del archivo del registro de consultas lentas. Elija la ruta de archivo y el nombre adecuados según sus necesidades.
• long_query_time: Especifica el número de segundos en los que una consulta tarda más en ejecutarse de lo que se considera una consulta lenta. Este valor se puede ajustar según las necesidades de su aplicación.

4. Guarde y cierre el archivo de configuración.

5. Reinicie el servicio MySQL para que los cambios de configuración surtan efecto.

6. Ahora, el registro de consultas lentas de MySQL está habilitado. Las declaraciones de consulta cuyo tiempo de ejecución supere el umbral se registrarán en el archivo de registro especificado.

Para ver el registro de consultas lentas, puede usar un editor de texto para abrir el archivo de registro especificado (`/path/to/slow-query.log`) para ver las declaraciones de consultas lentas y la información relacionada registrada en él.

Tenga en cuenta que habilitar registros de consultas lentos puede tener cierto impacto en el rendimiento de la base de datos y debe usarse con precaución en entornos de producción y configurarse y administrarse adecuadamente según sea necesario.

7.3 detalles del perfil (ver el tiempo de ejecución de SQL) (comprender)

En MySQL, la función de "perfilado" de consultas se puede utilizar para rastrear y analizar el rendimiento de las consultas. Cuando el análisis de rendimiento de consultas está habilitado, MySQL registrará estadísticas de ejecución detalladas para cada consulta.

Para habilitar la creación de perfiles para una consulta y ver estadísticas de ejecución detalladas para una consulta, siga estos pasos:

1. Abra un cliente MySQL o utilice la herramienta de interfaz gráfica de usuario MySQL adecuada para conectarse a la base de datos.

2. En la sesión, ejecute el siguiente comando para habilitar la función de creación de perfiles de la consulta:
   SET profiling = 1;

3. Luego, ejecute la consulta que desea analizar.

4. Después de ejecutar la consulta, utilice el siguiente comando para ver los detalles del perfil de la consulta:
   MOSTRAR PERFILES;

   Esto mostrará una lista de todas las consultas, cada una con un ID de consulta único.

5. Seleccione la consulta cuyos detalles de perfil desea ver y use el siguiente comando:
   MOSTRAR PERFIL PARA LA CONSULTA <query_id>;
   Reemplace `<query_id>` con el ID de consulta real de la consulta que desea ver.

   Esto mostrará estadísticas de ejecución detalladas relacionadas con la consulta seleccionada, incluido el tiempo de ejecución de la consulta, la cantidad de filas escaneadas, la creación de tablas temporales y más.

6. Después de ver los detalles de creación de perfiles de la consulta, puede utilizar el siguiente comando para detener la creación de perfiles y borrar la información de la consulta registrada:
   SET profiling = 0;

Tenga en cuenta que habilitar la creación de perfiles de consultas puede tener algún impacto en el rendimiento. Por lo tanto, la creación de perfiles debe habilitarse sólo cuando se requiere un análisis detallado del rendimiento de la consulta, y la creación de perfiles debe detenerse inmediatamente para evitar gastos generales innecesarios.

 7.4 explicar el plan de ejecución (importante)

Explicar el plan de ejecución es un comando en MySQL que se utiliza para obtener el plan de ejecución de una declaración de consulta. El plan de ejecución muestra detalles como el orden de las operaciones seleccionadas por el optimizador MySQL al procesar la consulta, los índices utilizados y el método de acceso a los datos.

El conjunto de resultados del plan de ejecución de Explicación contiene varios campos, cada uno de los cuales proporciona información sobre un aspecto diferente de la ejecución de la consulta. Los siguientes son campos comunes y sus significados en el conjunto de resultados de Explicar el plan de ejecución:

1. id:

   • Indica el número de cada operación en el plan de ejecución de la consulta.
   • Para consultas complejas, puede haber múltiples operaciones, que están numeradas según una estructura de árbol.

2. select_type:

   • Indica el tipo de operación a realizar.
   • Los tipos comunes incluyen: SIMPLE (consulta simple), PRIMARY (consulta principal), SUBQUERY (subconsulta), DERIVED (consulta de tabla derivada), UNION (consulta conjunta), etc.
   • Este campo le ayuda a comprender los tipos y relaciones de las diferentes operaciones en la consulta.

3. table:

   • Indica el nombre de la tabla involucrada en la operación.
   • Si la consulta involucra más de una tabla, pueden aparecer varias filas, con flechas que indican el orden de unión.

4. type:

   • Indica cómo MySQL accederá a la tabla.
   • Los tipos comunes incluyen: ALL (escaneo de tabla completa), INDEX (usar escaneo de índice), RANGE (escaneo de rango), REF (usar escaneo de clave de referencia), EQ_REF (búsqueda de índice única), CONST (búsqueda constante), etc.
   • Normalmente, el mejor tipo de acceso es utilizar un índice en lugar de un escaneo completo de la tabla.
   • Los tipos de combinación de mejor a peor son system > const > eq_reg > ref > range > index > ALL.

     ---

     sistema	La tabla tiene solo una fila de registros (igual a la tabla del sistema)
     constante	Consulta de índice usando constantes
     eq_ref	Escaneo de índice único, generalmente usando restricciones de clave primaria
     árbitro	Escaneo de índice no único
     rango	Escaneo de rango de índice
     índice	Escaneo de índice completo
     TODO	Escaneo completo de la tabla

5. possible_keys:

   • Indica índices potenciales que MySQL puede usar.
   • Si se utilizan índices en la consulta, aparecerán en este campo.

6. key:

   • Indica el índice real elegido para utilizar.
   • Si este campo está vacío, no se utiliza ningún índice.
   • Generalmente, un mejor plan de ejecución es utilizar índices eficientes para acelerar las consultas.

7. rows:

   • Le indica a MySQL que estime el número de filas que deben verificarse.
   • Esta es una estimación basada en estadísticas y el algoritmo del selector de índice.

8. Extra:

   • Proporciona información de ejecución adicional para ayudar a comprender mejor los detalles de la ejecución de consultas.
   • Los valores posibles incluyen: usar índice (solo usar índice para consultas), usar dónde (usar la cláusula WHERE para filtrar), usar temporal (usar tabla temporal), usar filesort (usar clasificación de archivos), etc.

Estos campos proporcionan detalles sobre la ejecución de la consulta y pueden ayudar a los desarrolladores a comprender cómo se ejecutó la consulta, los patrones de acceso y si existen posibles problemas de rendimiento. Al analizar los campos en el conjunto de resultados de Explicar el plan de ejecución, puede tomar decisiones de optimización adecuadas, como crear índices apropiados, reescribir consultas o ajustar declaraciones de consulta para mejorar el rendimiento de las consultas.

8. Reglas de uso del índice

8.1 Regla del prefijo más a la izquierda

La regla del prefijo más a la izquierda significa que cuando se utiliza un índice conjunto para realizar consultas, se debe comenzar desde la columna más a la izquierda del índice y no se pueden omitir las columnas del medio. Si se omite una columna, el índice sólo será parcialmente efectivo y los índices de los campos posteriores no serán válidos.

El motivo de esta regla es que el índice conjunto se almacena en orden según varias columnas del índice. Al realizar una consulta, el sistema de base de datos buscará basándose en la columna más a la izquierda del índice y buscará gradualmente hacia la derecha en el orden del índice hasta que se encuentren datos que cumplan con todas las condiciones o no sea posible realizar más coincidencias.

Si omitimos una columna para la consulta, las columnas posteriores a esta columna no se buscarán en el orden del índice, lo que provocará que el índice deje de ser válido. Esto hará que la base de datos necesite escanear más páginas de datos para satisfacer las condiciones de la consulta, lo que reducirá el rendimiento de la consulta.

Por lo tanto, cuando utilice un índice conjunto para realizar consultas, debe cumplir con la regla de prefijo más a la izquierda y realizar consultas en el orden de las columnas del índice, de modo que pueda maximizar las ventajas de rendimiento proporcionadas por el índice. Si necesita realizar consultas flexibles en varias columnas, puede considerar crear un índice más apropiado o utilizar otros métodos de optimización de consultas para mejorar el rendimiento.

8.2 El índice conjunto evita consultas de rango 

Cuando se utiliza un índice conjunto para una consulta de rango (<, >), el índice de columna en el lado derecho de la consulta de rango no será válido. Esto se debe a que las consultas de rango necesitan escanear el índice en un orden determinado y no pueden utilizar completamente el orden del índice.

Para evitar este problema de falla del índice, puede considerar usar >= o <= en lugar de consultas de rango. Al utilizar el operador >= o <=, la consulta de rango se puede convertir en una consulta de igual valor o en una consulta de valor único, de modo que todo el índice conjunto siga siendo válido.

Por ejemplo, si desea realizar una consulta de rango col1 > 5 AND col2 < 10, puede reescribirla como col1 >= 5 AND col1 < x AND col2 < 10, donde x es un valor mayor que 5. De esta manera, dividimos la consulta de rango en dos consultas equivalentes para garantizar el uso efectivo del índice conjunto.

Cabe señalar que al dividir una consulta de rango, debemos elegir un punto de división apropiado (como el valor x en el ejemplo anterior) de acuerdo con la situación específica para garantizar la exactitud y cobertura de los resultados de la consulta. Además, las condiciones de consulta dividida pueden aumentar cierta complejidad lógica y requerir un diseño y pruebas cuidadosos.

8.3 mensajes SQL

1. USE INDEX: Indica a MySQL que utilice un índice específico para ejecutar consultas.
2. IGNORE INDEX: Indica a MySQL que ignore un índice específico y seleccione otros índices disponibles para ejecutar la consulta.
3. FORCE INDEX: Obliga a MySQL a utilizar un índice específico para ejecutar consultas e ignorar otros índices que puedan ser más adecuados.

8.4 Índice de cobertura

Intente utilizar índices de cobertura (la consulta utiliza un índice y todas las columnas que deben devolverse se pueden encontrar en el índice) y reduzca select *.

El significado del campo adicional en explica::
using index conditionLa búsqueda usa un índice, pero es necesario volver a consultar los datos en la tabla
using where; using index;: La búsqueda usa el índice, pero los datos requeridos se pueden encontrar en la columna de índice, por lo que no hay Necesito volver a consultar a la mesa.

Si la fila correspondiente se puede encontrar directamente en el índice agrupado, los datos de la fila se devolverán directamente y solo se requiere una consulta, incluso seleccione *; si el índice agrupado se encuentra en el índice auxiliar, por ejemplo, solo necesita se puede encontrar a través del índice auxiliar (nombre select id, name from xxx where name='xxx';) Para la identificación correspondiente, devuelva el nombre y la identificación correspondiente al índice de nombre. Solo se necesita una consulta; si está buscando otros campos a través del índice auxiliar, debe volver a consultar la mesa, comoselect id, name, gender from xxx where name='xxx';

Así que trate de no usarlo select *, es fácil provocar consultas en la tabla y reducir la eficiencia, a menos que haya un índice conjunto que contenga todos los campos.

Pregunta de la entrevista : Una tabla tiene cuatro campos (id, nombre de usuario, contraseña, estado). Debido a la gran cantidad de datos, es necesario optimizar la siguiente declaración SQL. La mejor solución es cómo proceder:
select id, username, password from tb_user where username='itcast';

Solución: cree un índice conjunto para los campos de nombre de usuario y contraseña, de modo que no sea necesario volver a consultar la tabla y sobrescribir directamente el índice.

8.5 Índice de prefijos

Cuando el tipo de campo es una cadena (varchar, texto, etc.), a veces es necesario indexar una cadena muy larga, lo que hará que el índice sea muy grande y desperdiciará una gran cantidad de E/S del disco durante la consulta, lo que afectará la eficiencia de la consulta. En este caso, puede simplemente eliminar parte del prefijo de la cadena y crear un índice, lo que puede ahorrar mucho espacio en el índice y mejorar la eficiencia de la indexación.

Sintaxis: create index idx_xxxx on table_name(columnn(n));
Longitud del prefijo: se puede determinar en función de la selectividad del índice, que se refiere a la relación entre los valores de índice únicos (cardinalidad) y el número total de registros en la tabla de datos. Cuanto mayor sea la selectividad del índice, mayor será Eficiencia de la consulta. La selectividad del índice única es 1, que es la mejor selectividad del índice y tiene el mejor rendimiento.

Encuentre la fórmula de selectividad:

1. select count(distinct email) / count(*) from tb_user;
2. select count(distinct substring(email, 1, 5)) / count(*) from tb_user;

8.6 Índice de columna única e índice conjunto

Índice de columna única: es decir, un índice solo contiene una sola columna.
Índice conjunto: es decir, un índice contiene múltiples columnas.
En un escenario empresarial, si hay múltiples condiciones de consulta, al considerar crear un índice para el campo de consulta, Se recomienda crear un índice conjunto en lugar de una sola columna.

Situación de índice de una sola columna:
explain select id, phone, name from tb_user where phone = '17799990010' and name = '韩信';
esta oración solo utilizará el campo de índice del teléfono

Precauciones

• Al realizar una consulta conjunta de múltiples condiciones, el optimizador de MySQL evaluará qué campo tiene una mayor eficiencia de indexación y seleccionará ese índice para completar la consulta.

9. Principios de diseño de índices

Criterios de diseño

1. Cree índices para tablas con grandes cantidades de datos y consultas frecuentes.
2. Cree índices para campos que se utilizan a menudo como condiciones de consulta (dónde), operaciones de clasificación (ordenar por) y agrupar (agrupar por).
3. Intente elegir columnas con alta diferenciación como índices e intente crear índices únicos. Cuanto mayor sea la diferenciación, más eficiente será el uso de los índices.
4. Si es un campo de tipo cadena y la longitud del campo es larga, se puede establecer un índice de prefijo en función de las características del campo.
5. Intente utilizar índices conjuntos y reduzca los índices de una sola columna. Al realizar consultas, los índices conjuntos a menudo pueden cubrir el índice, ahorrar espacio de almacenamiento, evitar respaldos de tabla y mejorar la eficiencia de la consulta.
6. Es necesario controlar el número de índices, cuantos más índices, mejor, cuanto más índices, mayor será el costo de mantener la estructura del índice, lo que afectará la eficiencia de las adiciones, eliminaciones y modificaciones.
7. Si una columna indexada no puede almacenar valores NULL, restríjala usando NOT NULL al crear la tabla. Cuando el optimizador sabe si cada columna contiene valores NULL, puede determinar mejor qué índice usar de manera más eficiente para la consulta.

10. Situación de falla del índice

10.1 Operaciones de columna de índice

 Si se realizan operaciones en columnas indexadas, el índice dejará de ser válido. como:explain select * from tb_user where substring(phone, 10, 2) = '15';

Las operaciones de columnas de índice se refieren a operaciones (como cálculos, operaciones de funciones, etc.) en columnas de índice al consultar condiciones o crear índice. En algunos casos, las operaciones en columnas indexadas pueden provocar errores en el índice. Aquí hay algunas razones comunes:

1. Resultados de operaciones impredecibles: cuando se realizan operaciones en columnas de índice, los valores originales de las columnas pueden cambiar, lo que resulta en la imposibilidad de hacer coincidir con precisión los valores clave en el índice. Por ejemplo, si se usa una operación de función en la condición de consulta, por ejemplo WHERE UPPER(column) = 'VALUE', debido a que el índice solo almacena el valor de la columna original en lugar del resultado de la operación de la función, la base de datos no puede usar directamente el índice para una búsqueda y filtrado eficientes.

2. El tipo de resultado de la operación no coincide: el índice se ordena y almacena según un tipo de datos específico. Si una operación da como resultado una discrepancia entre el tipo de datos del resultado y el tipo de datos de la columna de índice, el índice no se utilizará correctamente. Por ejemplo, si realiza una operación de concatenación de cadenas en una columna de índice de números enteros, es posible que no pueda utilizar el índice para acelerar las consultas.

3. La operación hace que las columnas del índice no se puedan comparar en orden: el objetivo principal del índice es proporcionar ordenamiento para localizar y filtrar datos rápidamente. Si se realizan operaciones que hacen que el orden de las columnas del índice sea inconsistente, el índice perderá el orden y no proporcionará optimización para las consultas. Por ejemplo, si se utiliza una operación de función hash irreversible en la condición de consulta, los valores de las columnas de índice no se pueden comparar en orden.

Para evitar fallas en el índice, debe intentar evitar realizar operaciones en las columnas del índice durante las condiciones de consulta o la creación del índice. Si realmente necesita utilizar operaciones, puede considerar las siguientes soluciones:

• Operaciones inversas en columnas de índice: si la operación es reversible, puede mantener la validez del índice aplicando la operación a los parámetros de consulta en lugar de a las columnas de índice.
• Uso de índices de funciones: algunos sistemas de administración de bases de datos proporcionan la función de índices de funciones, que pueden crear índices basados ​​en operaciones de funciones específicas para satisfacer necesidades de consulta específicas.

10.2 Cadenas sin comillas

Si la cadena no se cita al consultar condiciones o crear un índice, el índice puede dejar de ser válido. Aquí hay algunas razones comunes:

1. Falta de coincidencia de tipos de datos: las cadenas en la base de datos deben representarse entre comillas, mientras que los valores sin comillas generalmente se tratan como otros tipos de datos (como nombres de columnas, nombres de funciones, etc.). Si las comillas no se utilizan correctamente al consultar condiciones o crear índices, es posible que la base de datos no coincida correctamente con el tipo de datos de la cadena, lo que provoca que el índice falle.

2. Problema de comparación de cadenas: cuando la base de datos realiza una comparación de cadenas, generalmente se basa en las reglas de clasificación de las cadenas. Si la cadena no está entrecomillada, la base de datos puede analizarla como otro tipo de datos en lugar de compararla según la clasificación de la cadena. Esto puede hacer que el índice no coincida correctamente con las condiciones de la consulta, lo que hace que el índice deje de ser válido.

3. Error de sintaxis: en las sentencias SQL, las cadenas normalmente deben estar entre comillas como estructura de sintaxis legal. Si no se utilizan comillas, pueden producirse errores de sintaxis, lo que provocará que la base de datos no pueda analizar correctamente las condiciones de consulta o crear índices, lo que provocará un error en el índice.

Para evitar problemas de fallas en el índice, asegúrese de que todos los valores de cadena estén entre comillas correctamente al consultar y crear índices. Esto permite que la base de datos identifique correctamente el tipo de cadena y realice una comparación y optimización del índice de acuerdo con las reglas de clasificación de la cadena. Al mismo tiempo, se recomienda consultar la documentación de la base de datos correspondiente para comprender las reglas de sintaxis específicas y las mejores prácticas.

10.3 consulta difusa

En una consulta difusa, si es solo una coincidencia aproximada de cola, el índice no será inválido; si es una coincidencia aproximada de cabecera, el índice no será válido. Por ejemplo: explain select * from tb_user where profession like '%工程';si hay % antes y después, tampoco será válido.

Las siguientes son las razones por las que fallan los índices de coincidencia difusa de cola y de coincidencia difusa de cabeza:

1. Coincidencia difusa de cola: si el carácter comodín de una consulta difusa (como %) aparece solo al final de la cadena de búsqueda, el índice aún se puede usar de manera efectiva. Por ejemplo, utilícelo para LIKE 'abc%'realizar una consulta de coincidencia final, de modo que la base de datos pueda buscar utilizando el índice y devolver resultados coincidentes que comiencen con "abc".

2. Coincidencia aproximada del encabezado: por el contrario, si el carácter comodín de la consulta aproximada (como %) aparece al principio de la cadena de búsqueda, el índice fallará. Por ejemplo, utilice LIKE '%abc'una consulta de coincidencia de encabezado. En este caso, la base de datos no puede utilizar eficazmente el índice para buscar porque no puede determinar la posición inicial del valor coincidente.

La razón principal es que el índice almacena datos en un orden determinado, y el comodín del encabezado de la coincidencia difusa requiere atravesar todo el índice para realizar la coincidencia, lo que hace imposible localizar y filtrar de manera eficiente el orden del índice.

10.4 Condiciones de conexión

Cuando se utiliza el operador OR para combinar varias condiciones, si una de las columnas de las condiciones no tiene un índice, no se utilizará el índice involucrado. Esto se debe a las siguientes razones:

1. Selectividad del índice: el optimizador de la base de datos generalmente decide si utilizar un índice en función de su selectividad. La selectividad se refiere a qué tan únicos son los diferentes valores del índice. Cuando las columnas de una condición no están indexadas, es menos selectiva, lo que significa que contiene menos valores distintos. En este caso, es posible que el índice que utiliza la condición no proporcione un efecto de filtrado suficiente, lo que hace que el optimizador de consultas decida no utilizar el índice.

2. Estimación del costo del plan de consulta: cuando el optimizador de la base de datos determina el plan de consulta, estima el costo en función de cada ruta de ejecución posible. Si una de las columnas de los criterios no está indexada, es posible que los índices involucrados no proporcionen un filtrado efectivo, lo que hace que la estimación de costos para la ruta de ejecución que utiliza el índice sea mayor. Por lo tanto, el optimizador puede elegir otras rutas de ejecución que no utilicen índices.

3. Estructura lógica: para el operador OR, la base de datos necesita evaluar cada condición de forma independiente y combinar los resultados. Si una de las columnas de las condiciones no tiene un índice, es posible que la base de datos necesite escanear toda la tabla para evaluar la condición, lo que entra en conflicto con otras condiciones que utilizan índices. Para evitar el acceso a datos innecesarios y operaciones de fusión, el optimizador puede optar por no utilizar ningún índice.

Para solucionar este problema, puedes considerar las siguientes opciones:

• Asegúrese de que todas las columnas de criterios involucradas tengan índices adecuados para mejorar el rendimiento de las consultas.
• Para tablas grandes, considere refactorizar la consulta para dividir el operador OR en varias consultas independientes y usar UNION o UNION ALL para fusionar los resultados. Esto garantiza que cada subconsulta utilice el índice apropiado y evita fallas de índice causadas por el operador OR.

10.5 Impacto de la distribución de datos

Cuando MySQL evalúa que usar un índice es más lento que un escaneo completo de la tabla, elegirá no usar un índice. Aquí hay un ejemplo:

Para una tabla de estudiantes, si contiene una columna info, infolos campos de la mayoría de los registros están vacíos y el índice está establecido en la columna, cuando se ejecuta la siguiente consulta:

SELECCIONE * DEL estudiante DONDE la información ES NULA;

En este caso, el optimizador de MySQL puede optar por no utilizar el índice en esa columna.

Este es el por qué:

1. Mala selectividad del índice: dado que infolos campos de la mayoría de los registros están vacíos, la selectividad de las columnas del índice es muy baja. La selectividad de un índice se refiere al grado en que diferentes valores son únicos. Cuando la selectividad de una columna es muy baja, significa que el índice no puede proporcionar un buen efecto de filtrado. El optimizador puede considerar que un escaneo completo de la tabla es más eficiente que usar un índice porque puede ser más costoso buscar y acceder a bloques de datos usando un índice.

2. Estimación del costo de acceso a los datos: dado que los campos de la mayoría de los registros infoestán vacíos, cuando se utiliza el índice de esta columna para realizar un escaneo de rango, es posible que sea necesario acceder a una gran cantidad de bloques de datos, lo que aumentará el costo de la consulta. Teniendo en cuenta la distribución de los datos generales, el optimizador puede decidir que es más económico realizar un escaneo directo de la tabla completa.

Por las razones anteriores, el optimizador de MySQL puede optar por no utilizar el índice en esta columna y, en su lugar, utilizar un escaneo completo de la tabla para encontrar inforegistros vacíos.