Resumen de las preguntas comunes de la entrevista de MYSQL

1NF (primera forma normal): el atributo (correspondiente al campo de la tabla) ya no se puede dividir, es decir, este campo solo puede tener un valor y no se puede dividir en muchos otros campos. 1NF es el requisito más básico de todas las bases de datos relacionales , es decir, las tablas creadas en bases de datos relacionales deben satisfacer la primera forma normal.

2NF (Segunda forma normal): 2NF requiere que cada instancia o fila en la tabla de la base de datos se distinga de manera única . 2NF agrega una columna sobre la base de 1NF. Esta columna se denomina clave principal y los atributos no principales dependen de la clave principal. llave.

3NF (Tercera forma normal): Sobre la base de 2NF, 3NF requiere que cada columna esté directamente relacionada con la columna de clave principal, en lugar de estar indirectamente relacionada, es decir, no hay información de clave no principal de otras tablas.

Durante el proceso de desarrollo, no es necesario satisfacer los tres paradigmas. A veces, para mejorar la eficiencia de las consultas, los campos de otras tablas pueden ser redundantes en la tabla.

2. Diferencia entre declaración DML y declaración DDL

DML es la abreviatura de Data Manipulation Language (lenguaje de manipulación de datos), que se refiere a la operación de registros de tablas en la base de datos, que incluye principalmente la inserción, actualización, eliminación y consulta de registros de tablas, y es la operación diaria más utilizada por los desarrolladores. .
DDL (Lenguaje de definición de datos) es la abreviatura de Lenguaje de definición de datos En pocas palabras, es un lenguaje operativo para crear, eliminar y modificar objetos dentro de la base de datos. La mayor diferencia entre este y el lenguaje DML es que DML solo opera en los datos internos de la tabla y no involucra la definición de la tabla, la modificación de la estructura y no involucra otros objetos. Las declaraciones DDL son más utilizadas por los administradores de bases de datos (DBA) y rara vez las usan los desarrolladores generales.

3. La diferencia entre clave primaria y clave externa

Clave principal : se utiliza para identificar de forma única una fila de datos, no puede haber repetición, no se permiten espacios vacíos y una tabla solo puede tener una clave principal;
Clave foránea : Se utiliza para establecer una relación con otras tablas.La clave foránea es la clave primaria de otra tabla.La clave foránea puede tener duplicados y puede ser nula. Una tabla puede tener múltiples claves foráneas;

4. La diferencia entre soltar, eliminar y truncar

(1) uso diferente

drop(Descartar datos): drop table 表名, elimina directamente la estructura de la tabla, se usa al eliminar la tabla.
truncate(Borrar datos): truncate table 表名solo borra los datos de la tabla, y al insertar datos, la identificación de incremento automático comienza de nuevo desde 1, que se usa al borrar los datos de la tabla.
delete(eliminar datos): delete from 表名 where 列名=值, para eliminar los datos de una fila, si no wherese agrega ninguna cláusula, truncate table 表名el efecto es similar.

(2) pertenecen a diferentes lenguajes de base de datos

truncatey dropson instrucciones DDL (lenguaje de definición de datos), la operación surte efecto de inmediato, los datos originales no se colocan en el segmento de reversión, no se pueden revertir y la operación no activa un disparador.
deleteLa declaración es una declaración DML (lenguaje de manipulación de base de datos). Esta operación se colocará en el segmento de reversión y tendrá efecto después de que se confirme la transacción.

(3) La velocidad de ejecución es diferente

deleteCuando se ejecuta el comando, binlogse generará el registro de la base de datos, y el registro del registro requiere mucho tiempo, pero también tiene la ventaja de facilitar la reversión y recuperación de datos.
truncateEl registro de la base de datos no se genera cuando se ejecuta el comando, por lo que es deletemás rápido que el comando. Además, el valor de autoincremento de la tabla se restablecerá y el índice se restaurará al tamaño original.
dropEl comando liberará todo el espacio ocupado por la mesa.

En general: drop> truncate>delete

5. Infraestructura

La siguiente figura es un breve diagrama de la arquitectura de MySQL. En la siguiente figura, puede ver claramente cómo se ejecuta una instrucción SQL del cliente dentro de MySQL.

imagen

Conector: relacionado con la autenticación de identidad y la autoridad (al iniciar sesión en MySQL).
Caché de consulta: al ejecutar una declaración de consulta, primero consultará el caché (eliminado después de MySQL 8.0, porque esta función no es muy práctica).
Analizador: si no se golpea el caché, la declaración SQL pasará a través del analizador.Para decirlo sin rodeos, el analizador primero debe ver lo que está haciendo su declaración SQL y luego verificar si la sintaxis de su declaración SQL es correcta.
Optimizer: Ejecutar de acuerdo a la solución óptima considerada por MySQL.
Ejecutor: ejecuta sentencias y devuelve datos desde el motor de almacenamiento. Antes de ejecutar la sentencia, juzgará si tiene permiso, si no lo tiene, informará de un error.
Motor de almacenamiento enchufable : es el principal responsable del almacenamiento y la lectura de datos. Adopta una arquitectura enchufable y es compatible con InnoDB, MyISAM, Memory y otros motores de almacenamiento.

6. ¿Cuál es la diferencia entre MyISAM e InnoDB?

Antes de MySQL 5.5, el motor MyISAM era el motor de almacenamiento predeterminado de MySQL y, después de MySQL 5.5, InnoDB era el motor de almacenamiento predeterminado de MySQL.

(1) Si admitir bloqueos de nivel de fila

MyISAM solo tiene bloqueos a nivel de tabla, mientras que InnoDB admite bloqueos a nivel de fila y bloqueos a nivel de tabla, y el valor predeterminado es bloqueo a nivel de fila.

