Uno, índice
Este artículo toma mySQL como ejemplo.
El uso de índices es el método de optimización más común. En bases de datos por debajo de decenas de millones, los índices pueden mejorar enormemente la eficiencia de las consultas.
A continuación se muestran algunos puntos a los que debe prestar atención al utilizar el índice.
Primero introduzca varios tipos de índices comunes.
Índice de clave primaria de clave primaria (todas las claves primarias son índices de clave primaria, único, no vacío)
Índice único único (solo después de configurar el índice)
Índice índice ordinario (solo significa que el campo está configurado como índice)
Índice (id, nombre de usuario) índice conjunto (Establezca varios campos como índice, y el índice se activa cuando se buscan estos campos al mismo tiempo)
Texto completo Índice de texto completo
1. El índice tiene el "principio de coincidencia situado más a la izquierda"
En la consulta difusa, si se deja borroso y aparece totalmente borroso, el índice no se verá afectado.
Es decir, cuando hay un '%' a la izquierda, el índice no se ve afectado.
//命中索引
SELECT id FROM user WHERE username LIKE "aa%"；
//未命中索引
SELECT id FROM user WHERE username LIKE "%aa"；
//未命中索引
SELECT id FROM user WHERE username LIKE "%aa%"；
En un índice conjunto, el campo izquierdo golpea el índice.
Suponemos que solo se establece el índice conjunto de Index (id, username, iphone).
Si la condición de consulta solo aparece en el campo izquierdo, se puede acceder al índice.
Pero si el campo de la izquierda no aparece, pero aparece el campo de la derecha, el índice no se acierta.
//名中索引
SELECT * FROM user WHERE id='001' AND username='tom' AND iphone='110'；
//名中索引
SELECT * FROM user WHERE id='001' AND username='tom'；
//名中索引
SELECT * FROM user WHERE id='001'；
//未命中索引
SELECT * FROM user WHERE username='tom' AND iphone='110'；
//未命中索引
SELECT * FROM user WHERE id='001' AND iphone='110'；
//未命中索引
SELECT * FROM user WHERE iphone='110'；
2. Otras operaciones que no pueden llegar al índice
Al realizar operaciones de expresión en campos en la cláusula WHERE, las operaciones de función y otras operaciones no se pueden indexar por nombre
//未名中索引
SELECT id FROM user WHERE number/2 = 100;
//未名中索引
SELECT id FROM user WHERE substring(name,1,3) = 'abc';
//将运算放在‘=’右边后，命中索引
SELECT id FROM user WHERE number = 100*2;
Cuando se utilizan condiciones de conexión OR, si una de las condiciones no establece un índice, no se alcanzará el índice.
//如果id和phone中有一个未设置索引，则不命中索引。
SELECT * FROM user WHERE id='001' OR phone='110'；
Al juzgar si un campo no es NULL, el índice no se verá afectado.
Al juzgar si un campo es NULO, presione el índice
//未命中索引
SELECT id FROM user WHERE phone IS NOT NULL;
//命中索引
SELECT id FROM user WHERE phone IS NULL;
El índice no se golpea cuando se usa NOT IN
//未命中索引
SELECT * FROM user WHERE id NOT IN(1,2,3);
//命中索引
SELECT * FROM user WHERE id IN(1,2,3);
Los índices no son tantos como sea posible. Si bien la indexación puede mejorar la eficiencia de la selección correspondiente, también reduce la eficiencia de la inserción y actualización, porque el índice puede reconstruirse durante la inserción o actualización.
Recomendar un buen blog de optimización de bases de datos.
Resumen de optimización de base de datos SQL Programa de optimización de base de datos de 1 millón de niveles
Dos, la elección de existe y en
A menudo escucho que la eficiencia de in no es tan alta como existe, y la cláusula in debe reemplazarse por existe. Pero este no es el caso, debemos elegir según la situación real.
Asumimos una situación, un estudiante de mesa de estudiante y un dormitorio de mesa de dormitorio.
Suponga que queremos encontrar la identificación de estudiante de todos los dormitorios en el área A, donde el campo de la sección no está indexado.
select id from student where dorm_id in (select id from dorm where section='A');
select id from student where exists(select null from dorm where id=dorm_id and section='A')；
Mire las dos sentencias SQL anteriores, haga lo mismo, una usa en y la otra usa existe.
En la primera declaración, la tabla externa puede usar el índice de dorm _id, pero la tabla interna no usa el índice.
En la segunda declaración, la tabla externa no usa el índice y la tabla interna puede usar el índice id.
Por lo tanto, cuando la tabla interna es muy grande, la primera instrucción no usa el índice y es ineficiente, y la segunda instrucción usa el índice para mejorar la eficiencia.
Cuando la mesa interior no es grande, pero la mesa exterior es grande, la primera declaración tiene una ventaja.
Todo, cuando el uso existe, el índice se usa en la tabla interna. Cuando se usa in, el índice se usa en la tabla externa.
Resumen: IN es adecuado para el caso donde la superficie exterior es grande y la superficie interior es pequeña; EXISTS es adecuado para el caso donde la superficie exterior es pequeña y la superficie interior es grande.
Lea este blog para obtener más detalles.
Existe y en son más eficientes
Tres, subbase de datos y subtabla
Cuando los datos de la base de datos alcanzan decenas de millones de niveles, la función del índice empeora cada vez más Para mejorar la eficiencia, los programadores pensaron en un método para dividir los datos.
1. Tabla de puntuación de nivel
Cuando hay demasiados datos en una tabla, la eficiencia de la consulta se ralentizará naturalmente. Para mejorar la eficiencia de la consulta, podemos dividir la tabla A en las tablas A1, A2, A3 ... los campos son todos iguales y los datos se distribuyen uniformemente en varias tablas de acuerdo con una regla determinada , Mejorar la eficiencia de las operaciones de la base de datos.
2. Submesa vertical
La división vertical de tablas significa que algunas tablas tienen muchos campos. Podemos dividir algunos campos relativamente largos y de uso poco frecuente en una nueva tabla, es decir, "tabla grande dividida tabla pequeña", que es conveniente para el desarrollo y el mantenimiento.
Después de todo, la subtabla todavía se opera en una base de datos y el problema de conexiones insuficientes a la base de datos no se resuelve. El cuello de botella de la base de datos aún existe, por lo que realizamos la operación de la subbase de datos.
3. Subbiblioteca horizontal
Subbase de datos horizontal significa que no todas las tablas se colocan en una base de datos. Por ejemplo, las tablas del módulo amigo se colocan en una base de datos y las tablas de otros módulos de transacciones se colocan en otra base de datos. De esta manera, se logra una alta cohesión y un bajo acoplamiento El marco de microservicio actual es la aplicación de una subbase de datos horizontal.
4. Subbiblioteca vertical
La subbase de datos vertical es en realidad el concepto de agrupación. La estructura de división de la base de datos A en A1, A2, A3 ... es la misma, y solo los datos se distribuyen uniformemente entre varias bases de datos para mejorar la eficiencia operativa de la base de datos.
Al mismo tiempo, la subbase de datos y la subtabla también traerán muchos problemas nuevos, por ejemplo, la transacción se vuelve más complicada, la clave principal global para evitar la duplicación, etc.
Lea este blog para obtener más detalles.
Ideas de subtabla de subbase de datos de base de datos
(continuará)