Entrevista - Puntos destacados de las preguntas y respuestas de MySQL

1. Arquitectura de la base de datos

1.1 Hablar sobre el diagrama de infraestructura de MySQL

Cuéntale al entrevistador sobre la arquitectura lógica de MySQL. Si tienes una pizarra, puedes hacer el siguiente dibujo. El dibujo proviene de Internet.

El diagrama de arquitectura lógica de Mysql se divide principalmente en tres capas:

(1) La primera capa es responsable del procesamiento de la conexión, autorización y autenticación, seguridad, etc. 

(2) La segunda capa es responsable de compilar y optimizar SQL 

(3) La tercera capa es el motor de almacenamiento.

1.2 ¿Cómo se ejecuta una consulta SQL en MySQL?

• Verifique primero la declaración 是否有权限. Si no hay permiso, se devolverá un mensaje de error directamente. Si hay permiso, se consultará primero el caché (antes de MySQL 8.0).

• Si no hay caché, el analizador 词法分析extraerá elementos clave, como seleccionar en la instrucción sql, y luego juzgará si la instrucción sql tiene errores de sintaxis, como si las palabras clave son correctas, etc.

• Finalmente, el optimizador determina el plan de ejecución para la verificación de permisos, si no hay permiso, devolverá directamente un mensaje de error, si tiene permiso 调用数据库引擎接口, devolverá el resultado de la ejecución.

2. Optimización SQL

2.1 ¿Cómo optimiza SQL en su trabajo diario?

Esta pregunta se puede responder desde las siguientes dimensiones:

2.1.1, optimizar la estructura de la tabla

(1) Intenta usar campos numéricos

Si los campos que contienen solo información numérica no deben diseñarse como tipo de carácter, esto reducirá el rendimiento de la consulta y la conexión, y aumentará el costo de almacenamiento. Esto se debe a que el motor compara cada carácter de la cadena uno por uno al procesar consultas y uniones, mientras que solo se requiere una comparación para los números.

(2) Use varchar en lugar de char tanto como sea posible

Los campos de longitud variable tienen poco espacio de almacenamiento y pueden ahorrar espacio de almacenamiento.

(3) Cuando la columna de índice tiene una gran cantidad de datos duplicados, el índice se puede eliminar

Por ejemplo, hay una columna de género, casi solo masculino, femenino, desconocido, dicho índice no es válido.

2.1.2 Optimización de la consulta

• Debe intentar evitar el uso de los operadores != o <> en las cláusulas where

• Debe intentar evitar el uso o unir condiciones en cláusulas where

• No aparecer selecciona * para cualquier consulta

• Evite valores nulos para campos en cláusulas where

2.1.3, optimización de índice

• Indexe los campos utilizados como condiciones de consulta y ordene por

• Evite crear demasiados índices y use más índices compuestos

2.2 ¿Cómo leer el plan de ejecución (explicar) y cómo entender el significado de cada campo?

Agregar la palabra clave de explicación antes de la declaración de selección devolverá la información del plan de ejecución.

(1) columna id: es el número de serie de la declaración de selección MySQL divide la consulta de selección en consulta simple y consulta compleja.

(2) columna select_type: Indica si la fila correspondiente es una consulta simple o compleja.

(3) columna de la tabla: a qué tabla se accede mediante una fila de explicación.

(4) tipo de columna: una de las columnas más importantes. Representa un tipo de asociación o tipo de acceso, que es cómo MySQL decide cómo buscar filas en una tabla. De mejor a peor: system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

(5) Columna de claves_posibles: Muestra qué índices puede usar la consulta para encontrar.

(6) columna clave: esta columna muestra qué índice mysql realmente usa para optimizar el acceso a la tabla.

(7) columna key_len: muestra el número de bytes utilizados por mysql en el índice, a través de este valor se puede calcular qué columnas del índice se utilizan.

(8) columna ref: Esta columna muestra la columna o constante utilizada en la tabla de valor de búsqueda en el índice del registro de la columna clave, las comunes son: const (constante), func, NULL, nombre de campo.

(9) columna de filas: esta columna es el número de filas que MySQL estima que se leerán y detectarán. Tenga en cuenta que este no es el número de filas en el conjunto de resultados.

(10) Columna adicional: muestra información adicional. Por ejemplo, están Usar índice, Usar dónde, Usar temporal, etc.

2.3 ¿Alguna vez se ha preocupado por el sql que consume mucho tiempo en el sistema empresarial? ¿Las estadísticas son demasiado lentas para las consultas? ¿Cómo optimizar la consulta lenta?

Cuando solemos escribir Sql, debemos desarrollar el hábito de usar el análisis de explicación. Las estadísticas de consulta lenta, operación y mantenimiento se contarán regularmente para nosotros.

Optimización de ideas de consultas lentas:

• Declaración de análisis, si se cargan campos/datos innecesarios

• Analice la sentencia de ejecución de SQL, si llega al índice, etc.

• Si el SQL es complejo, optimizar la estructura SQL

• Si la cantidad de datos en la tabla es demasiado grande, considere dividir la tabla

3. Índice

3.1, la diferencia entre un índice agrupado y un índice no agrupado

Se puede responder en las siguientes cuatro dimensiones:

(1) Una tabla solo puede tener un índice agrupado y una tabla puede tener varios índices no agrupados.

(2) Para un índice agrupado, el orden lógico de los valores clave en el índice determina el orden físico de las filas correspondientes en la tabla; para un índice no agrupado, el orden lógico de los índices en el índice es diferente del orden de almacenamiento físico de las filas del disco.

(3) El índice se describe mediante la estructura de datos del árbol binario.Podemos entender el índice agrupado de esta manera: el nodo hoja del índice es el nodo de datos. El nodo hoja de un índice no agrupado sigue siendo un nodo de índice, pero hay un puntero al bloque de datos correspondiente.

(4) Índice agrupado: el almacenamiento físico se ordena por índice, índice no agrupado: el almacenamiento físico no se ordena por índice;

3.2 ¿Por qué usar el árbol B+, por qué no usar el árbol binario ordinario?

Esta pregunta se puede ver desde varias dimensiones, si la consulta es lo suficientemente rápida, si la eficiencia es estable, cuántos datos se almacenan y la cantidad de búsquedas en el disco, por qué no es un árbol binario ordinario, por qué no es un árbol equilibrado. árbol binario, ¿por qué no es un árbol B, sino un árbol B+?

3.2.1 ¿Por qué no es un árbol binario ordinario?

Si el árbol binario está especializado como una lista enlazada, es equivalente a una exploración de tabla completa. En comparación con el árbol de búsqueda binario, el árbol binario equilibrado tiene una eficiencia de búsqueda más estable y una velocidad de búsqueda general más rápida.

3.2.2 ¿Por qué no un árbol binario balanceado?

Sabemos que la eficiencia de las consultas es mucho más rápida para los datos en la memoria que en el disco. Si la estructura de datos del árbol se usa como índice, entonces necesitamos leer un nodo del disco cada vez que buscamos datos, que es lo que llamamos un bloque de disco, pero un árbol binario balanceado solo puede almacenar un valor clave y datos. por nodo, si se trata de un árbol B, se pueden almacenar más datos de nodo y se reducirá la altura del árbol, por lo que se reducirá la cantidad de lecturas de disco y la eficiencia de las consultas será más rápida.

3.2.3 ¿Por qué no es un árbol B sino un árbol B+?

No se almacenan datos en los nodos que no son hojas del árbol B+, solo se almacena el valor clave, mientras que el nodo del árbol B no solo almacena el valor clave, sino que también almacena los datos. El tamaño predeterminado de una página en innodb es de 16 Kb. Si no se almacenan datos, se almacenarán más valores clave, el orden del árbol correspondiente (el árbol de nodos secundarios de un nodo) será más grande y el árbol será más corto y más gordo De esta manera, la cantidad de IO para el disco IO para encontrar datos se reducirá nuevamente, y la eficiencia de la consulta de datos será más rápida.

Todos los datos del índice del árbol B+ se almacenan en los nodos hoja, y los datos se organizan en orden, y la lista vinculada está conectada. Luego, el árbol B+ hace que la búsqueda por rango, la búsqueda por clasificación, la búsqueda por grupos y la búsqueda por deduplicación sean extremadamente fáciles.

3.3 ¿Cuál es la diferencia entre el índice Hash y el índice de árbol B+? ¿Cómo elegisteis a la hora de diseñar el índice?

• Los árboles B+ pueden realizar consultas de rango, pero los índices hash no.

• El árbol B+ admite el principio más a la izquierda del índice conjunto, el índice Hash no lo admite.

• El árbol B+ admite el orden por clasificación, pero el índice Hash no.

• Los índices hash son más eficientes que los árboles B+ para consultas de igualdad.

• Cuando el árbol B+ usa Me gusta para realizar una consulta aproximada, las palabras detrás de Me gusta (por ejemplo, comenzando con %) pueden desempeñar un papel de optimización, y el índice Hash no puede realizar ninguna consulta aproximada.

3.4 ¿Cuál es el principio del prefijo más a la izquierda? ¿Cuál es el principio de coincidencia más a la izquierda?

El principio del prefijo más a la izquierda es el primero más a la izquierda. Al crear un índice de varias columnas, de acuerdo con los requisitos comerciales, la columna utilizada con más frecuencia en la cláusula where se coloca en el extremo izquierdo.

Cuando creamos un índice combinado, como (a1, a2, a3), es equivalente a crear tres índices (a1), (a1, a2) y (a1, a2, a3), que es el principio de coincidencia más a la izquierda.

