Explorando la arquitectura subyacente de MySQL: una descripción general del proceso de diseño e implementación

Todavía se requieren Me gusta, en caso de que haya un chico guapo frente a la pantalla, ¡simplemente dale me gusta! ! ! !

Autor: Mr. Raymon en Source Code Times

decir de frente

Mysql, como un excelente y ampliamente utilizado sistema de administración de bases de datos, es casi una parte indispensable del desarrollo diario para muchos ingenieros de Java. Ya sea que esté almacenando datos masivos o recuperando y administrando datos de manera eficiente, Mysql juega un papel importante. Sin embargo, además de usar Mysql para el desarrollo diario, ¿realmente entendemos su arquitectura subyacente y el proceso de diseño e implementación? Este blog lo llevará a una exploración profunda del proceso de diseño e implementación de la arquitectura subyacente de Mysql, ayudándolo a comprender y aplicar mejor este poderoso sistema de base de datos. Descubramos juntos el misterio de la capa inferior de Mysql y exploremos sus misterios.

1. ¿Cómo se ve Mysql en tus ojos?

MySQL, a los ojos de la mayoría de los ingenieros de Java comunes, a menudo se ve como una herramienta para almacenar y manipular datos. A menudo lo usamos para crear bases de datos, crear tablas e índices, para agregar, eliminar, modificar y consultar datos. Estos métodos básicos de uso se han convertido en operaciones rutinarias cuando tratamos con MySQL en nuestro trabajo diario. (Como la imagen de abajo)

Sin embargo, en el desarrollo diario, a menudo solo nos enfocamos en cómo usar MySQL correctamente para las operaciones de datos y rara vez tenemos un conocimiento profundo de la arquitectura subyacente y los principios de implementación de MySQL. Es posible que sepamos poco sobre los mecanismos subyacentes, como los motores de almacenamiento, los optimizadores de consultas y la gestión de transacciones, y que tengamos un conocimiento limitado sobre cómo optimizar el rendimiento, garantizar la coherencia de los datos y realizar copias de seguridad y recuperación.
Debido a esto, es muy importante para nosotros comprender el proceso de diseño e implementación de la arquitectura subyacente de MySQL. No solo puede ayudarnos a comprender mejor el mecanismo interno de MySQL, sino también a mejorar la eficiencia y la calidad de nuestro trabajo. En el siguiente contenido, analizaremos en profundidad los diversos componentes y tecnologías de la arquitectura subyacente de MySQL, con la esperanza de brindarle un conocimiento más profundo y completo de MySQL. Desvelemos el velo subyacente de MySQL y exploremos sus misterios

2. ¿Cómo se conecta el sistema Java a Mysql?

En Java, conectarse a una base de datos MySQL generalmente requiere JDBC (conectividad de base de datos de Java). JDBC es un conjunto de APIs proporcionadas por Java para acceder a bases de datos, proporciona una interfaz estándar que nos permite interactuar con varias bases de datos a través de código Java.

Para conectarse a la base de datos MySQL, primero debe asegurarse de que la base de datos MySQL se haya instalado en el sistema y que el controlador JDBC de MySQL apropiado se haya importado al proyecto Java. El controlador Mysql construye un puente entre el sistema Java y la base de datos Msyql para nosotros:

Por lo tanto, cuando estamos implementando código de negocios, si necesitamos ejecutar sentencias SQL relacionadas, el controlador Mysql puede ayudarnos a pasar las sentencias SQL a la base de datos Mysql para su ejecución: Entonces pensemos en una pregunta, ¿puede un sistema Java solo seguir las instrucciones

? la base de datos establecer una conexión? Esto definitivamente no es posible, porque necesitamos entender una verdad. Supongamos que desarrollamos un sistema web en Java y lo implementamos en Tomcat, entonces Tomcat debe tener varios subprocesos para procesar varias solicitudes al mismo tiempo. Veamos la imagen a continuación: Por lo tanto

, cuando hay varias solicitudes comerciales, podemos establecer una conexión de base de datos para cada solicitud para uso independiente, de la siguiente manera: Pero
en un escenario de alta concurrencia, si cada subproceso de Tomcat accede a la base de datos, ¿es posible conectarse a una base de datos, ejecutar un declaración SQL, y luego destruir la conexión? Puede haber cientos de subprocesos que realizan este proceso con frecuencia. Este enfoque no es recomendable. Lleva tiempo establecer una conexión con la base de datos cada vez. Cuando se establece la conexión y se ejecuta la instrucción SQL, la conexión se destruye y se restablece. Esto es muy ineficiente.