(2) Si respaldar transacciones

MyISAM no brinda soporte para transacciones, InnoDB brinda soporte para transacciones, implementa los cuatro niveles de aislamiento definidos por el estándar SQL y tiene la capacidad de confirmar y revertir transacciones.

El nivel de aislamiento REPEATABLE-READ (relegible) utilizado por InnoDB de forma predeterminada puede resolver el problema de la lectura fantasma (basado en MVCC y Next-Key Lock).

(3) Si admitir claves foráneas

MyISAM no lo admite, pero InnoDB sí.

(4) Si admitir la recuperación segura después de un bloqueo anormal de la base de datos

MyISAM no lo admite, pero InnoDB sí. Después de que la base de datos que usa InnoDB falla de manera anormal, cuando se reinicia la base de datos, se asegurará de que la base de datos se restaure al estado anterior al bloqueo. El proceso de recuperación depende de redo log.

(5) Si es compatible con MVCC

MyISAM no lo admite, pero InnoDB sí.

(6) Implementación del índice

Aunque tanto el motor MyISAM como el motor InnoDB utilizan B+Tree como estructura de índice, los métodos de implementación de los dos son diferentes.

En el motor InnoDB, sus archivos de datos son en sí mismos archivos de índice. El archivo de datos de la tabla en sí es una estructura de índice organizada por B+Tree, y el campo de datos del nodo hoja del árbol almacena registros de datos completos.
Los archivos de índice y los archivos de datos de MyISAM están separados, y el índice almacena punteros a archivos de datos.

(7) diferencia de rendimiento

El rendimiento de InnoDB es más fuerte que el de MyISAM. No importa en modo mixto de lectura y escritura o en modo de solo lectura, a medida que aumenta la cantidad de núcleos de CPU, las capacidades de lectura y escritura de InnoDB aumentan linealmente. Debido a que MyISAM no puede leer y escribir simultáneamente, su poder de procesamiento no tiene nada que ver con la cantidad de núcleos.

imagen

Comparación de rendimiento de InnoDB y MyISAM

7. Recomiende la identificación autoincremental como el problema clave principal

El árbol B+ del índice ordinario almacena el valor del índice de clave principal. Si el valor es grande, "resultará en un espacio de almacenamiento más grande para el índice ordinario".
Use la identificación de incremento automático como el índice de clave principal para insertar nuevos datos siempre que se coloque al final de la página, directamente "insertar en orden" sin mantener deliberadamente
La división de páginas es fácil de mantener. Cuando la página actual en la que se insertan los datos está casi llena, se producirá la división de páginas. Si el índice de la clave principal no es una identificación de aumento automático, los datos se pueden insertar desde la mitad de la página y el los datos en la página cambiarán con frecuencia ". Lo que lleva a mayores costos de mantenimiento para las divisiones de página"

8. Por qué la clave principal de incremento automático de MySQL no es continua

En MySQL 5.7 y versiones anteriores, el valor de autoincremento se almacena en la memoria y no se conserva;
Conflicto de clave única: al insertar datos, primero aumente la clave principal de incremento automático +1, y luego, al insertar datos, la clave única entra en conflicto, la inserción de datos falla, pero la clave principal de incremento automático no se vuelve a cambiar;
Reversión de transacciones: similar al conflicto de clave única, el valor de incremento automático no se revertirá durante la operación de reversión. De hecho, la razón principal para hacer esto es mejorar el rendimiento.

9. ¿Qué hace el registro de rehacer?

redo log(registro de rehacer) es InnoDBexclusivo del motor de almacenamiento, lo que permite MySQLla recuperación de fallas.

Por ejemplo, si MySQLla instancia se cuelga o se cae, al reiniciar, InnoDBel motor de almacenamiento utilizará redo loglos datos restaurados para garantizar la persistencia y la integridad de los datos.

Al actualizar los datos de la tabla, si se encuentra que Buffer Poolhay datos para actualizar en , se actualizarán Buffer Pooldirectamente en . Luego, registrará "qué modificación se realizó en una determinada página de datos" en el caché de registro de rehacer ( redo log buffer), y luego lo actualizará en redo logel archivo.

10. Momento de vaciar el registro de rehacer

imagen

La parte roja es el búfer de registro de rehacer que pertenece a la memoria
La parte amarilla es la memoria caché de la página, que se ha escrito en el disco en este momento, pero no se ha conservado
La parte verde es el disco duro, que ha sido persistente

El motor de almacenamiento InnoDB proporciona el parámetro innodb_flush_log_at_trx_commit para la estrategia de vaciado del registro de rehacer, que admite tres estrategias

Cuando se establece en 0, significa que la operación del disco no se realizará cada vez que se confirme la transacción , sino que solo se mantendrá en el búfer de registro de rehacer, y el bloqueo de mysql perderá 1s de datos;
Cuando se establece en 1, significa que cada vez que se confirma una transacción, se realizará la operación del disco (valor predeterminado) y se conservará en el disco;
Cuando se establece en 2, significa que solo el contenido del búfer de registro de rehacer se escribe en el caché de la página cada vez que se confirma la transacción , y el tiempo de inactividad del sistema operativo perderá 1 s de datos porque no se conserva;

El parámetro innodb_flush_log_at_trx_commit tiene como valor predeterminado 1, lo que significa que cuando se confirma la transacción, se llamará a fsync (operación síncrona) para vaciar el registro de rehacer.

Además, el motor de almacenamiento InnoDB tiene un subproceso en segundo plano que escribe el contenido del búfer de registro de rehacer en la caché del sistema de archivos (caché de página) cada segundo y luego llama a fsync para vaciar el disco.

Cuando el espacio ocupado por el búfer de registro de rehacer está a punto de alcanzar la mitad de innodb_log_buffer_size, el subproceso de fondo vaciará activamente el disco.

11. ¿Cómo redo log grab logs?

redo logNo solo hay un archivo de registro almacenado en el disco duro , sino en forma de un grupo de archivos de registro , y el tamaño de cada redoarchivo de registro es el mismo.

Por ejemplo, se puede configurar como un grupo de 4archivos, y el tamaño de cada archivo es el contenido que 1GBtodo el redo loggrupo de archivos de registro puede registrar 4G.

Adopta la forma de una matriz en anillo, escribe desde el principio, escribe hasta el final y vuelve al principio para escribir en bucle, como se muestra en la figura siguiente.

imagen

Por lo tanto, si los datos están llenos pero no han tenido tiempo de vaciar los datos en el disco, entonces ocurrirá el fenómeno de "inestabilidad de la memoria" .Desde la perspectiva del ojo humano, se encontrará que mysql estará inactivo por un rato, y en este momento está vaciando el disco.

12. ¿Qué es binlog?

binlog es un registro de archivo, que pertenece al registro de la capa del servidor. Es un archivo en formato binario. El contenido del registro es la lógica original de la declaración, que es similar a "agregar 1 al campo c de la línea ID = 2 ".

binlogIndependientemente del motor de almacenamiento utilizado, se generarán registros siempre que se actualicen los datos de la tabla . Su función principal es la copia de seguridad de datos y la replicación maestro-esclavo.

binlogSe registran todas las operaciones lógicas de actualización de datos, que pertenecen al registro lógico y se escriben secuencialmente.

13. Formato de registro de binlog

binlogHay tres formatos para los registros, que binlog_formatse pueden especificar mediante parámetros.

declaración : El contenido del registro es SQLel texto original de la declaración, y hay un problema de consistencia de datos;
fila : el registro contiene los datos específicos de la operación, lo que puede garantizar la consistencia de los datos sincronizados;
mixto : El contenido del registro es una mezcla de los dos anteriores, y se juzgará si MySQLesta declaración puede causar inconsistencia en los datos: si es así, use el formato, de lo contrario use el formato.SQLrowstatement

14. Mecanismo de escritura de binlog

Durante la ejecución de la transacción, primero se escribe el registro binlog cachey, cuando se confirma la transacción, se binlog cacheescribe binlogen el archivo.

Debido a que una transacción binlogno se puede desensamblar, no importa cuán grande sea la transacción, debe escribirse de una sola vez, por lo que el sistema asignará un bloque de memoria a cada subproceso binlog cache.

Podemos binlog_cache_sizecontrolar el tamaño de caché binlog de un solo hilo a través de parámetros.Si el contenido de almacenamiento excede este parámetro, debe almacenarse temporalmente en el disco ( Swap).

binlog también proporciona el parámetro sync_binlog para controlar el tiempo de escritura en el caché de la página y el disco:

0: cada vez que se envía una transacción, solo se escribe en la memoria caché de la página del sistema de archivos. El sistema decide cuándo ejecutarla fsync. Si la máquina falla, page cacheel binlog interno se perderá.
1: Cada vez que se confirme una transacción fsync, se ejecutará, al igual que el proceso de vaciado del registro de rehacer .
N(N>1): cada vez que se confirma una transacción, se escribe en la memoria caché de la página del sistema de archivos, pero Nsolo después de acumular una transacción fsync. Si la máquina deja de funcionar, se perderá el registro Nde la transacción más reciente binlog.

15. ¿Cuál es la diferencia entre redolog y binlog?

Redolog es el registro único de Innodb , mientras que binlog está en la capa del servidor y se utilizan todos los motores de almacenamiento;
Redolog registra valores específicos , qué modificaciones se realizan en una determinada página y el contenido de la operación registrado por binlog ;
Cuando el tamaño del binlog alcanza el límite superior o el registro de vaciado generará un nuevo archivo , el redolog tiene un tamaño fijo y solo se puede reciclar ;
El registro binlog no tiene la capacidad de seguridad contra fallas y solo se puede usar para archivar, mientras que el registro de rehacer tiene la capacidad de seguridad contra fallas;
El registro de rehacer se puede escribir continuamente durante la ejecución de la transacción (el vaciado se establece en 1, el subproceso de fondo se ejecuta una vez cada 1 o el espacio ocupado por el búfer del registro de rehacer está a punto de alcanzar la mitad del innodb_log_buffer_size), mientras que el binlog solo se escribe en la memoria caché del archivo cuando la transacción se confirma en el sistema;

16. Compromiso de dos fases

Suponiendo que después de escribir el registro de rehacer en el proceso de ejecución de sql, se produce una excepción durante la escritura del registro binlog, ¿qué sucederá?

Debido a que el binlog es anómalo antes de que finalice, no hay ningún registro de modificación correspondiente en el binlog en este momento. Por lo tanto, cuando se utilice el registro binlog para restaurar datos más tarde, se omitirá esta actualización y los datos finales serán incoherentes .

Para resolver el problema de la coherencia lógica entre dos registros, el motor de almacenamiento InnoDB utiliza un esquema de confirmación de dos fases .

La escritura del registro de rehacer se divide en dos pasos: preparación y confirmación, que es una confirmación de dos fases. Después de usar la confirmación de dos fases, no afectará la excepción al escribir en el binlog, porque cuando MySQL restaura datos basados en el registro de rehacer, encuentra que el registro de rehacer todavía está en la etapa de preparación y no hay ningún registro de binlog correspondiente. , por lo que la transacción se revertirá.

Veamos otro escenario. Se produce una excepción en la fase de confirmación de la configuración del registro de rehacer. ¿Se revertirá la transacción?

