El siguiente contenido es un resumen de los puntos de conocimiento basados en "MySQL Performance Tuning and Architecture Design", los amigos interesados pueden leer este libro, después de todo, aprender y comparar sistemas de acuerdo con el libro. Capaz de captar el contexto del conocimiento como un todo.
1. Composición del módulo lógico MySQL
MySQL se puede considerar como una arquitectura de dos niveles. La primera capa se llama Capa SQL. La función principal de esta parte es completar todos los preparativos antes de que el sistema de base de datos mysql procese los datos subyacentes, incluido el juicio de permisos, el análisis SQL y el plan de ejecución. Optimización, procesamiento de caché de consultas, etc.; La segunda capa es la capa del motor de almacenamiento (Capa del motor de almacenamiento), esta capa es la realización de las operaciones de acceso a datos en el sistema de la base de datos, que se completa con múltiples motores de almacenamiento. 
Parece simple en estructura, pero cada capa contiene muchos módulos pequeños.
Los módulos incluidos en la capa SQL Layer son:
- Módulo de inicialización
El módulo de inicialización es para realizar varias operaciones de inicialización en todo el sistema cuando se inicia el servidor mysql, como la inicialización de varios búferes y estructuras de caché y la aplicación de espacio de memoria, la configuración de inicialización de varias variables del sistema y varios motores de almacenamiento. Configuración inicial, etc.
- API central
El módulo principal de API es principalmente para proporcionar algunas implementaciones optimizadas de funciones de operación de bajo nivel que requieren muy eficientes, incluida la realización de varias estructuras de datos de bajo nivel, la realización de algoritmos especiales, canalización de caracteres, procesamiento digital, etc., E / S de archivos pequeños, salida formateada Y la parte más importante de la gestión de la memoria. Todos los códigos fuente del módulo API principal se concentran en la carpeta mysys y strings.
- Módulo de interacción en red
El módulo de interacción de la red subyacente abstrae la API de interfaz utilizada por la interacción de la red subyacente y realiza la recepción y el envío de los datos de la red subyacente para facilitar la invocación de otros módulos. Y parte del mantenimiento de este programa. Todo el código fuente está en la carpeta vio.
- Módulo de protocolo interactivo cliente y servidor
Cualquier sistema de software estructurado C / S definitivamente tendrá su propio protocolo de interacción de información único, y MySQL no es una excepción El módulo de protocolo de interacción Cliente & Servidor parte de MySQL realiza todos los protocolos en el proceso de interacción entre el cliente y MySQL. Por supuesto, estos protocolos se basan en el sistema operativo y los protocolos de red existentes. Como TCP / IP, Unix Socket.
- Módulo de usuario
Las funciones implementadas por el módulo de usuario incluyen principalmente el control de autoridad de conexión de inicio de sesión del usuario y la gestión de autorización de usuario. Al igual que el guardia de la puerta de MySQL, decida si "abrir la puerta" a los visitantes
-
Módulo de control de acceso
¿Qué pasa si los visitantes pueden hacer lo que quieran cuando entran por la puerta? Por razones de seguridad, no debe ser tan arbitrario. En este momento, el módulo de control de acceso debe monitorear cada acción del huésped en tiempo real y otorgar diferentes permisos a los diferentes invitados. La función realizada por el módulo de control de acceso es controlar el acceso del usuario a los datos en base a la información de autorización de cada usuario en el módulo de usuario y varias restricciones únicas a la propia base de datos. El módulo de usuario y el módulo de control de acceso se combinan para formar la función de gestión de seguridad de permisos de todo el sistema de base de datos MySQL.
- Gestión de conexiones, hilo de conexión, módulo de gestión de hilos
El módulo de administración de conexiones es responsable de monitorear varias solicitudes a MySQL Server, aceptar solicitudes de conexión y reenviar todas las solicitudes de conexión al módulo de administración de subprocesos. A cada solicitud de cliente conectada a MySQL Server se le asignará (o creará) un subproceso de conexión para su servicio separado . El trabajo principal del hilo de conexión es ser responsable de la comunicación entre MySQL Server y el cliente, y aceptar las solicitudes de comando del cliente. Pase la información de resultados en el lado del servidor. El módulo de administración de subprocesos es responsable de administrar y mantener estos subprocesos de conexión. También incluye creación de subprocesos, caché de subprocesos, etc.
-
Módulo de análisis y reenvío de consultas
En MySQL, estamos acostumbrados a llamar a todos los comandos enviados desde el Cliente al Servidor como consulta. En MySQL Server, después de que el hilo de conexión recibe una consulta del cliente, pasará directamente la consulta a la clase especial responsable de clasificar varias consultas. Reenviar al módulo de procesamiento correspondiente, este módulo es el módulo de análisis y reenvío de consultas. El trabajo principal es realizar un análisis semántico y gramatical de las declaraciones de consulta, luego clasificarlas de acuerdo con diferentes tipos de operaciones y luego realizar un reenvío dirigido.
- Módulo de caché de consultas
El módulo Query Cache es un módulo muy importante en MySQL. Su función principal es almacenar en caché el conjunto de resultados devueltos de la solicitud de consulta de la clase select enviada por el cliente a MySQL en la memoria, y hacer una correspondencia con un valor hash de la consulta. Después de que se produzcan cambios en los datos de la tabla base de los datos obtenidos por la consulta, MySQL invalidará automáticamente la caché de la consulta. En un sistema de aplicaciones con una proporción muy alta de lecturas y escrituras, la mejora del rendimiento de la caché de consultas es muy significativa. Por supuesto, su consumo de memoria también es enorme.
- Módulo optimizador de consultas
El optimizador de consultas es optimizar la consulta solicitada por el cliente. De acuerdo con el enunciado de consulta solicitado por el cliente, y alguna información estadística en la base de datos, analiza en base a una serie de algoritmos para obtener una estrategia óptima y decirle al programa posterior Cómo obtener el resultado de esta declaración de consulta.
-
Módulo de gestión de cambios de mesa
El módulo de administración de cambios de tabla es principalmente responsable de completar algunas consultas DML y DDL, como: actualizar, eliminar, insertar, crear tabla, modificar tabla y otras declaraciones.
- Módulo de mantenimiento de mesa
La verificación del estado de la tabla, la reparación de errores, la optimización y el análisis son todas las cosas que debe hacer el módulo de mantenimiento de la tabla.
-
Módulo de gestión del estado del sistema
El módulo de gestión del estado del sistema es responsable de devolver varios datos de estado al usuario cuando el cliente solicita el estado del sistema, como el comando show status y el comando show variables comúnmente utilizado por DBA. Los resultados obtenidos son todos devueltos por este módulo.
-
Gerente de mesa
Este módulo se confunde con el módulo de cambio de tabla y mantenimiento de tabla anterior del nombre, pero su función es completamente diferente del módulo de cambio de tabla y mantenimiento. Todo el mundo sabe que cada tabla MySQL tiene un archivo de definición de tabla, que sigue siendo un archivo * .frm. El trabajo principal del administrador de tablas es mantener estos archivos y un caché El contenido principal del caché es la información de estructura de cada tabla. Además, también mantiene la gestión de bloqueos a nivel de tabla.
-
Módulo de registro
Principalmente responsable de los registros de la capa lógica de todo el nivel del sistema, incluido el registro de errores, el registro binario, el registro de consultas, etc.
-
Módulo de copia
El módulo de replicación se puede dividir en dos partes: el módulo maestro y el módulo esclavo. El módulo maestro es principalmente responsable de leer el registro binario del lado maestro en el entorno de replicación e interactuar con el hilo de E / S del lado esclavo. El módulo esclavo hace un poco más que el módulo maestro. Se refleja principalmente en dos subprocesos del sistema. Uno es responsable de solicitar y recibir el registro binario del maestro y escribir en el subproceso de E / S en el registro de retransmisión local. El otro es responsable de leer los archivos de registro relevantes del registro de retransmisión y luego analizarlos en el subproceso SQL que se puede ejecutar correctamente en el lado esclavo y obtener exactamente el mismo resultado que en el lado maestro y luego entregarlos al subproceso SQL ejecutado por el esclavo.
-
Módulo de interfaz del motor de almacenamiento
El módulo de interfaz del motor de almacenamiento es el punto más distintivo de la base de datos MySQL. Actualmente, entre varios productos de bases de datos, básicamente solo MySQL puede realizar la administración de complementos de su motor de almacenamiento de datos subyacente. Este módulo es en realidad solo una clase abstracta, pero es precisamente debido a su exitosa abstracción de alto nivel de varios procesos de bases de datos que ha logrado las características del motor de almacenamiento conectable MySQL actual.
2. Coordinación de trabajo de cada módulo
Aquí viene el punto. Usamos un ejemplo para ilustrar cómo cada módulo del sistema mysql se ama entre sí para completar una consulta que creemos que es muy simple.
Iniciamos mysql, establecemos una conexión con el cliente, solicitamos una consulta, obtenemos el resultado devuelto y finalmente salimos. Todo un proceso de análisis.
El primer paso: después de ejecutar el comando para iniciar el sistema mysql, el módulo de inicialización de mysql lee los parámetros del sistema y los parámetros de la línea de comandos del archivo de configuración del sistema e inicializa todo el sistema de acuerdo con los parámetros, como solicitar y asignar búferes e inicializar variables globales. , Y varias estructuras. Al mismo tiempo, cada motor de almacenamiento también se inicia para realizar su propio trabajo de inicialización. Cuando se inicializa todo el sistema, el módulo de administración de conexiones se hará cargo. El módulo de administración de conexiones iniciará el programa de escucha para procesar las solicitudes de conexión del cliente, incluida la supervisión de la red tcp / ip y los sockets Unix. En este momento, mysql serve básicamente se inicia. , Listo para aceptar solicitudes de clientes.
Paso 2: cuando el módulo de gestión de conexión escucha la solicitud de conexión del cliente (con la ayuda de las funciones relevantes del módulo de interacción de red), las dos partes utilizan el protocolo definido por el módulo de protocolo de interacción cliente y servidor para "saludar" algunas palabras, y el módulo de gestión de conexión se conectará. La solicitud se reenvía al módulo de gestión de subprocesos para solicitar un subproceso de conexión.
Paso 3: El módulo de administración de subprocesos luego transfiere el control al módulo de subprocesos de conexión y le dice al módulo de subprocesos de conexión que ahora mi solicitud de conexión ha llegado y que se debe establecer una conexión. Por favor, maneje rápidamente. Después de recibir la solicitud de conexión, el módulo de subprocesos de conexión primero verificará si hay un subproceso de conexión inactivo almacenado en caché en el grupo de subprocesos de conexión actual. Si lo hay, sacará uno para conectarse con la solicitud del cliente. Si no hay un subproceso de conexión inactivo, establezca uno El nuevo hilo de conexión solicita una conexión con el cliente. Por supuesto, el módulo de hilo de conexión no saca inmediatamente un hilo de conexión para conectarse con el cliente después de recibir la solicitud de conexión. En cambio, primero verifica la autorización llamando al módulo de usuario. Solo después de que la solicitud del cliente pasa la verificación de autorización, La solicitud del cliente está conectada al hilo de conexión responsable de la solicitud.
En MySQL, las solicitudes del cliente se dividen en dos tipos, uno es consulta, que necesita llamar al analizador, que es el análisis del módulo de análisis y reenvío de consultas, para ejecutar la solicitud; el otro es el comando, que se puede ejecutar sin llamar al analizador. Solicitud. Si nuestra configuración inicial habilita la función de Registro de consultas completo, el módulo de análisis y reenvío de consultas llamará al módulo de registro para contar la solicitud en el registro. Independientemente de si se trata de una solicitud de tipo Consulta o de tipo comando, se registrará en el registro, por lo que, por motivos de rendimiento, la función de Registro de consulta completo generalmente rara vez se activa.
Paso 4: Cuando la solicitud del cliente y el hilo de conexión "intercambiar códigos secretos (protocolo de intercomunicación)" están conectados, el hilo de conexión comienza a procesar varios comandos (o consultas) enviados por la solicitud del cliente y acepta las solicitudes relacionadas. Él reenvía las declaraciones de consulta recibidas al módulo de análisis y reenvío de consultas. El analizador de consultas primero realiza un análisis semántico y gramatical básico de la consulta. Luego, según el tipo de comando, algunas se procesarán directamente y otras se distribuirán a otros módulos para su procesamiento.
Si es una solicitud de tipo de consulta, el control se transferirá al analizador de consultas. El analizador de consultas primero analiza si es una consulta de tipo seleccionado. Si es así, llama al módulo de caché de consultas para permitirle comprobar si la consulta está en la caché de consultas. ya existe. Si es así, devuelva directamente los datos en la caché al módulo de hilo de conexión. Luego, los datos se envían al cliente a través del hilo conectado con el cliente. Si no es un tipo de consulta que se pueda almacenar en caché, o si no hay datos de consulta en la caché, la consulta continuará pasándose de nuevo al analizador de consultas y el analizador de consultas la procesará en consecuencia y luego la distribuirá al módulo de procesamiento correspondiente a través del distribuidor de consultas.
Paso 5: Si el resultado del análisis del analizador es una instrucción de selección que no se almacena en caché, el control se transfiere al Optimizador, que es el módulo Optimizador de consultas. Si es una instrucción DML o DDL, se transferirá al módulo de administración de cambios de tabla. Si se trata de una consulta para actualizar estadísticas, detectar, reparar y clasificar, se entregará al módulo de mantenimiento de tablas para su procesamiento, la consulta relacionada con la copia se transferirá al módulo de replicación para su procesamiento correspondiente y el estado de solicitud de la consulta se entregará al informe de recopilación de estado. Módulo. De hecho, el módulo de gestión de cambios de tabla es responsable de diferentes DML y DDL al insertar procesador, eliminar procesador, actualizar procesador, crear procesador y alterar procesador de acuerdo con la solicitud de procesamiento correspondiente.
Paso 6: Después de que cada módulo recibe la solicitud del módulo de análisis y distribución de consultas, primero verificará si el usuario conectado tiene permiso para acceder a la tabla de destino de control y al campo de destino a través del módulo de control de acceso. De ser así, llamará al módulo de administración de tabla Solicita la tabla correspondiente y obtén el candado correspondiente. El módulo de gestión de tablas primero verá si la tabla ya existe en el caché de la tabla, si se ha abierto, realizará directamente el procesamiento relacionado con el bloqueo. Si no está en el caché, debe abrir el archivo de la tabla para obtener el bloqueo y luego entregar la tabla abierta Módulo de gestión de cambio de mesa.
Paso 7: Después de que el módulo de administración de cambios de tabla "obtenga" la tabla abierta, determinará el tipo de motor de almacenamiento y otra información relacionada de la tabla según la metainformación relacionada de la tabla. Según el tipo de motor de almacenamiento de la tabla, envíe una solicitud al módulo de interfaz del motor de almacenamiento, llame al módulo de implementación del motor de almacenamiento correspondiente y realice el procesamiento correspondiente.
Sin embargo, para el módulo de gestión de cambio de tabla, lo que está visible es solo una serie de interfaces "estándar" proporcionadas por el módulo de interfaz del motor de almacenamiento. La implementación específica del módulo de implementación del motor de almacenamiento subyacente es transparente para el módulo de gestión de cambio de tabla. Solo necesita llamar a la interfaz correspondiente y especificar el tipo de tabla, y el módulo de interfaz llamará al motor de almacenamiento correcto según el tipo de tabla para realizar el procesamiento correspondiente.
Paso 8: Cuando se procesa una consulta o un comando (éxito o fracaso), el control se devolverá al módulo del hilo de conexión. Si el procesamiento es exitoso, el resultado del procesamiento (que puede ser un conjunto de resultados o un indicador de éxito o fracaso) se retroalimenta al cliente a través del hilo de conexión. Si se produce un error durante el procesamiento, el mensaje de error correspondiente también se enviará al cliente, y luego el módulo del hilo de conexión realizará el trabajo de limpieza correspondiente y continuará esperando solicitudes posteriores, repita el proceso mencionado anteriormente o completará la desconexión del cliente. Solicitud de conexión.
Paso 9: Si en el proceso anterior, el módulo relevante hace que los datos en la base de datos cambien, y MySQL llama a la función bin-log, el módulo de procesamiento correspondiente también llamará al módulo de procesamiento de registros para actualizar la declaración de cambio correspondiente. La forma del evento se registra en el archivo de registro binario especificado por el parámetro relevante.
En el proceso de procesamiento de contenido de cada uno de los módulos anteriores, las respectivas funciones de procesamiento de computación central dependen en gran medida de todo el módulo de la API de MySQL, como la administración de memoria, E / S de archivos, procesamiento de números y cadenas, etc.
Todo el proceso anterior se muestra en la Figura 2-2: