9. Cómo agregar índice a una cadena
9.1 Índice de prefijo
MySQL admite índices de prefijos. De forma predeterminada, si crea un índice sin especificar una longitud de prefijo, el índice contendrá la cadena completa.
mysql> alter table teacher add index index1(email);
#或
mysql> alter table teacher add index index2(email(6));
Si está utilizando index1 (es decir, la estructura de índice de toda la cadena de correo electrónico), la secuencia de ejecución es la siguiente:
- Busque el registro cuyo valor de índice sea '[email protected]' en el árbol de índice index1 y obtenga el valor de ID2;
- Vaya a la clave principal y busque la fila cuyo valor de clave principal es ID2, juzgue que el valor del correo electrónico es correcto y agregue esta fila de registros al conjunto de resultados;
- Obtenga el siguiente registro en la posición recién encontrada en el árbol de índice index1, descubra que la condición de correo electrónico = '[email protected]' ya no se cumple y el ciclo finaliza.
Durante este proceso, solo necesita recuperar datos del índice de clave principal una vez, por lo que el sistema piensa que solo se ha escaneado una fila.
Si está utilizando index2 (es decir, estructura de índice de correo electrónico (6)), la secuencia de ejecución es la siguiente:
- Busque registros que satisfagan el valor de índice 'zhangs' del árbol de índice index2, y el primero encontrado es ID1;
- Vaya a la clave principal y busque la fila cuyo valor de clave principal es ID1. Se considera que el valor del correo electrónico no es '[email protected]' y esta fila de registros se descarta;
- Obtenga el siguiente registro en la posición que acaba de encontrar en el índice 2 y descubra que todavía es "zhangs". Saque ID2, luego obtenga la fila completa en el índice de ID y juzgue que esta vez el valor es correcto. Agregue esta fila de registros a el conjunto de resultados;
- Repita el paso anterior hasta que el valor obtenido en idxe2 no sea 'zhangs' y el ciclo finalice.
En otras palabras, usar un índice de prefijo y definir la longitud puede ahorrar espacio sin agregar demasiado costo de consulta adicional . Ya hemos hablado antes de discriminación, cuanto mayor sea la discriminación, mejor. Porque cuanto mayor sea la distinción, menos valores clave duplicados.
9.2 El impacto del índice de prefijo en el índice de cobertura
Conclusión:
El uso de índices de prefijo elimina la necesidad de cubrir índices para optimizar el rendimiento de las consultas. Este también es un factor que debe considerar al elegir si desea utilizar índices de prefijo.
10. Desplazamiento del índice
Index Condition Pushdown (ICP) es una nueva característica de MySQL 5.6. Es un método de optimización que utiliza índices para filtrar datos en la capa del motor de almacenamiento. ICP puede reducir la cantidad de veces que el motor de almacenamiento accede a la tabla base y la cantidad de veces que el servidor MySQL accede al motor de almacenamiento.
10.1 Proceso de escaneo antes y después de su uso
En el proceso de no utilizar el escaneo del índice ICP:
Capa de almacenamiento: solo se saca y devuelve a la capa del servidor la fila completa de registros correspondientes a los registros de índice que cumplen con las condiciones de la clave de índice.
Capa de servidor: utilice la condición donde posterior para filtrar los datos devueltos hasta que se devuelva la última fila.
El proceso de uso del escaneo ICP:
- capa de almacenamiento:
Primero, determine el intervalo de registro de índice que satisface la condición de clave de índice y luego use el filtro de índice en el índice para filtrar. Solo los registros de índice que cumplen con las condiciones del filtro de índice se devuelven a la tabla y la fila completa de registros se devuelve a la capa del servidor. Los registros de índice que no cumplen con las condiciones del filtro de índice se descartan y no se devolverán a la tabla ni a la capa del servidor.
- capa de servidor:
Para los datos devueltos, utilice las condiciones de filtro de tabla para el filtrado final.
Diferencia de costos antes y después del uso. Antes de su uso
, la capa de almacenamiento devolvía muchas filas de registros que debían ser filtrados por el filtro de índice.
Después de usar ICP, los registros que no cumplían con las condiciones del filtro de índice se eliminaban directamente, eliminando la necesidad de que se devuelvan a la mesa y se pasen a la capa del servidor.
El efecto de aceleración de ICP depende de la proporción de datos filtrados por ICP en el motor de almacenamiento.
10.2 Condiciones de uso del PCI
Condiciones para usar ICP:
① Solo se puede usar para índice secundario (índice secundario)
②El valor de tipo (tipo de unión) en el plan de ejecución mostrado por explicación es rango, ref, eq_ref o ref_or_null.
③ ICP no puede filtrar todas las condiciones de dónde. Si el campo de la condición de dónde no está en la columna de índice, los registros de toda la tabla aún deben leerse en el servidor para el filtrado de dónde.
④ ICP se puede utilizar para motores de almacenamiento MyISAM e InnnoDB
⑤ MySQL versión 5.6 no admite la función ICP de tablas de particiones y la versión 5.7 comienza a admitirla.
⑥ Cuando SQL utiliza un índice de cobertura, no se admite el método de optimización ICP.
11. Índice ordinario versus índice único
Desde una perspectiva de rendimiento, ¿debería elegir un índice único o un índice normal? ¿Cuál es la base para la selección?
Supongamos que tenemos una tabla con la columna de clave principal como ID. Hay un campo k en la tabla y hay un índice en k. Supongamos que los valores en el campo k no se repiten. La declaración de creación de tabla para esta tabla es:
mysql> create table test(
id int primary key,
k int not null,
name varchar(16),
index (k)
)engine=InnoDB;
Los valores (ID,k) de R1 ~ R5 en la tabla son (100,1), (200,2), (300,3), (500,5) y (600,6) respectivamente.
11.1 Proceso de consulta
Supongamos que la declaración para ejecutar la consulta es select id from test where k=5.
- Para un índice normal, después de encontrar el primer registro (5500) que cumple la condición, debe encontrar el siguiente registro hasta encontrar el primer registro que no cumple la condición k = 5.
- Para un índice único, dado que el índice define la unicidad, la búsqueda se detendrá después de que se encuentre el primer registro que cumpla las condiciones.
- Entonces, ¿cuál es la brecha de rendimiento causada por esta diferencia? La respuesta es, mínimamente.
11.2 Proceso de actualización
Para ilustrar el impacto de los índices ordinarios y los índices únicos en el rendimiento de la declaración de actualización, introduzcamos el búfer de cambios.
Cuando es necesario actualizar una página de datos, si la página de datos está en la memoria, se actualizará directamente. Si la página de datos aún no está en la memoria, InooDB almacenará en caché
estas operaciones de actualización en el búfer de cambios sin afectar la coherencia de los datos. no es necesario
leer esta página de datos desde el disco. Cuando la próxima consulta necesite acceder a esta página de datos, lea la página de datos en la memoria y luego realice
operaciones relacionadas con esta página en el búfer de cambios. De esta forma se puede garantizar la exactitud de la lógica de los datos.
El proceso de aplicar las operaciones en el búfer de cambios a la página de datos original y obtener los resultados más recientes se llama fusión. Además de activar la fusión al acceder a esta página de datos
, el sistema tiene subprocesos en segundo plano que se fusionan periódicamente. Durante el cierre normal de la base de datos,
también se realizará la operación de fusión.
Si la operación de actualización se puede registrar primero en el búfer de cambios para reducir las lecturas del disco, la velocidad de ejecución de la declaración mejorará significativamente. Además,
leer datos en la memoria requiere ocupar el grupo de búfer, por lo que este método también puede evitar la ocupación de memoria y mejorar su utilización.
El búfer de cambios no se puede utilizar para actualizar el índice único, de hecho, solo se pueden utilizar índices ordinarios.
12. Otras estrategias de optimización de consultas
12.1 La diferencia entre EXISTE y EN
No entiendo muy bien en qué caso se debe usar EXISTS y en qué caso se debe usar IN. ¿El criterio de selección se basa en si se puede utilizar el índice de la tabla?
12.2 Eficiencia de COUNT(*) y COUNT (campos específicos)
Pregunta: Hay tres formas de contar el número de filas en una tabla de datos en MySQL: SELECT COUNT(*), SELECT COUNT(1) y
SELECT COUNT (campos específicos) ¿Cuál es la eficiencia de consulta entre estos tres métodos?
12.3 Acerca de SELECCIONAR(*)
En consultas de tablas se recomienda especificar los campos. No utilizar * como lista de campos de la consulta. Se recomienda utilizar la consulta SELECT <lista de campos>. Motivos:
① Durante el proceso de análisis, MySQL convertirá "*" en todos los nombres de columnas en orden consultando el diccionario de datos, lo que consumirá mucho tiempo y recursos
.
② No se puede utilizar el índice de cobertura
12.4 Impacto de LIMIT 1 en la optimización
Está dirigido a declaraciones SQL que escanean toda la tabla. Si puede estar seguro de que solo hay un conjunto de resultados, agregar LIMIT 1 no continuará escaneando cuando se encuentre un resultado, lo que acelerará la consulta.
Si la tabla de datos ha establecido un índice único para el campo, puede consultar a través del índice. Si no se escanea toda la tabla, no es necesario agregar
LÍMITE 1.
12.5 Utilice COMMIT más
Siempre que sea posible, utilice COMMIT tanto como sea posible en el programa, de modo que mejore el rendimiento del programa y reduzca la demanda
debido a los recursos liberados por COMMIT.
Recursos publicados por COMMIT:
- Información sobre el segmento de reversión utilizado para recuperar datos.
- Bloqueo adquirido por declaración del programa
- Espacio en el búfer de registro de rehacer/deshacer
- Gestionar el gasto interno en los 3 recursos anteriores.