La transacción no se revertirá.Aunque el registro de rehacer está en la etapa de preparación, el registro binlog correspondiente se puede encontrar a través de la identificación de la transacción, por lo que MySQL lo considera completo y enviará la transacción para restaurar los datos.

17. ¿Qué es el registro de deshacer?

Sabemos que si queremos asegurar la atomicidad de las transacciones , necesitamos revertir las operaciones ejecutadas (INSERTAR, ELIMINAR, ACTUALIZAR) cuando ocurre una excepción. En MySQL, el mecanismo de recuperación se implementa revirtiendo el registro (deshacer registro) Sí, todas las modificaciones realizadas por transacciones se registrarán primero en este registro de reversión y luego se realizarán las operaciones relacionadas.

Cada vez que se cambia un registro, se registrará un registro de deshacer, y cada registro de deshacer también tiene un DB_ROLL_PTRatributo. Estos registros de deshacer se pueden conectar entre sí para formar una lista vinculada para formar una cadena de versiones.

El nodo principal de la cadena de versiones es el último valor del registro actual.

imagen

18. ¿Qué es el registro de retransmisión?

Relaylog es un registro de retransmisión, que se usa durante la sincronización maestro-esclavo.Es un archivo de registro temporal intermediario que se usa para almacenar el contenido del registro binlog sincronizado desde el nodo maestro.

imagen

Después de que el binlog del nodo maestro maestro se transmite al nodo esclavo, se escribe en el registro de retransmisión y el subproceso sql esclavo del nodo esclavo lee el registro del registro de retransmisión y lo aplica localmente al nodo esclavo.

El subproceso de E/S del servidor esclavo lee el registro binario del servidor maestro y lo registra en el archivo local del servidor esclavo, y luego el subproceso SQL lee el contenido del registro de registro de retransmisión y lo aplica al servidor esclavo, por lo que que los datos del servidor esclavo y del servidor maestro permanezcan unánimes .

19. Índice

El índice es en realidad una estructura de datos que puede ayudarnos a recuperar rápidamente datos en la base de datos.

La función del índice es equivalente a la tabla de contenido del libro. Por ejemplo: cuando buscamos un diccionario, si no hay un directorio, solo podemos encontrar la palabra que necesitamos buscar página por página, y la velocidad es muy lenta. Si hay una tabla de contenido, solo necesitamos ir a la tabla de contenido para encontrar la posición de la palabra y luego pasar directamente a esa página.

20. Índice hash

Una tabla hash es una colección de pares clave-valor. El valor correspondiente (valor) se puede recuperar rápidamente a través de la clave (clave), por lo que la tabla hash puede recuperar datos rápidamente (cerca de O(1)).

¡pero! El algoritmo hash tiene un problema de conflicto Hash, lo que significa que varias claves diferentes finalmente obtienen el mismo índice. Por lo general, nuestra solución común es el método de dirección de cadena .

El método de dirección de cadena es almacenar los datos de colisión hash en la lista enlazada. Por ejemplo, antes de JDK1.8, HashMap usaba el método de dirección de cadena para resolver conflictos de hash. Sin embargo, después de JDK1.8, HashMap introdujo un árbol rojo-negro para reducir el tiempo de búsqueda cuando la lista enlazada es demasiado larga.

Para reducir la ocurrencia de colisiones hash, una buena función hash debería distribuir datos "uniformemente" en todo el conjunto de posibles valores hash.

Dado que la tabla hash es tan rápida, ¿por qué MySQL no la usa como una estructura de datos de índice? Principalmente porque los índices hash no admiten consultas secuenciales y de rango . Si queremos ordenar los datos en la tabla o realizar una consulta de rango, entonces el índice Hash no funcionará y solo se puede tomar una IO cada vez.

21. Árbol B y árbol B+

Todos los nodos del árbol B almacenan claves y datos, mientras que solo los nodos de hoja del árbol B+ almacenan claves y datos, y otros nodos internos solo almacenan claves.
Los nodos de hoja del árbol B son todos independientes; los nodos de hoja del árbol B+ tienen una cadena de referencia que apunta a sus nodos de hoja adyacentes.
El proceso de recuperación del árbol B es equivalente a realizar una búsqueda binaria de las palabras clave de cada nodo del rango, y la recuperación puede terminar antes de llegar al nodo hoja. La eficiencia de recuperación del árbol B+ es muy estable.Cualquier búsqueda es un proceso desde el nodo raíz hasta el nodo hoja, y la recuperación secuencial de los nodos hoja es obvia.

22. Índice de clave principal

La columna de clave principal de la tabla de datos utiliza el índice de clave principal, un índice único especial.

En la tabla InnoDB de MySQL, cuando no se muestra la clave principal de la tabla especificada, InnoDB verificará automáticamente si hay un índice único en la tabla y no permite campos con valores nulos. Si es así, seleccione este campo como la clave principal predeterminada. De lo contrario, InnoDB creará automáticamente una clave principal de incremento automático de 6 bytes.

23. Índice secundario

El índice secundario también se denomina índice auxiliar porque los datos almacenados en los nodos hoja del índice secundario son la clave principal. Es decir, a través del índice secundario se puede ubicar la posición de la clave primaria.

Los índices como los índices únicos, los índices ordinarios y los índices de prefijos son índices secundarios.