Por lo tanto, necesitamos introducir el concepto de grupo de conexiones para resolver este problema. El grupo de conexiones mantiene un conjunto de conexiones de base de datos reutilizables y administra las conexiones de manera eficiente. Cuando el subproceso de Tomcat necesita acceder a la base de datos, puede obtener una conexión disponible del grupo de conexiones y devolver la conexión al grupo de conexiones después de la ejecución. Esto puede reducir la creación y destrucción frecuente de conexiones y mejorar el rendimiento. Como sigue:

3. ¿Por qué Mysql también necesita un grupo de conexiones?

¿Sabes que cuando vas al banco a hacer negocios, a veces tienes que hacer cola? Sería una pérdida de tiempo y recursos suponer que todos deben esperar a que el personal del banco haga el negocio por ellos, ¿verdad? El conjunto de conexiones de MySQL es como un sistema de cola para transacciones bancarias, lo que nos ayuda a administrar y utilizar las conexiones de la base de datos de manera más efectiva.

1. Mejore la eficiencia de la conexión: en MySQL, se requiere un trabajo preparatorio para establecer una conexión a la base de datos, al igual que el personal del banco debe hacer algunos preparativos antes de manejar el negocio. Si la conexión se vuelve a crear cada vez, será muy ineficiente, al igual que todos tienen que ir al banco a hacer cola para obtener un número y manejar el negocio. El grupo de conexiones creará algunas conexiones por adelantado, al igual que el banco prepara varias ventanas por adelantado para el procesamiento comercial, de modo que solo se pueda obtener una conexión disponible del grupo de conexiones, lo que reduce el tiempo de espera y mejora la eficiencia de la conexión.

2. Ahorre recursos del sistema: la conexión a la base de datos es un recurso limitado, al igual que el personal de un banco es limitado. Si todos usan a un miembro del personal para manejar los negocios, el banco se paralizará rápidamente. El conjunto de conexiones puede administrar y controlar la cantidad de conexiones, de forma similar a la cantidad de ventanas de control del banco, para garantizar que no se creen demasiadas conexiones, evitando así el desperdicio de recursos de la base de datos y del servidor.

3. Simplifique la administración de conexiones: la agrupación de conexiones nos permite administrar las conexiones más fácilmente, al igual que el sistema de filas de un banco permite que el personal del banco se concentre en el negocio del cliente. A través del grupo de conexiones, no necesitamos crear y liberar manualmente la conexión, solo obtenga la conexión del grupo de conexiones y utilícela, y devuélvala al grupo de conexiones después de completarla. Esto simplifica el trabajo de gestión de conexiones y mejora la eficiencia del desarrollo. En resumen, el grupo de conexiones de MySQL es como un sistema de colas bancarias, que puede mejorar la eficiencia de la conexión, ahorrar recursos del sistema, administrar la confiabilidad de la conexión y simplificar la administración de la conexión. El grupo de conexiones juega un papel importante en las operaciones de base de datos de alta concurrencia, ayudándonos a conectarnos e interactuar con la base de datos MySQL de manera más eficiente y conveniente.

4. ¿Cómo maneja Mysql las solicitudes de conexión?

Cuando Mysql recibe una solicitud de conexión de red, cómo procesa la solicitud y cómo ejecutar el SQL finalmente, echemos un vistazo a los pasos en el enlace del proceso completo.
primero:

1. La conexión de red debe asignarse a un subproceso para su procesamiento, y un subproceso supervisa la solicitud y lee los datos de la solicitud, como leer y analizar una instrucción SQL enviada por el sistema Java desde la conexión de red
   .
2. Se proporciona un componente dentro de Mysql: interfaz SQL (interfaz SQL), que se utiliza para ejecutar específicamente sentencias SQL
3. Luego use el optimizador de consultas: seleccione la ruta de consulta óptima para ejecutar, función: genere un árbol de ruta de consulta para declaraciones SQL complejas escritas por usted con decenas de líneas, cientos de líneas o incluso miles de líneas, y luego seleccione una consulta óptima de él camino de salida
4. Llamar al ejecutor: llamar a la interfaz del motor de almacenamiento según el plan de ejecución
5. Llame a la interfaz del motor de almacenamiento para ejecutar realmente la instrucción SQL.Función: el ejecutor llamará a la interfaz del motor de almacenamiento de acuerdo con un cierto orden y pasos de acuerdo con el plan de ejecución seleccionado por el optimizador, y ejecutará la lógica de la instrucción SQL
6. Motor de almacenamiento: administre y almacene datos, admita una variedad de motores de almacenamiento como: InnoDB, MyISAM, Memory, podemos elegir qué motor de almacenamiento usar para ser responsable de la ejecución de declaraciones SQL específicas. Ahora MySQL generalmente usa el motor de almacenamiento InnoDB de forma predeterminada.

Si está interesado en todo el proceso de ejecución anterior, puede estudiarlo en profundidad, y este artículo no presentará los detalles. Analicemos cómo el motor de almacenamiento InnoDB gestiona y almacena nuestros datos.

5. Estructura de memoria importante de InnoDB: grupo de búfer

En el motor de almacenamiento InnoDB, hay un componente muy importante en la memoria, que es el grupo de búfer (BufferPool), que almacenará en caché una gran cantidad de datos, de modo que cuando consulte más tarde, si tiene datos en el grupo de búfer de memoria, simplemente no necesita verificar el disco, veamos la imagen a continuación.

Por ejemplo, la declaración SQL: actualizar usuarios establecer nombre = 'xxx' donde id = 1, por ejemplo, para la fila de datos "id = 1", primero verificará si la fila de datos "id = 1" está en el grupo de búfer, si no está allí, se cargará directamente desde el disco en el grupo de búfer, y luego se agregará un bloqueo exclusivo a esta fila de registros.

El grupo de búfer utiliza el algoritmo LRU (Usado menos recientemente) para administrar las páginas de datos en la memoria. Cuando una consulta necesita acceder a los datos, InnoDB primero verifica si la página de datos correspondiente existe en el grupo de búfer. Si está presente, obtiene los datos directamente de la memoria en lugar de leerlos del disco, lo que mejora en gran medida el rendimiento de las consultas. Si la página de datos no está en el grupo de búfer, InnoDB la leerá en el grupo de búfer y la mantendrá en la memoria para consultas posteriores.

Al configurar correctamente el tamaño del grupo de búfer, las páginas de datos de uso frecuente siempre se pueden mantener en la memoria, lo que mejora la eficiencia de las consultas. Los grupos de búfer más grandes generalmente son adecuados para servidores con grandes cantidades de memoria

6. archivo de registro de deshacer: para que los datos actualizados se puedan revertir

Los archivos de registro de deshacer se utilizan para registrar las operaciones de las transacciones en curso en la base de datos para proporcionar datos de reversión cuando es necesario revertir una transacción. Cuando se produce una operación de actualización, eliminación o inserción, el motor InnoDB registrará la información relevante en el archivo de registro Deshacer.

Cuando es necesario deshacer una transacción, el motor InnoDB utiliza el registro Deshacer para restaurar los datos al estado en que se encontraban antes de que comenzara la transacción. Deshace las modificaciones a los datos invirtiendo la operación y restaura los datos a su estado anterior.

Cuando cargamos el registro que se actualizará desde el archivo de disco al grupo de búfer, lo bloqueamos al mismo tiempo y escribimos el valor anterior antes de la actualización en el archivo de registro de deshacer, podemos comenzar oficialmente a actualizar el registro. los registros en el grupo de búfer se actualizarán primero y los datos en este momento son datos sucios.

La llamada actualización de los datos en el grupo de búfer de memoria aquí significa cambiar el campo de nombre de los datos en la fila "id=1" en la memoria
a "xxx":

7. Rehaga los archivos de registro: asegure la consistencia y persistencia de los datos

Ahora imaginemos que si la operación de modificación en la figura anterior se ha escrito en la memoria caché, pero no se ha sincronizado con el disco para persistencia en el futuro; en este momento, la máquina msyql está inactiva y cuelga, entonces los datos en el caché inevitablemente Si se pierde, los datos actualizados también se perderán. Por lo tanto, para garantizar la coherencia y la durabilidad de los datos de Mysql, el motor innodb introduce archivos de registro de rehacer.

El Redo Log es un registro físico que se utiliza principalmente para registrar las operaciones de modificación realizadas en la base de datos antes de que se confirme la transacción. Cuando la base de datos falla o falla, el registro de rehacer se puede usar para restaurar al último estado enviado para garantizar la persistencia de los datos.