3.5 ¿Para qué escenarios no son adecuados los índices?

• No apto para la indexación con una pequeña cantidad de datos

• Las actualizaciones frecuentes no son adecuadas para la indexación = Los campos con poca discriminación no son adecuados para la indexación (como el género)

3.6 ¿Cuáles son las ventajas y desventajas de los índices?

(1) ventajas:

• Un índice único puede garantizar la unicidad de cada fila de datos en una tabla de base de datos

• Los índices pueden acelerar las consultas de datos y reducir el tiempo de consulta

(2) Desventajas:

• Crear y mantener índices lleva tiempo

• El índice necesita ocupar espacio físico Además del espacio de datos ocupado por la tabla de datos, cada índice también ocupa una cierta cantidad de espacio físico.

• Al agregar, eliminar y modificar los datos en la tabla, el índice también debe mantenerse dinámicamente.

4. Bloquear

4.1 ¿Se ha encontrado MySQL con un problema de interbloqueo y cómo lo resolvió?

encontrado. Mis pasos generales para solucionar los puntos muertos son salsa púrpura:

(1) Ver el estado innodb del motor de la demostración del registro del interbloqueo;

(2) Descubra el punto muerto Sql

(3) Analizar la situación de bloqueo de sql

(4) Simular un incidente de interbloqueo

(5) Analizar registros de interbloqueo

(6) Análisis de resultados de punto muerto

4.2 ¿Cuáles son los bloqueos optimistas y los bloqueos pesimistas de la base de datos y sus diferencias?

(1) Cerradura pesimista:

El candado pesimista es obstinado e inseguro. Su corazón solo pertenece a la transacción actual, y siempre está preocupada de que sus amados datos puedan ser modificados por otras transacciones, por lo que después de que una transacción haya (adquirido) un candado pesimista, cualquier otra transacción no puede modificar los datos y solo puede esperar a que se libere el bloqueo.

(2) Bloqueo optimista:

El "optimismo" del bloqueo optimista se refleja en la creencia de que los cambios de datos no serán demasiado frecuentes. Por lo tanto, permite múltiples transacciones para realizar cambios en los datos al mismo tiempo.

Método de implementación: los bloqueos optimistas generalmente se implementan mediante el mecanismo del número de versión o el algoritmo CAS.

4.3 ¿Está familiarizado con MVCC y sus principios subyacentes?

MVCC (Control de concurrencia multiversión), la tecnología de control de concurrencia multiversión.

La implementación de MVCC en MySQL InnoDB es principalmente para mejorar el rendimiento concurrente de la base de datos y para manejar mejor los conflictos de lectura y escritura, de modo que incluso cuando hay un conflicto de lectura y escritura, puede lograr no bloquear y no -Bloqueo de lectura concurrente.

5. Asuntos

5.1 Cuatro características de las transacciones MySQL y sus principios de implementación

• Atomicidad: la transacción se ejecuta como un todo, y se ejecutan todas o ninguna de las operaciones en la base de datos contenida en ella.

• Coherencia: significa que los datos no se destruirán antes de que comience la transacción y después de que finalice. Si la cuenta A transfiere 10 yuanes a la cuenta B, la cantidad total de A y B sigue siendo la misma independientemente de si tiene éxito o no.

• Aislamiento: cuando varias transacciones acceden al mismo tiempo, las transacciones se aíslan entre sí, es decir, una transacción no afecta el efecto de ejecución de otras transacciones. En resumen, significa que no hay agua de río entre asuntos.

• Persistencia: una vez completada la transacción, los cambios operativos realizados por la transacción en la base de datos se mantendrán en la base de datos.

5.2 ¿Cuáles son los niveles de aislamiento de las transacciones? ¿Cuál es el nivel de aislamiento predeterminado de MySQL?

• Leer sin confirmar

• Lectura comprometida

• Lectura repetible

• Serializable

El nivel de aislamiento de transacciones predeterminado de Mysql es Lectura repetible

5.3 ¿Qué son las lecturas fantasma, las lecturas sucias y las lecturas no repetibles?

Las transacciones A y B se ejecutan alternativamente, y la transacción A es perturbada por la transacción B, porque la transacción A lee los datos no confirmados de la transacción B, que es una lectura sucia.

Dentro del alcance de una transacción, dos consultas idénticas leen el mismo registro pero devuelven datos diferentes, que son lecturas no repetibles.

La transacción A consulta un rango de conjuntos de resultados, otra transacción B simultánea inserta/elimina datos en este rango y los confirma en silencio, y luego la transacción A consulta el mismo rango nuevamente, y los conjuntos de resultados obtenidos por las dos lecturas son diferentes, esto es fantasma leyendo.

6. Combate real

6.1 ¿Qué debo hacer si la CPU de la base de datos MySQL se dispara?