Índice único (clave única): un índice único también es una restricción. El valor de la columna de índice debe ser único, pero se permiten valores nulos; si es un índice compuesto , la combinación de valores de columna debe ser única. Una tabla permite crear múltiples índices únicos. La mayoría de las veces, el propósito de establecer un índice único es por la unicidad de los datos en la columna de atributo, no por la eficiencia de la consulta .
Índice ordinario (Índice): La única función de un índice ordinario es consultar datos rápidamente. Una tabla permite crear múltiples índices ordinarios, y se permite la duplicación de datos y NULL.
Índice de prefijo (Prefix): El índice de prefijo solo es aplicable a datos de tipo cadena . El índice de prefijo es para crear un índice para los primeros caracteres del texto , y los datos creados por el índice ordinario son más pequeños, porque solo se toman los primeros caracteres.
Índice compuesto: se refiere al índice creado en múltiples campos. El índice se usará solo cuando el primer campo cuando se crea el índice se usa en la condición de consulta. Cuando use un índice compuesto, siga el conjunto de prefijos más a la izquierda (descrito más adelante);
Índice de texto completo (Full Text): El índice de texto completo es principalmente para recuperar información de palabras clave en datos de texto grande, que es una tecnología utilizada actualmente por las bases de datos de los motores de búsqueda. Antes de Mysql 5.6, solo el motor MYISAM admitía la indexación de texto completo.Después de 5.6, InnoDB también admite la indexación de texto completo.

El índice de texto completo en MySQL tiene dos variables, la longitud mínima de búsqueda y la longitud máxima de búsqueda Las palabras cuya longitud es menor que la longitud mínima de búsqueda y mayor que la longitud máxima de búsqueda no serán indexadas.

24. Índice agrupado e índice no agrupado

Un índice agrupado es un índice en el que la estructura del índice y los datos se almacenan juntos, no en un tipo de índice separado. Los nodos de hoja del índice de clave principal de InnoDB almacenan filas de datos, por lo que pertenece al índice agrupado.

En MySQL, el archivo .ibd de la tabla del motor InnoDB contiene el índice y los datos de la tabla. Para la tabla del motor InnoDB, cada nodo que no sea hoja del índice (árbol B+) de la tabla almacena el índice y el nodo hoja almacena el índice Los datos correspondientes al índice.

Un índice no agrupado es un índice en el que la estructura del índice y los datos se almacenan por separado, no un tipo de índice separado. Los índices secundarios (índices auxiliares) son índices no agrupados. El motor MyISAM de MySQL, independientemente de la clave principal o no principal, utiliza índices no agrupados.

El índice auxiliar es un índice creado por nosotros. Sus nodos hoja almacenan la clave principal. Después de encontrar la clave principal a través del índice auxiliar, podemos volver a la tabla para encontrar el índice de clave principal a través de la clave principal que encontramos .

25. De vuelta a la mesa

Volver a la tabla es escanear la fila de datos en el árbol de índice a través del índice de la base de datos, obtener la identificación de la clave principal y luego obtener los datos en el número de índice de la clave principal a través de la identificación de la clave principal, es decir, la consulta basado en el índice de clave no primaria necesita escanear un árbol de índice adicional.

26. Índice de cobertura e índice conjunto

Si un índice contiene (o cubre) los valores de todos los campos que deben consultarse, lo llamamos "índice de cobertura". Significa que los datos que necesitamos se pueden consultar a través del índice, sin necesidad de consultar los datos en la tabla de datos (de vuelta a la tabla) según el índice, lo que reduce la operación io de la base de datos y mejora la eficiencia de la consulta.

El uso de varios campos en una tabla para crear un índice es un índice conjunto, también llamado índice compuesto o índice compuesto.

27. El principio de coincidencia del prefijo más a la izquierda

El principio de coincidencia de prefijos más a la izquierda significa que cuando se utiliza un índice conjunto, MySQL coincidirá con las condiciones de consulta de izquierda a derecha de acuerdo con el orden de los campos en el índice conjunto. Si hay un campo coincidente, utilizará este campo para filtrar un lote de datos hasta que todos los campos en el índice conjunto coincidan, o se encuentre una consulta de rango durante la ejecución, como >, <, entre y consultas similares que comiencen con %. dejarán de coincidir.

Por lo tanto, cuando usamos un índice conjunto, podemos colocar los campos altamente discriminatorios en el extremo izquierdo, lo que también puede filtrar más datos.

28. Índice empujar hacia abajo

Index Condition Pushdown (Index Condition Pushdown) es una función de optimización de índice proporcionada por MySQL versión 5.6.Durante el proceso de recorrido de índice no agrupado, primero puede juzgar los campos contenidos en el índice, filtrar registros no calificados y reducir los tiempos de retorno.

29. Conversión implícita

Cuando los operadores se utilizan con operandos de diferentes tipos, se produce una conversión de tipo para que los operandos sean compatibles. Algunas conversiones ocurren implícitamente. Por ejemplo, MySQL convierte automáticamente cadenas en números y viceversa, según sea necesario. Las siguientes reglas describen cómo se transforman las operaciones de comparación:

Cuando al menos uno de los dos parámetros es NULL, el resultado de la comparación también es NULL. En un caso especial, al usar <=> para comparar dos NULL, devolverá 1. En ambos casos, no se requiere conversión de tipo;
Ambos parámetros son cadenas y se compararán según cadenas sin conversión de tipo;
Ambos parámetros son enteros, comparados según enteros, sin conversión de tipos;
Al comparar valores hexadecimales con no números, se tratan como cadenas binarias;
Un parámetro es TIMESTAMP o DATETIME, y el otro parámetro es una constante, que se convertirá en marca de tiempo;
Un parámetro es de tipo decimal.Si el otro parámetro es decimal o entero, el entero se convertirá a decimal para la comparación.Si el otro parámetro es de coma flotante, el decimal se convertirá a coma flotante para la comparación;
En todos los demás casos, ambos argumentos se convierten en flotantes y se comparan;

30. ¿Cómo elegir el índice ordinario y el índice único?

Preguntar
- Cuando el índice normal es una condición, se escanearán los datos consultados hasta escanear toda la tabla;
- Cuando el índice único es la condición de consulta, los datos encontrados se devolverán directamente sin continuar escaneando la tabla;
renovar
- Los índices ordinarios actualizarán directamente la operación al búfer de cambios y luego finalizarán
- Un índice único necesita determinar si los datos entran en conflicto