El papel de Redo Log se refleja principalmente en los siguientes dos aspectos:

1. Recuperación de datos: cuando la base de datos falla, las operaciones de modificación no confirmadas se pueden volver a aplicar a la base de datos a través de Redo Log, restaurando así el último estado enviado.
2. Mejore el rendimiento: al registrar las operaciones de modificación en el registro de rehacer, las operaciones de E/S del disco se pueden convertir en operaciones de escritura secuencial, lo que mejora en gran medida el rendimiento de escritura de la base de datos.

Por lo tanto, cuando se ejecuta la operación de actualización, Mysql escribirá la modificación en la memoria en un búfer de registro de rehacer, que también es un búfer en la memoria y se usa para almacenar el registro de redo. El llamado registro de rehacer es para registrar qué modificaciones ha realizado en los datos, como cambiar el valor del campo de nombre a xxx para el registro "id = 10", esto es un registro. Como se muestra en la siguiente figura:

Observaciones: innodb_log_buffer_size: especifica el tamaño del búfer de Redo Log, el valor predeterminado es 8 MB. Un valor mayor
puede reducir las operaciones de actualización frecuentes y mejorar el rendimiento, pero también consumirá más memoria.

8. Envíe la transacción: rehaga el vaciado de registros

Cuando se confirma la transacción, los datos en el área de caché en el redolog se vaciarán en el disco. Entonces, ¿importa la pérdida de datos en este punto?

De hecho, no importa, porque si no envió una transacción para una declaración de actualización, significa que no se pudo ejecutar con éxito. En este momento, aunque el tiempo de inactividad de MySQL provocó la pérdida de todos los datos en la memoria, usted encontrará que los datos en el disco todavía están en el estado original.

Tres estrategias para escribir registros de rehacer en el disco

La estrategia de descarga se configura a través de innodb_flush_log_at_trx_commit, que tiene varias opciones:

1. Si el valor del parámetro es 0, el registro de rehacer no ingresa al disco, lo que significa que el registro de rehacer no se vacía en el disco, es decir, la estrategia de escritura asíncrona. Cuando se confirma una transacción, la operación de modificación del Redo Log solo se escribirá en la memoria caché de la página del sistema operativo y no se vaciará en el disco inmediatamente. Esto proporciona el mejor rendimiento de escritura, pero puede resultar en cierto grado de pérdida de datos en caso de falla o bloqueo de la base de datos.
2. El valor del parámetro es 1, y el registro de rehacer se envía al disco [valor predeterminado] significa que el registro de rehacer se vacía en el disco sincrónicamente. Cuando se confirma la transacción, la operación de modificación del Redo Log se escribirá en el disco inmediatamente y esperará a que se complete la operación de E/S. Además de garantizar la persistencia de los datos, también tendrá un cierto impacto en el rendimiento. Esta es la configuración más utilizada y es adecuada para la mayoría de los escenarios de aplicación.

3. El valor del parámetro es 2 y el registro de rehacer se ingresa en la memoria caché del sistema operativo.

Indica que la operación de modificación del Redo Log se escribe en el disco cada vez que se confirma una transacción, pero no espera a que finalice la operación de E/S. Cuando se confirma una transacción, el registro de rehacer se escribe primero en la memoria caché de la página del sistema operativo y luego el subproceso en segundo plano vacía los datos en el disco de forma asíncrona. Esta configuración puede proporcionar un mejor rendimiento y cierto grado de protección de datos, pero aún existen algunos riesgos.

Selección de la estrategia de descarga
La selección del valor innodb_flush_log_at_trx_commit adecuado depende de los requisitos de persistencia y rendimiento de los datos. Se puede establecer en 1 si los requisitos de persistencia de datos son muy altos. Si el requisito de rendimiento es alto y un cierto grado de pérdida de datos es aceptable, se puede establecer en 0. Si busca un mejor rendimiento mientras garantiza un cierto grado de protección de datos, puede elegir establecerlo en 2.

Puede ajustar el valor de innodb_flush_log_at_trx_commit modificando la configuración de los parámetros en el archivo de configuración de MySQL y reiniciando el servicio de MySQL para que surta efecto.

Por lo general, recomendamos establecerlo en 1. Es decir, al realizar una transacción, el registro de rehacer debe vaciarse en el archivo del disco. Esto puede garantizar estrictamente que después de confirmar la transacción, los datos nunca se perderán, porque hay registros de rehacer en el archivo del disco para restaurar todas las modificaciones que realizó.

