Mi informacion de contacto
Correo[email protected]
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
En términos generales, MySQL se puede dividir en dos capas.
mysql -h$ip -P$port -u$user -p
MySQL en el comando de conexión es una herramienta de cliente utilizada para establecer una conexión con el servidor.Después de completar el protocolo de enlace TCP clásico, el conector
Está a punto de comenzar a autenticar su identidad. En este momento, se utilizará el nombre de usuario y la contraseña que ingresó.
Si el cliente permanece inactivo durante demasiado tiempo, el conector lo desconectará automáticamente. Este tiempo está controlado por el parámetro wait_timeout y el valor predeterminado es 8 horas.
Si el cliente vuelve a enviar una solicitud después de desconectarse la conexión, recibirá un recordatorio de error: Lost connection to MySQL server during query . Si desea continuar en este momento, debe volver a conectarse y luego ejecutar la solicitud.
En la base de datos, una conexión larga significa que después de que la conexión sea exitosa, si el cliente continúa realizando solicitudes, siempre se utilizará la misma conexión. Una conexión corta significa que la conexión se desconecta después de ejecutar algunas consultas y se restablece una nueva para la siguiente consulta.
El proceso de establecimiento de una conexión suele ser complicado, por lo que le sugiero que intente minimizar las acciones de establecimiento de una conexión durante el uso, es decir, intente utilizar conexiones largas.
Pero después de utilizar todas las conexiones largas, es posible que a veces la memoria ocupada por MySQL aumente muy rápidamente.La memoria utilizada temporalmente por MySQL durante la ejecución se gestiona en el objeto de conexión. . Estos recursos se liberarán cuando se desconecte la conexión.Así que siLa acumulación de conexiones largas puede provocar un uso excesivo de la memoria., fue eliminado por la fuerza por el sistema (OOM). A juzgar por el fenómeno, MySQL se reinició de manera anormal.
¿Cómo resolver este problema? Puedes considerar las siguientes dos opciones.
mysql_reset_connection para reinicializar los recursos de conexión. Este proceso no requiere reconexión ni verificación de permisos, pero restaurará la conexión al estado en el que se acababa de crear.Después de que MySQL reciba una solicitud de consulta, primero irá al caché de consultas para ver si esta declaración se ha ejecutado antes. Las declaraciones ejecutadas previamente y sus resultados se pueden almacenar en caché directamente en la memoria en forma de pares clave-valor. La clave es la declaración de la consulta y el valor es el resultado de la consulta. Si su consulta puede encontrar la clave directamente en este caché, entonces el valor se devolverá directamente al cliente.
Si la declaración no está en la caché de consultas, la fase de ejecución continúa. Una vez completada la ejecución, los resultados de la ejecución se almacenarán en la caché de consultas. Puede ver que si la consulta llega al caché, MySQL puede devolver el resultado directamente sin realizar operaciones complejas posteriores, lo cual es muy eficiente.
Pero la mayor parte del tiempo lo haréSe recomienda no utilizar el almacenamiento en caché de consultas. ,¿por qué? Porque el almacenamiento en caché de consultas a menudo hace más daño que bien.
La caché de consultas se invalida con mucha frecuencia. Siempre que haya una actualización de una tabla, se borrarán todas las cachés de consultas de esta tabla. Por lo tanto, es posible que se haya tomado la molestia de guardar los resultados y, antes de usarlos, fueron eliminados por una actualización. Para bases de datos con una gran presión de actualización, la tasa de aciertos de la caché de consultas será muy baja. A menos que su empresa tenga una tabla estática que solo se actualizará una vez cada mucho tiempo. Por ejemplo, si es una tabla de configuración del sistema, entonces la consulta en esta tabla es adecuada para la caché de consultas.
Afortunadamente, MySQL también proporciona este método de "uso bajo demanda". Puede establecer el parámetro query_cache_type en DEMAND para que la caché de consultas no se utilice para las declaraciones SQL predeterminadas. Para las declaraciones en las que está seguro de querer usar la caché de consultas, puede usar SQL_CACHE para especificarlo explícitamente, como la siguiente declaración:
select SQL_CACHE * from T where ID=10；
hay que tener en cuenta es,La versión MySQL 8.0 elimina directamente toda la función de caché de consultas, lo que significa que esta función ya no estará disponible a partir de la versión 8.0.
Si no se accede a la caché de consultas, comienza la ejecución real de la declaración. Primero, MySQL necesita saber lo que quiere hacer, por lo que necesita analizar la declaración SQL.
No sé si todavía recuerdas el artículo "Kong Yiji". El gerente del hotel tiene una pizarra rosa que se utiliza especialmente para registrar los registros crediticios de los huéspedes. Si no hay mucha gente que pague a crédito, entonces puede escribir el nombre del cliente y la cuenta en la pizarra. Pero si hay demasiadas personas con cuentas de crédito, siempre habrá ocasiones en las que el panel de fans no podrá realizar un seguimiento de ellas. En este momento, el comerciante debe tener un libro de contabilidad específico para registrar las cuentas de crédito.
Si alguien quiere liquidar un crédito o saldar una deuda, el comerciante generalmente tiene dos opciones:
Cuando el negocio está en auge y el mostrador está ocupado, el comerciante definitivamente elegiráeste último , porque la operación anterior es demasiado problemática. Primero, debe encontrar el registro de la cuenta de crédito total de esta persona. Piénselo, hay docenas de páginas densamente empaquetadas. Para encontrar el nombre, es posible que el comerciante tenga que ponerse gafas para leer y buscar lentamente. Después de encontrarlo, sacará el ábaco para calcular y finalmente escribirá el resultado nuevamente. el libro mayor.
Es problemático pensar en todo este proceso. Por el contrario, es más fácil escribirlo primero en la pizarra rosa. Piénselo, si el comerciante no cuenta con la ayuda del tablero rosa, tendrá que girar el libro de contabilidad cada vez que registre las cuentas, ¿no es la eficiencia insoportablemente baja?
De manera similar, este problema también existe en MySQL. Si cada operación de actualización debe escribirse en el disco y el disco también debe encontrar el registro correspondiente antes de la actualización, el costo de IO y el costo de búsqueda de todo el proceso serán muy altos. Para resolver este problema, los diseñadores de MySQL utilizaron una idea similar al tablero rosa del comerciante del hotel para mejorar la eficiencia de las actualizaciones.
Todo el proceso de cooperación entre el tablero rosa y el libro mayor es en realidad lo que se menciona a menudo en MySQL. WAL tecnología,WAL El nombre completo esWrite-Ahead Logging, el punto clave esEscriba el registro primero y luego escriba en el disco., es decir, escriba primero el pizarrón rosa y luego escriba el libro de cuentas cuando no esté ocupado.
Específicamente, cuando es necesario actualizar un registro, el motor InnoDB primero escribirá el registro en el registro de rehacer (tablero rosa) y actualizará la memoria. Al mismo tiempo, el motor InnoDB actualizará el registro de operación en el disco en el momento apropiado, y esta actualización a menudo se realiza cuando el sistema está relativamente inactivo, tal como lo hace el comerciante después de cerrar.
Si hoy no hay muchas cuentas de crédito, el comerciante puede esperar hasta la hora de cierre para ordenar los artículos. Pero, ¿qué debemos hacer si un día determinado hay muchas cuentas de crédito y el tablero rosa está lleno? En ese momento, el comerciante no tuvo más remedio que dejar su trabajo, actualizar algunos de los registros de crédito en el tablero rosa en el libro mayor y luego borrar estos registros del tablero rosa para dejar espacio para nuevas cuentas.
De manera similar, el registro de rehacer de InnoDB tiene un tamaño fijo. Por ejemplo, se puede configurar como un conjunto de 4 archivos, cada archivo tiene un tamaño de 1 GB. Luego, este "tablero rosa" puede registrar un total de operaciones de 4 GB. Comience a escribir desde el principio y luego regrese al principio para escribir en un bucle, como se muestra en la siguiente imagen.
write pos es la posición del registro actual. Se mueve hacia atrás mientras escribe. Después de escribir hasta el final del archivo No. 3, regresa al principio del archivo No. 0. El punto de control es la posición actual que se va a borrar y también avanza y se repite. Antes de borrar el registro, el registro debe actualizarse en el archivo de datos.
El espacio entre la posición de escritura y el punto de control es la parte vacía del "tablero rosa" que se puede utilizar para registrar nuevas operaciones. Si la posición de escritura alcanza el punto de control, significa que el "tablero rosa" está lleno y no se pueden realizar nuevas actualizaciones en este momento. Primero debe detener y borrar algunos registros para avanzar en el punto de control.
Con el registro de rehacer, InnoDB puede garantizar que incluso si la base de datos se reinicia de manera anormal, los registros enviados anteriormente no se perderán.crash-safe。
Para comprender el concepto de seguridad contra accidentes, piense en nuestro ejemplo anterior de registro de crédito. Siempre que el registro de crédito esté registrado en el tablero rosa o escrito en el libro mayor, incluso si el comerciante lo olvida más tarde, como por ejemplo, si suspende repentinamente el negocio durante unos días, aún puede aclarar la cuenta de crédito a través de los datos del libro mayor y tablero rosa después de reanudar el negocio.
Como mencionamos antes, MySQL en su conjunto en realidad tiene dos partes: una es la capa del servidor, que hace principalmente cosas en el nivel funcional de MySQL y la otra es la capa del motor, que es responsable de asuntos específicos relacionados con el almacenamiento;El tablero rosa del que hablamos arribaEl registro de rehacer es un registro exclusivo del motor InnoDB.,y La capa del Servidor también tiene su propio registro, llamado binlog (registro de archivo)。
Creo que te preguntarás, ¿por qué hay dos registros?
Porque al principio no había ningún motor InnoDB en MySQL. El propio motor de MySQL es MyISAM, pero MyISAM no tiene capacidades a prueba de fallas y los registros binlog solo se pueden usar para archivar. InnoDB fue introducido en MySQL en forma de complemento por otra empresa. Dado que depender únicamente de binlog no tiene capacidades a prueba de fallas, InnoDB usa otro sistema de registro, es decir, rehacer registro, para lograr capacidades a prueba de fallas.
Estos dos registros tienen las siguientes tres diferencias.
Con una comprensión conceptual de estos dos registros, veamos los procesos internos del ejecutor y el motor InnoDB al ejecutar esta simple declaración de actualización.
Aquí proporciono el diagrama de flujo de ejecución de esta declaración de actualización. El cuadro claro en la figura indica que se ejecuta dentro de InnoDB y el cuadro oscuro indica que se ejecuta en el ejecutor.
actualizar el proceso de ejecución de la declaración
Es posible que haya notado que los últimos tres pasos parecen un poco "circulares". La escritura del registro de rehacer se divide en dos pasos: preparar y confirmar. Esto es "compromiso de dos fases".
¿Por qué es necesaria una "presentación en dos fases"?Esto es para permitir la diferencia entre los dos registros.lógicamente consistente . Para explicar este problema, debemos comenzar con la pregunta al principio del artículo: ¿Cómo restaurar la base de datos al estado de cualquier segundo en medio mes?
Como dijimos antes, binlog registrará todas las operaciones lógicas y adoptará la forma de "escritura adjunta". Si su DBA promete que se puede restaurar en medio mes, entonces el sistema de respaldo definitivamente guardará todos los binlogs en el último medio mes y el sistema realizará copias de seguridad periódicas de toda la base de datos. Lo "regular" aquí depende de la importancia del sistema, que puede ser una vez al día o una vez a la semana.
Cuando necesita restaurar a un segundo específico, por ejemplo, a las dos de la tarde de un día, descubre que una tabla se eliminó accidentalmente al mediodía y necesita recuperar los datos, puede hacer esto:
Bien, después de hablar sobre el proceso de recuperación de datos, volvamos y hablemos de por qué el registro necesita "compromiso en dos fases". Aquí también podríamos utilizar la prueba por contradicción para explicar.
Dado que redo log y binlog son dos lógicas independientes, si no se utiliza la confirmación de dos fases, primero se debe escribir el redo log y luego el binlog, o se debe adoptar el orden inverso. Veamos qué problemas hay con estos dos métodos.
Siga utilizando la declaración de actualización anterior como ejemplo. Suponga que el valor del campo c en la fila actual con ID = 2 es 0 y suponga que durante la ejecución de la declaración de actualización, se produce un bloqueo después de que se escribe el primer registro pero antes de que se escriba el segundo.
Usted podría decir: ¿Esta probabilidad es muy baja? No hay situaciones en las que sea necesario restaurar la biblioteca temporal en ningún momento.
En realidad no, este proceso no sólo es necesario para recuperar datos después de un mal funcionamiento. Cuando necesita expandir la capacidad, es decir, cuando necesita crear más bases de datos en espera para aumentar la capacidad de lectura del sistema, la práctica común ahora es usar una copia de seguridad completa y aplicar binlog para lograr esto. Esta "inconsistencia" causará su Hay. una inconsistencia entre las bases de datos maestra y esclava en línea.
En pocas palabras, tanto el registro de rehacer como el binlog se pueden utilizar para representar el estado de confirmación de una transacción, yLa presentación en dos fases tiene como objetivo mantener la coherencia lógica de los dos estados.。
Se ha dedicado a la investigación de tecnología durante más de 30 años y domina varios lenguajes como java, linux, javascript, php, css, etc. Ha realizado muchas contribuciones en el campo del código abierto. Estación de documentación para desarrolladores para compartir algunos problemas en el desarrollo de tecnología para referencia futura.
Correo[email protected]