Por lo tanto, los índices únicos son más adecuados para escenarios de consulta y los índices ordinarios son más adecuados para escenarios de inserción.

31. Evite la falla del índice

La falla del índice también es una de las principales razones de las consultas lentas. Las situaciones comunes que conducen a la falla del índice son las siguientes:

Consulta con SELECT *;
Se crea un índice compuesto, pero la condición de consulta no cumple con el principio de coincidencia más a la izquierda;
Realizar operaciones como cálculos, funciones y conversiones de tipos en columnas indexadas;
consultas LIKE que comienzan con %, como '%abc';
Si o se usa en la condición de consulta, y no hay índice en una columna en la condición previa y posterior de o, los índices involucrados no se usarán
Las columnas especificadas en la función match() deben ser exactamente las mismas que las especificadas en el índice de texto completo; de lo contrario, se informará de un error y no se podrá utilizar el índice de texto completo.
Preste atención a la longitud de la búsqueda cuando la indexación de texto completo haga que el índice falle

32. Reglas para la indexación

Campos que no son NULL: Los datos del campo índice no deben ser NULL en la medida de lo posible, ya que la base de datos es difícil de optimizar para campos cuyos datos son NULL. Si el campo se consulta con frecuencia pero no puede evitar ser NULL, se recomienda utilizar valores cortos o caracteres cortos con una semántica clara como 0,1,verdadero,falso como alternativa.
Campos consultados con frecuencia: Los campos que creamos índices deben ser campos consultados con frecuencia.
Campos consultados como condiciones: los campos consultados como condiciones DONDE deben considerarse para la indexación.
Campos que deben ordenarse con frecuencia: el índice se ha ordenado, por lo que la consulta puede usar la clasificación del índice para acelerar el tiempo de consulta de clasificación.
Campos que se utilizan con frecuencia para la conexión: Los campos que se utilizan con frecuencia para la conexión pueden ser algunas columnas de clave externa, para las columnas de clave externa no es necesario establecer una clave externa, solo que la columna involucre la relación entre tablas. Para los campos que se consultan con frecuencia mediante combinaciones, se puede considerar la indexación para mejorar la eficiencia de las consultas de combinación de varias tablas.
Los campos que se actualizan con frecuencia deben indexarse cuidadosamente;
Considere la posibilidad de crear índices conjuntos en lugar de índices de una sola columna tanto como sea posible;
Considere usar índices de prefijo en lugar de índices normales en campos de tipo cadena;
Elimine los índices que no se han utilizado durante mucho tiempo;

33. Características extremas de la transacción

Una cosa consta de n unidades, y estas n unidades tienen éxito al mismo tiempo o fallan al mismo tiempo durante la ejecución, lo que pone n unidades en una transacción. Permítanme darles un ejemplo simple: sin considerar si las preguntas del examen son correctas o no, un examen consta de varias preguntas. Las preguntas se entregan al profesor por separado, y el examen puede entenderse aquí como una transacción.

Las características de la transacción:

R: Atomicidad ( Atomicity), atomicidad significa que una transacción es una unidad de trabajo indivisible, y las operaciones en una transacción ocurren todas o no ocurren.
C: Consistencia ( Consistency), en una transacción, la integridad de los datos antes y después de la transacción debe ser consistente.
I: Aislamiento ( Isolation), que existe en múltiples transacciones. El aislamiento de transacciones significa que cuando múltiples usuarios acceden a la base de datos simultáneamente, las transacciones de un usuario no pueden ser interferidas por las transacciones de otros usuarios, y los datos entre múltiples transacciones simultáneas deben ser aislamiento mutuo.
D: Persistencia ( Durability), persistencia significa que una vez que se confirma una transacción, sus cambios en los datos de la base de datos son permanentes, y luego, incluso si la base de datos falla, no debería tener ningún impacto en ella.

34. Problemas causados por transacciones concurrentes

Lectura sucia: la transacción B lee datos que la transacción A no ha confirmado;
Modificación perdida (Lost to modify): cuando una transacción lee un dato, otra transacción también accede a los datos, luego, después de que los datos se modifican en la primera transacción, la segunda transacción también modifica los datos. De esta forma, los resultados de la modificación en la primera transacción se pierden, por lo que se denomina modificación perdida.
Lectura irrepetible: la transacción B lee los datos enviados por la transacción A, es decir, los datos leídos por la transacción B antes y después de que se confirme la transacción A son inconsistentes (las transacciones A y B operan en el mismo dato) 内容;
Lectura fantasma/lectura virtual: la transacción B lee los datos enviados por la transacción A, es decir, la transacción A realiza una operación de inserción y los datos leídos por la transacción B antes y después de la transacción A son inconsistentes 数量.

35. Nivel de aislamiento de transacciones

Para resolver los problemas de concurrencia causados por el aislamiento anterior, la base de datos proporciona un mecanismo de aislamiento de transacciones.

read uncommitted (lectura no confirmada): Cuando una transacción no ha sido comprometida, los cambios que realiza pueden ser vistos por otras transacciones, leyendo datos no comprometidos, cuyo problema no se puede resolver;
lectura confirmada (lectura confirmada): después de confirmar una transacción, otras transacciones verán los cambios que realice. Leer los datos confirmados puede resolver las lecturas sucias: valor predeterminado de Oracle;
Lectura repetible (repetible read): Los datos vistos durante la ejecución de una transacción siempre son consistentes con los datos vistos al inicio de la transacción, lo que puede resolver lecturas sucias y lecturas no repetibles --- mysql default;
serializable (serialización): como su nombre lo indica, para la misma fila de registros, "escribir" agregará "bloqueo de escritura" y "leer" agregará "bloqueo de lectura". Cuando se produce un conflicto de bloqueo de lectura y escritura, la transacción a la que se accede más tarde debe esperar a que se complete la transacción anterior antes de continuar con la ejecución. Las lecturas sucias, las lecturas no repetibles y las lecturas fantasma se pueden resolver, lo que equivale a bloquear tablas.

