MySQL que cubre el índice y la consulta de la tabla posterior

I. Introducción 

¿Por qué el proceso de recuperación es completamente diferente para un atributo más?

select id,name from user where name='shenjian'

select id,name,sex from user where name='shenjian'

2. ¿Qué es la consulta back-to-table?

Esto comienza con la implementación del índice de InnoDB. InnoDB tiene dos tipos de índices:

• Índice agrupado (índice agrupado)

• Índice ordinario (índice secundario)

¿Cuál es la diferencia entre el índice agrupado InnoDB y el índice ordinario?

Los nodos hoja del índice agrupado de InnoDB almacenan registros de fila. Por lo tanto, InnoDB debe tener un solo índice agrupado:

1. Si la tabla define PK, PK es un índice agrupado;
2. Si la tabla no define PK, la primera columna única que no es NULL es un índice agrupado;
3. De lo contrario, InnoDB creará un ID de fila oculto como índice agrupado;

Entonces, la consulta PK es muy rápida, ubique directamente el registro de fila.

Los nodos hoja de los índices ordinarios de InnoDB almacenan valores de clave primaria.

Tenga en cuenta que en lugar de almacenar el puntero del encabezado del registro de fila, el nodo hoja índice de MyISAM almacena el puntero del registro.

Por ejemplo, también podría tener una mesa:

user(id PK, name KEY, sex, flag);

id es un índice agrupado y el nombre es un índice normal.

Hay cuatro registros en la tabla:

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

Los dos índices de árbol B + se muestran en la figura anterior:

1. ID es PK, índice agrupado, los nodos hoja almacenan registros de filas;

2. El nombre es KEY, un índice común, y el nodo hoja almacena el valor PK, es decir, id;

Dado que el registro de fila no se puede ubicar directamente desde el índice ordinario, ¿cuál es el proceso de consulta del índice ordinario?

Normalmente, debe escanear el árbol de índices dos veces.

P.ej:

select * from t where name='lisi';

¿Cómo se implementa?

Como la ruta rosa , debe escanear el árbol de índice dos veces:

1. Primero localice el valor de clave principal id = 5 a través del índice ordinario;
2. Busque el registro de fila a través del índice agrupado;

Esta es la llamada consulta back-to-table , que primero localiza el valor de la clave primaria y luego localiza el registro de la fila. Su rendimiento es menor que el de escanear el árbol de índice.

Tres, ¿qué es la cobertura de índices?

En el sitio web oficial de MySQL, aparece una declaración similar en el capítulo de optimización del plan de consulta de explicación, es decir, cuando el campo Extra del resultado de salida de la explicación es Usar índice, se puede activar la cobertura del índice.

Ya sea el sitio web oficial de SQL-Server o el sitio web oficial de MySQL, se expresa: solo un árbol de índice puede obtener todos los datos de columna requeridos por SQL, no es necesario volver a la tabla, más rápido.

Cuarto, ¿cómo lograr la cobertura del índice?

El método común es crear el campo que se consultará en el índice conjunto.

La primera declaración SQL:

select id,name from user where name='shenjian';

 Puede acceder al índice de nombre, el nodo hoja de índice almacena la identificación de la clave principal, y la identificación y el nombre se pueden obtener a través del árbol de índice del nombre, sin volver a la tabla, conforme a la cobertura del índice y con alta eficiencia.

La segunda declaración SQL:

select id,name,sex from user where name='shenjian';

 Se puede acceder al índice de nombre, y el nodo hoja del índice almacena la identificación de la clave principal, pero el campo de sexo debe recuperarse de la consulta de la tabla. Si no se cumple la cobertura del índice, debe escanear el índice agrupado a través del valor de identificación para obtener el campo de sexo nuevamente, y la eficiencia se reducirá.

Es diferente si actualiza el índice de una sola columna de (nombre) al índice conjunto (nombre, sexo).

puede ser visto:

select id,name from user where name='shenjian';

select id,name,sex from user where name='shenjian';

Ambos pueden alcanzar la cobertura del índice sin volver a la mesa.

5. ¿Qué escenarios pueden utilizar la cobertura de índices para optimizar SQL?

Escenario 1: optimización de consultas de recuento completo de tablas

La tabla original es:

user(PK id, name, sex)；

directo:

select count(name) from user;

No se puede utilizar la cobertura del índice.

Agregar índice:

alter table user add key(name);

Puede utilizar la cobertura de índices para mejorar la eficiencia.

Escenario 2: consulta de columna para volver a la optimización de la tabla

select id,name,sex from user where name='shenjian';

Este ejemplo no entrará en detalles. Actualice un índice de una sola columna (nombre) a un índice conjunto (nombre, sexo) para evitar volver a la tabla.

Escenario 3: consulta de paginación

select id,name,sex from user order by name limit 500,100;

Actualice un índice de una sola columna (nombre) a un índice conjunto (nombre, sexo) para evitar volver a la tabla.

Índice ordinario del índice agrupado de InnoDB , de vuelta a la tabla , cobertura del índice .

 

Previous: Optimización del rendimiento del acceso a la base de datos de Oracle

Siguiente: Copia de seguridad y recuperación de la base de datos PostgreSQL