9. ¿Qué es exactamente binlog?

De hecho, el registro de rehacer que mencionamos antes es una especie de registro de rehacer que está sesgado hacia la naturaleza física, porque registra algo como esto, "qué modificación se hizo a qué registro en qué página de datos".

Y el registro de rehacer en sí mismo es algo exclusivo del motor de almacenamiento InnoDB. El binlog se llama registro de archivo, que registra un registro que está sesgado hacia la lógica, similar a "actualizar una fila de datos con id = 1 en la tabla de usuarios, cuál es el valor después de la actualización", binlog no es un almacenamiento InnoDB motor El archivo de registro único es un archivo de registro que pertenece al propio servidor mysql. Por lo tanto, cuando se envía una transacción, binlog se escribirá al mismo tiempo:
Análisis de la estrategia de vaciado de registros de binlog
Para los registros de binlog, en realidad existen diferentes estrategias de vaciado. Hay un parámetro sync_binlog que puede controlar la estrategia de vaciado de binlog, y su valor predeterminado El valor es 0, cuando escribe el binlog en el disco, no ingresa directamente al archivo del disco, sino que ingresa al caché de la memoria caché del sistema operativo. Entonces, al igual que en el análisis anterior, si la máquina está inactiva en este momento, se perderá su registro binlog en el caché del sistema operativo:

si establece el parámetro sync_binlog en 1, entonces en este momento se verá obligado a enviar la transacción. El binlog se escribe directamente en el archivo del disco, por lo que después de confirmar la transacción de esta manera, incluso si la máquina deja de funcionar, el binlog del disco no se perderá.

Envío completo de transacciones basado en binlog y redo log

Cuando escribimos el binlog en el archivo del disco, se completará el envío de la transacción final. En este momento, el nombre del archivo binlog correspondiente a esta actualización y la ubicación del registro binlog actualizado en el archivo se escribirán en el registro de rehacer. Vaya al archivo de registro y escriba una marca de compromiso en el archivo de registro de registro de rehacer al mismo tiempo. Después de completar este asunto, finalmente se completa el envío de la transacción. Veamos el siguiente diagrama: ¿

Cuál es el significado de escribir la marca de compromiso en el registro de rehacer en el último paso?

Para mantener el registro de rehacer consistente con el registro binlog, la marca de confirmación de la transacción final debe escribirse en el registro de rehacer, y luego la transacción se confirma con éxito en este momento, y hay un registro correspondiente a esta actualización en el registro de rehacer, y hay también es un registro en el binlog El registro correspondiente a la segunda actualización, el registro de rehacer y el binlog son completamente consistentes

El subproceso de E/S de fondo vacía aleatoriamente los datos sucios después de la actualización de la memoria en el disco

MySQL tiene un subproceso de E/S en segundo plano, que vaciará aleatoriamente los datos sucios modificados en el grupo de búfer de memoria de vuelta al archivo de datos en el disco en un momento determinado en el futuro.Veamos la siguiente figura: en su subproceso de E/S Antes de vaciar el

sucio datos en el disco, no importa incluso si mysql falla, porque después de reiniciar, restaurará la modificación realizada por la transacción enviada antes de acuerdo con el registro de rehacer en la memoria, y luego esperará el momento adecuado, el IO el subproceso naturalmente hará esta modificación. Los datos finales se descargan en el archivo de datos en el disco.

10. Resumen

El motor de almacenamiento InnoDB contiene principalmente algunos datos almacenados en caché en la memoria, como el grupo de búfer y el búfer de registro de rehacer, y también contiene algunos archivos de registro de deshacer, archivos de registro de rehacer, etc., y el propio servidor mysql también tiene archivos de registro binlog.

Cuando realiza una actualización, cada instrucción SQL se corresponderá con la modificación de los datos en caché en el grupo de búfer, la escritura del registro de deshacer y la escritura del búfer del registro de rehacer; pero cuando envíe la transacción, el registro de rehacer definitivamente se vaciará en el disco. , el binlog se vacía en el disco y se completa la marca de compromiso de transacción en el registro de rehacer; finalmente, el subproceso de E/S en segundo plano vaciará aleatoriamente los datos sucios del grupo de búfer en el disco.

Al final del artículo, todavía se requieren Me gusta, en caso de que haya un chico guapo frente a la pantalla, ¡simplemente dale me gusta! ! ! !