Proceso de investigación:

(1) Use el comando superior para observar y determinar si es causado por mysqld u otras razones.

(2) Si es causado por mysqld, muestre la lista de procesos, verifique el estado de la sesión y determine si hay sql que consume recursos en ejecución.

(3) Averigüe el sql con alto consumo y vea si el plan de ejecución es preciso, si falta el índice y si la cantidad de datos es demasiado grande.

tratar con:

(1) Elimine estos subprocesos (y observe si el uso de la CPU disminuye)

(2) Realice los ajustes correspondientes (como agregar índices, cambiar sql y cambiar parámetros de memoria)

(3) Vuelva a ejecutar estos SQL.

Otras situaciones:

También es posible que cada SQL no consuma muchos recursos, pero de repente se conectan una gran cantidad de sesiones para hacer que la CPU se dispare, en este caso hay que analizar por qué la cantidad de conexiones aumenta con la aplicación. , y luego haga los ajustes correspondientes. Por ejemplo, limite el número de conexiones, etc.

6.2 ¿Cómo solucionas el retraso maestro-esclavo de MYSQL?

La replicación maestro-esclavo se divide en cinco pasos: (la imagen proviene de la red)

• Paso 1: Los eventos de actualización (actualizar, insertar, eliminar) de la biblioteca principal se escriben en binlog

• Paso 2: Inicie una conexión desde la biblioteca y conéctese a la biblioteca principal.

• Paso 3: en este momento, la biblioteca principal crea un subproceso de volcado binlog y envía el contenido del binlog a la biblioteca esclava.

• Paso 4: después de iniciar la biblioteca esclava, cree un subproceso de E/S, lea el contenido del binlog de la biblioteca principal y escríbalo en el registro de retransmisión

• Paso 5: También se creará un subproceso SQL para leer el contenido del registro de retransmisión, ejecutar el evento de actualización de lectura desde la posición Exec_Master_Log_Pos y escribir el contenido actualizado en la base de datos del esclavo.

Causas del retraso de sincronización maestro-esclavo

Un servidor abre N enlaces para que el cliente se conecte, por lo que habrá grandes operaciones de actualización simultáneas, pero solo hay un hilo que lee el binlog del servidor.Cuando un determinado SQL se ejecuta en el servidor esclavo durante más tiempo o porque un determinado SQL necesita bloquear la tabla, habrá una gran acumulación de SQL en el servidor maestro, que no está sincronizado con el servidor esclavo. Esto conduce a una incoherencia maestro-esclavo, es decir, un retraso maestro-esclavo.

Solución de retardo de sincronización maestro-esclavo

• El servidor maestro es responsable de la operación de actualización y tiene mayores requisitos de seguridad que el servidor esclavo, por lo que se pueden modificar algunos parámetros de configuración, como sync_binlog=1, innodb_flush_log_at_trx_commit=1 y otras configuraciones.

• Elija un mejor dispositivo de hardware como esclavo.

• Si se utiliza un servidor esclavo como respaldo en lugar de proporcionar consultas, su carga se reducirá y la eficiencia de ejecutar el SQL en el registro de retransmisión será naturalmente alta.

• El propósito de aumentar el servidor esclavo es distribuir la presión de lectura, reduciendo así la carga del servidor.

6.3 Si te pidieran que hicieras el diseño de sub-bibliotecas y sub-mesas, ¿qué harías?

Esquema de sub-biblioteca y sub-tabla:

• Sub-biblioteca horizontal: según el campo, según una determinada estrategia (hash, rango, etc.), los datos de una biblioteca se dividen en varias bibliotecas.

• División horizontal de tablas: en función de los campos, de acuerdo con ciertas estrategias (hash, rango, etc.), los datos de una tabla se dividen en varias tablas.

• Subbiblioteca vertical: según la tabla, las diferentes tablas se dividen en diferentes bibliotecas según la propiedad comercial.

• División vertical de tablas: según el campo, los campos de la tabla se dividen en diferentes tablas (tabla principal y tabla de extensión) según la actividad del campo.

Middleware de subtabla y subbase de datos de uso común:

• fragmentación-jdbc

• Mi gato

Problemas que pueden surgir en la subbiblioteca y la subtabla

• Problema de transacción: necesidad de usar transacciones distribuidas

• El problema de la combinación de nodos cruzados: para resolver este problema, se puede implementar en dos consultas

• Problemas de recuento de nodos cruzados, orden por, agrupar por y función de agregación: combine los resultados en el lado de la aplicación después de obtener los resultados en cada nodo.

• Migración de datos, planificación de capacidad, expansión de capacidad, etc.

• Problema de ID: después de dividir la base de datos, ya no puede confiar en el propio mecanismo de generación de claves principales de la base de datos.

• Problemas de ordenación y paginación en fragmentos