Aunque el nivel serializable puede resolver todos los problemas de simultaneidad de la base de datos, bloqueará cada fila de lectura de datos, lo que puede provocar muchos problemas de tiempo de espera y competencia de bloqueo, lo que resulta en una disminución de la eficiencia. Por lo tanto, rara vez usamos serializable en aplicaciones prácticas. Solo cuando es muy necesario para garantizar la consistencia de los datos y no puede aceptar concurrencia, debemos considerar adoptar este nivel.

36, MVCC

Si la granularidad del bloqueo es demasiado grande, el rendimiento disminuirá.Existe un método MVCC con mejor rendimiento bajo el motor InnoDB de MySQL.

MVCC es Multi-Version Concurremt Controlla abreviatura de MVCC, que significa protocolo de control de concurrencia de múltiples versiones, que evita la competencia de los mismos datos entre diferentes transacciones a través del número de versión . Es principalmente para mejorar el rendimiento de lectura y escritura simultánea de la base de datos, permitiendo que múltiples transacciones lean y escriban simultáneamente sin bloqueo.

La implementación de MVCC se basa en columnas ocultas, registro de deshacer, vista de lectura .

De la introducción anterior a los cuatro niveles de aislamiento definidos por el estándar SQL, se puede ver que en la definición del nivel de aislamiento SQL estándar, REPEATABLE-READ (lectura repetible) no puede evitar la lectura fantasma .

Sin embargo, el nivel de aislamiento REPEATABLE-READ implementado por InnoDB puede resolver el problema de la lectura fantasma, principalmente en las siguientes dos situaciones:

Lectura instantánea: el mecanismo MVCC garantiza que no se produzcan lecturas fantasma.
Lectura actual: utilice el bloqueo de tecla siguiente (bloqueo de tecla de proximidad) para bloquear y asegurarse de que no se produzca una lectura fantasma. El bloqueo de tecla siguiente es una combinación de bloqueo de fila (bloqueo de registro) y bloqueo de espacio (bloqueo de espacio). El bloqueo de fila solo puede bloquear las filas existentes, para evitar la inserción de nuevas filas, debe confiar en los bloqueos de espacio.

El motor de almacenamiento InnoDB generalmente utiliza el nivel de aislamiento SERIALIZABLE en el caso de transacciones distribuidas.

37. Bloqueos en Mysql

Los bloqueos se pueden dividir en bloqueos de lectura y bloqueos de escritura si se dividen en tipos de operación.El concepto de bloqueos de lectura-escritura mencionado aquí es similar al de nuestro Java, que puede entenderse como bloqueos compartidos y bloqueos exclusivos. En términos de granularidad, se puede dividir en bloqueos de fila, bloqueos de página y bloqueos de tabla. Por lo general, usamos más bloqueos de fila y bloqueos de tabla. Lo que se menciona aquí se refiere principalmente al tamaño del alcance del bloqueo, y el tamaño del alcance del bloqueo También afecta directamente el grado de concurrencia. El grado de concurrencia del bloqueo de filas es el más alto, pero su costo de bloqueo es muy común en el motor Innodb. El costo de bloqueo del bloqueo de tablas es bajo, pero el rango de bloqueo también es grande y la concurrencia es la más baja. Es común en el motor MySIAM De acuerdo con las características de lectura - Compartidas, MySIAM es adecuado para escenarios de consulta sesgada.

Sabemos que los bloqueos y los niveles de transacción se utilizan realmente para resolver escenarios de concurrencia. La comprensión de los niveles de transacción se puede entender con la ayuda de los registros de rehacer y deshacer. Entonces, ¿cuál es la relación entre ellos y los bloqueos? La gente entiende que el mecanismo de bloqueo es principalmente un control de granularidad gruesa, pero la lectura y escritura de datos no es exitosa a la vez debido a la existencia de la estructura de almacenamiento, lo que da como resultado esas lecturas sucias, escrituras sucias y errores no repetibles. Los problemas de lectura y lectura fantasma, y las soluciones a estos problemas se realizan mediante el mecanismo MVVC.

38. Proceso de ejecución de declaraciones de consulta

select * from tb_student  s where s.age='18' and s.name=' 张三 ';

Primero verifique si la declaración tiene permiso. Si no hay permiso, se devolverá un mensaje de error directamente. Si hay permiso, antes de la versión MySQL8.0, primero consultará el caché y usará esta declaración SQL como clave para consulta si hay un resultado en la memoria.Si es así, directamente en caché, si no, vaya al siguiente paso.
Realice un análisis léxico a través del analizador para extraer los elementos clave de la declaración SQL. Por ejemplo, la declaración anterior se extrae como una selección de consulta, y el nombre de la tabla que se consultará es tb_student, y todas las columnas deben consultarse. la condición de consulta es el id='1' de esta tabla. Luego, juzgue si la declaración SQL tiene errores gramaticales, como si las palabras clave son correctas, etc. Si no hay ningún problema en la verificación, vaya al siguiente paso.
El siguiente paso es que el optimizador determine el plan de ejecución.La instrucción SQL anterior puede tener dos planes de ejecución:
- a. Primero consulte al estudiante cuyo nombre es "Zhang San" en la tabla de estudiantes y luego determine si la edad es 18.
- B. Primero busque a los estudiantes que tienen 18 años entre los estudiantes y luego consulte a los estudiantes cuyo nombre es "Zhang San". Luego, el optimizador elige una solución con la mejor eficiencia de ejecución de acuerdo con su propio algoritmo de optimización (el optimizador cree que a veces no es necesariamente la mejor). Luego, después de confirmar el plan de ejecución, está listo para comenzar la ejecución.
Realice la verificación de permisos, si no hay permiso, se devolverá un mensaje de error, si hay permiso, se llamará a la interfaz del motor de base de datos y se devolverá el resultado de ejecución del motor.

