Citar:
Recientemente leí "MySQL de alto rendimiento", aunque todavía no lo he terminado, pero creo que está muy bien escrito. Después de leer la parte del índice, es de
gran ayuda crear un índice y comprender el principio de funcionamiento del índice mysql. Tomé algunas notas sobre el índice y puedes volver atrás y consultarlo cuando encuentres problemas.
1. Ventajas del índice:
Si no está seguro de los conceptos básicos del índice mysql, puede leer mis dos blogs.
Índice agrupado de MySQL y índice no agrupado , el árbol b + vernáculo y el árbol b + .
1.1 El índice reduce en gran medida el número de filas que el servidor necesita escanear
1.2 El índice puede ayudar al servidor a evitar la clasificación y las tablas temporales
1.3 El índice puede cambiar la E / S aleatoria a E / S secuencial
2. Estrategias para usar índices
2.1 Columna independiente
Si la columna de índice es una columna independiente cuando se consulta, significa que el índice no puede ser parte de la expresión, ni puede ser un parámetro de una función.
Ejemplo de error:
1. select user_id from user where user_id + 1 = 7; 这里完全可以写成user_id = 6,这样索引才会生效
2. select * ...where to_days(current_date)-to_days(date_col) <=10
Nota: Si la columna indexada, como el campo detrás de donde en el ejemplo anterior, está indexada, pero porque la columna indexada está manipulada (se convierte en una expresión como user_id + 1),
o usa un par de funciones Se manipuló la columna de índice. Esto hará que el índice falle.
2.2 Índice de prefijo y selectividad de índice
2.2.1
Cuando algunas de las columnas que deben consultarse son relativamente largas, podemos crear un índice de prefijo, que es un índice de cierta longitud delante de esta columna, como alibabayushishidadao, creamos los primeros ocho índices, que es alibaba, y usamos este prefijo para buscar el correspondiente La columna. Pero aquí hay una pregunta, ¿cómo determinar la longitud del índice de prefijo?
Esto menciona un concepto llamado selectividad de índice . La selectividad de índice se refiere a la relación entre el número de índices únicos y el número total de registros de datos T. El rango es 1 / T ~ 1. Cuanto mayor sea la selectividad del índice, mayor será la eficiencia de la consulta, porque esto significa que el índice cubre más datos únicos y puede filtrar más filas al realizar consultas. La selectividad del índice es 1. Entonces, el rendimiento de este índice es extremadamente alto.
Por lo tanto, debemos establecer una longitud de índice de prefijo razonable para aumentar la tasa de selección del índice.
Ejemplo:
select count(distinct left(phone, 3))/count(*) as prefix3,
count(distinct left(phone, 5))/count(*) as prefix5,
count(distinct left(phone, 7))/count(*) as prefix7
from table;
Supongamos que la indexación de prefijos se realiza en el campo del teléfono, y el recuento anterior se puede usar para calcular qué proporción es la más cercana a la tasa de selección de índice de usar directamente el teléfono completo.
De esta manera, podemos cambiar el índice a un índice de prefijo, reduciendo así la longitud del índice y mejorando la eficiencia de la consulta.
2.2.2 Cree un índice de prefijo:
modificar la clave de adición de usuario de la tabla (nombre_usuario (7)) El número es la longitud del índice de prefijo
2.2.3 Desventajas del índice de prefijo:
1. Debido a que el índice de prefijo no es la longitud completa de la columna, no se puede agrupar y ordenar por
2. Al mismo tiempo, debido a que no es la longitud completa de la columna, no se puede alcanzar el índice de cobertura
2.2.4 Nota: Otros escenarios de uso del índice de prefijo son usar una identificación única para datos más largos o, a veces, es necesario usar un índice de sufijo (por supuesto, mysql no lo admite, pero damos la vuelta a los datos y los almacenamos cuando almacenamos datos )
2.3 Índice de varias columnas
Si encuentra que type = index_merge aparece en la explicación, entonces debe considerar la racionalidad de la creación de índices.
Este tipo de combinación de índices suele consumir una gran cantidad de recursos de memoria y CPU. Más importante aún, el optimizador no los calculará en el costo de la consulta. El optimizador solo se preocupa por la cantidad de datos leídos por páginas aleatorias.
2.4 Elija el orden de índice apropiado
No existe una regla fija para el orden del índice, debe crearse de acuerdo con el uso real.
Pero en general, colocamos los campos con alta frecuencia de uso y alta tasa de selección de índice al frente, y colocamos los campos que involucran consultas de rango y baja frecuencia de uso al final.
3.5 índice agrupado
3.5.1
La clave principal es preferiblemente una identificación autoincrementada, por lo que cada vez que ingresan nuevos datos, solo necesita agregar datos a la última columna de los datos del índice agrupado.Incluso si la página de datos actual está llena, solo necesita renovarla. Comience a agregar datos en una página. Si se trata de una clave principal que no tiene ningún orden, como uuid, porque los datos insertados vienen en orden en innodb, suponiendo que la clave principal de la uui insertada es más pequeña que la clave principal anterior, los datos anteriores se moverán , Para permitir que se inserten nuevos datos, y cuando la página de datos esté llena, consumirá más recursos para hacer frente a tal situación. Habrá una división continua de páginas, y la división continua de páginas causará fragmentación. , Entonces ocupará más espacio que una clave primaria normal de autoincremento.
3.5.2
Desventajas de la clave primaria de incremento automático: en el caso de la simultaneidad, puede conducir a la competencia de recursos, porque el límite superior del ID de incremento automático es que todos los subprocesos competirán y todas las inserciones deben obtener el incremento automático más reciente y más grande. id, y la concurrencia mantendrá este límite superior en constante cambio.
3.5.3
MySQL no puede realizar operaciones similares en el índice. Si es el prefijo de la izquierda como comparación, se puede indexar, porque se convertirá en una operación de comparación simple. Pero si es una consulta de rango como "% xxx%" al comienzo de un comodín, es No utilice el índice, ya que los motores de búsqueda no pueden comparar comodines con índices específicos.
consejos: seleccione sum (descripción = 3), sum (category_type = 2) de shop_page_field; De esta manera, puede contar cuántos datos pertenece el campo modificado a un determinado valor. Parece ser más conveniente escribir que contar, pero cómo se compara el rendimiento, Eso no se sabe.
4.5. Índice de cobertura
4.5.1 Beneficios del índice de cobertura:
1. Las entradas de los datos del índice de cobertura son más pequeñas que el volumen total de datos y la velocidad de la consulta será más rápida
. 2. Por supuesto, si los datos se obtienen directamente del índice, no es necesario recorrer el índice agrupado y no se requiere una consulta secundaria.
4.6. Índices no utilizados
Abra estados de usuario en el servidor (el valor predeterminado es cerrado) y luego deje que el servidor se ejecute durante un período de tiempo. Luego, consulte INFORMATION_SCHEMAINDEX.STATISTCS para averiguar la tasa de uso de un índice. Si no se utiliza un índice, se puede eliminar.
4.7 Índices y bloqueos
La granularidad de los bloqueos innodb puede alcanzar el nivel de fila, y hay un total de bloqueos de nivel de fila y bloqueos de nivel de mesa. El bloqueo de fila debe agregarse al índice para lograrlo, debido a que la clave principal, el índice y la información se almacenan en el índice, la
fila de datos se puede bloquear con precisión. Si no se agrega un índice, la tabla se bloqueará al realizar operaciones como actualizar. Preste atención a esto.
4.8 Indexación y clasificación
Si un campo se usa a menudo para ordenar, es mejor agregar un índice. A través de la palabra clave explicar, puede ver que el orden de archivo se devuelve en el campo adicional (mysql se denomina clasificación de archivos, aunque los archivos de disco no se usan necesariamente). Después de
agregar el índice Este tipo de archivo no se mostrará.
Supongamos que tenemos índices (A, B, C)
y luego declaraciones de consulta, si la clasificación bajo el objeto es válida
(1)select * from table where A = 'a' order by B, C;(索引生效)
(2)select * from table where A = 'a' order by B;(索引生效)
(3)select * from table where A = 'a' order by A, B;(索引生效)
(4)select * from table where A = 'a' order by C; （索引对A生效，对C排序没有生效）
(5)select * from table where A = 'a' order by B, D (不生效，引用了一个不再索引列的字段)
(6)select * from table where A > 'a' order by B, C(不生效，对于A是范围查询，索引失效)
(7)select * from table where A = 'a' and B in ('b1', 'b2') order by C (失效对于B in的情况也是范围查询，索引失效)
4.9 Otras estrategias de optimización
Cuando el contenido de la consulta es similar a la URL, la eficiencia de usar btree no será tan alta, porque la URL es generalmente relativamente larga y los tiempos de búsqueda del índice y la eficiencia no son buenos.
En este momento, podemos realizar crc32 o crc64 en la URL, calcular su valor hash y almacenarlo.
Pero crc32 / crc64 chocará, por lo que las condiciones de consulta deben traer la URL original;
seleccione * de url_table donde url_hash = "1342134234" y url = "Http://www.baidu.com".
Primero, se encontrará la URL correspondiente de acuerdo con url_hash, puede haber colisiones pero la consulta es rápida, y luego se filtra según el valor de la URL,
para que el rendimiento de la consulta sea alto.
Aquí url_hash sigue siendo el índice btree utilizado, pero será mucho más rápido filtrar la URL que la URL larga directa. Puede convertirse en un índice pseudo hash
Nota: Tanto crc64 como fnv64 () requieren mysql para instalar complementos adicionales, no mysql viene oficialmente con él. Entonces, si no está instalado, podemos realizar MD5 y operaciones similares para guardar un valor hash al escribir datos en el programa.