El proceso de ejecución de la declaración de consulta es el siguiente: verificación de permisos (si llega a la caché) ---> caché de consultas ---> analizador ---> optimizador ---> verificación de permisos ---> ejecutor --- > motor

39. Actualizar el proceso de ejecución de sentencias

update tb_student A set A.age='19' where A.name=' 张三 ';

Esta declaración seguirá básicamente el flujo de la consulta anterior, excepto que necesita registrar el registro al ejecutar la actualización, lo que introducirá el módulo de registro. El módulo de registro que viene con MySQL es binlog (registro de archivo) y todo el almacenamiento. Se pueden usar motores. Nuestro motor InnoDB de uso común también viene con un módulo de registro redo log (redo log). Discutiremos el proceso de ejecución de esta declaración en modo InnoDB.

Primero consulte los datos de Zhang San, si hay un caché, también usará el caché.

Luego obtenga la declaración de consulta y cambie la edad a 19, y luego llame a la interfaz API del motor para escribir esta línea de datos. El motor InnoDB guarda los datos en la memoria y registra el registro de rehacer al mismo tiempo. En este momento, el redo log ingresa al estado de preparación y luego le dice al ejecutor que complete la ejecución que se puede enviar en cualquier momento.

Después de que el ejecutor recibe la notificación, registra el binlog, luego llama a la interfaz del motor y envía el registro de rehacer como estado de envío.

actualización completada.

El flujo de ejecución de la sentencia de actualización es el siguiente: analizador---->verificación de permisos---->ejecutor--->motor---redo log(preparar estado)--->binlog--->redo log (estado de compromiso)

40. Optimización SQL

Deben evitarse, en la medida de lo posible, las exploraciones completas de la tabla, y primero deben considerarse los índices en las columnas involucradas en dónde y ordenar por;

Trate de evitar el uso de las siguientes declaraciones en la cláusula where, de lo contrario, el motor dejará de usar el índice y realizará un escaneo completo de la tabla;

Para juzgar el valor nulo del campo,

Usa != o <>

o para conectar condiciones (use union all en su lugar)

in y not in también deben usarse con precaución

No utilice consultas difusas (indexación de texto completo disponible)

Reducir las operaciones de expresión

operación de función

No use select * from t en ninguna parte, reemplace "*" con una lista de campos específica y no devuelva ningún campo que no se use;

Es mejor no tener más de 6 índices en una tabla, si hay demasiados, debe considerar si es necesario construir índices en algunas columnas que no se usan con frecuencia;

En muchos casos, es una buena elección usar exist en lugar de in;

Minimice las consultas conjuntas de varias tablas;

optimización de paginación;

Utilice los índices correctamente;

41. Datos de sincronización maestro-esclavo

imagen

maestro La biblioteca principal escribe el tipo de evento de esta actualización en el archivo binlog de la biblioteca principal

El maestro crea un subproceso de volcado de registro para notificar al esclavo que los datos deben actualizarse

El esclavo envía una solicitud al nodo maestro y guarda el contenido del archivo binlog en el registro de retransmisión local.

El esclavo inicia el subproceso sql para leer el contenido en el registro de retransmisión y vuelve a ejecutar el contenido localmente para completar la sincronización de datos maestro-esclavo.

Estrategia de sincronización :

Replicación sincrónica completa : la biblioteca maestra sincroniza a la fuerza los registros con la biblioteca esclava y regresa al cliente después de que se ejecutan todas las bibliotecas esclavas, lo que tiene un rendimiento deficiente;

Replicación semisíncrona : la biblioteca maestra considera que la operación fue exitosa cuando recibe al menos una confirmación de la biblioteca esclava, y la biblioteca esclava escribe en el registro con éxito y devuelve una confirmación de acuse de recibo;

42. Cómo solucionar el retraso maestro-esclavo

Después de MySQL 5.6, se proporciona un método de replicación en paralelo , que se reproduce convirtiendo subprocesos de SQL en varios subprocesos de trabajo.

Mejorar la configuración de la máquina (manera real)

Elija la estrategia adecuada de subbase de datos y subtabla al comienzo del negocio para evitar la presión adicional de copiar causada por la gran base de datos de un solo formulario.

evitar transacciones largas

Evite permitir que la base de datos realice varias operaciones a gran escala

Para algunas empresas sensibles a los retrasos, use directamente la biblioteca principal para leer

43. ¿Por qué no usar transacciones largas?

En el caso de la concurrencia, el conjunto de conexiones de la base de datos es fácil de explotar

Es fácil causar muchos bloqueos y tiempos de espera de bloqueo , las transacciones largas también ocupan recursos de bloqueo y también pueden arrastrar hacia abajo toda la biblioteca.

Largo tiempo de ejecución, fácil de causar retraso maestro-esclavo

El tiempo requerido para la reversión es relativamente largo , y cuanto más larga sea la transacción, más transacciones en todo el período de tiempo

El registro de deshacer registro es cada vez más grande y las transacciones largas significan que habrá vistas de transacciones muy antiguas en el sistema. Dado que estas transacciones pueden acceder a cualquier dato en la base de datos en cualquier momento, antes de que se confirme la transacción, se deben mantener los registros de reversión que pueda usar en la base de datos, lo que dará como resultado que se ocupe una gran cantidad de espacio de almacenamiento.