Análisis exhaustivo de la estructura de archivos MySQL, la arquitectura lógica y el proceso de ejecución de sql, ¿todavía tiene miedo de no entender?

1. Descripción del archivo MySQL

1.1 archivo de carpeta MySQL

Después de instalar MySQL en el servidor Linux, existen los siguientes archivos:

• auto.cnf: cada instancia de MySQL tiene una ID única

• Carpetas azules: representan bases de datos, cada base de datos corresponde a un directorio
• hostname.log: nombre de la máquina.log archivo de registro general, cerrado de forma predeterminada
• /var/log/mysqld.log: el archivo de registro de errores se configura en el archivo /etc/my.conf log-error=/var/log/mysqld.log
• ib_logfile0, ib_logfile1: rehacer rehacer archivos de registro, participar en el almacenamiento de datos
• ibdata1: archivo de datos, el tablespace del sistema se almacena en este archivo

1.2, el archivo de registro principal

1) Registro de errores (errorlog)

Está habilitado de forma predeterminada y el registro de errores no se puede desactivar desde la versión 5.5.7. El registro de errores registra todos los mensajes de error graves encontrados durante el funcionamiento, así como información detallada sobre cada inicio y apagado de MySQL.

Nombre de registro de errores predeterminado: hostname.err.

La información registrada en el registro de errores se puede definir mediante log-error y log-warnings , donde log-err define si se habilita la función del registro de errores y la ubicación de almacenamiento del registro de errores, y log-warnings es para definir si la información de advertencia también se define en el registro de errores.

#可以直接定义为文件路径，也可以为ON|OFF 
log_error=/var/log/mysqld.log 
#只能使用1|0来定义开关启动，默认是启动的 
log_warings=1 

2) Registro binario (registro bin)

Está deshabilitado de forma predeterminada y debe habilitarse a través de la siguiente configuración. :

log-bin=mysql-bin 

donde mysql-bin es el nombre base del archivo de registro binlog y el nombre completo del archivo de registro binlog: mysql-bin-000001.log

Binlog registra todas las sentencias ddl y dml en la base de datos, pero no incluye el contenido de las sentencias select. Las sentencias se almacenan en forma de eventos, describiendo el orden de los cambios de datos. Binlog también incluye la información del tiempo de ejecución de cada sentencia de actualización. Si es una declaración DDL, se registra directamente en el registro binlog, mientras que una declaración DML debe enviarse a través de una transacción para registrarse en el registro binlog.

Binlog se utiliza principalmente para implementar la replicación maestro-esclavo de MySQL, la copia de seguridad de datos y la recuperación de datos.

3) Registro de consulta general (registro de consulta general)

El registro de consultas generales está desactivado de forma predeterminada.

Dado que el registro de consultas general registra todas las operaciones del usuario, incluidas las adiciones, eliminaciones y cambios, se generará una gran cantidad de información en un entorno con grandes operaciones simultáneas, lo que generará E/S de disco innecesarias, lo que afectará el rendimiento de mysql. Si no es para depurar la base de datos, se recomienda no abrir el registro de consultas.

mysql> show global variables like 'general_log'; 

Método abierto:

#启动开关 
general_log={ON|OFF} 
#日志文件变量，而general_log_file如果没有指定，默认名是host_name.log 
general_log_file=/PATH/TO/file 
#记录类型 
log_output={TABLE|FILE|NONE} 

4) Registro de consultas lentas (registro de consultas lentas)

El valor predeterminado está desactivado.

Debe encenderse con la siguiente configuración:

#开启慢查询日志 
slow_query_log=ON 
#慢查询的阈值 
long_query_time=10 
#日志记录文件如果没有给出file_name值， 默认为主机名，后缀为-slow.log。如果给出了文件名， 但不是绝对路径名，文件则写入数据目录。 
slow_query_log_file= file_name 

Registre todas las consultas cuyo tiempo de ejecución exceda long_query_time segundos, lo cual es conveniente para recopilar sentencias SQL con mucho tiempo de consulta

Cuánto supera la consulta SQL el umbral de tiempo de consulta lento: SHOW GLOBAL STATUS LIKE '%Slow_queries%';

1.3 Archivo de datos

Tablas creadas por el motor MyIsam:

tablename.frm archivo de definición de estructura de tabla

archivo de datos tablename.MYD

archivo de índice tablename.MYI

Tablas creadas por el motor InnoDB :

tablename.frm archivo de definición de estructura de tabla

nombretabla.ibd archivo de datos y archivo de índice

2. Diagrama de arquitectura lógica

Conectores

• Conector, que se refiere a la interacción con SQL en diferentes lenguajes

Servicios de administración y utilidades

• Herramientas de gestión y control del sistema

Grupo de conexiones: grupo de conexiones

• Administre las conexiones de los usuarios y espere a que se procesen las solicitudes de conexión.
• Responsable de monitorear varias solicitudes al servidor MySQL, recibir 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 asigna (o crea) un hilo de conexión para atenderlo individualmente.
• El trabajo principal del hilo de conexión es ser responsable de la comunicación entre el servidor MySQL y el cliente, aceptar la solicitud de comando del cliente y transmitir la información del resultado del lado del servidor. El módulo de gestión de subprocesos es responsable de administrar y mantener estos subprocesos de conexión. Incluyendo creación de subprocesos, caché de subprocesos, etc.

Interfaz SQL: interfaz SQL

• Acepte el comando SQL del usuario y devuelva el resultado que el usuario necesita consultar. Por ejemplo, seleccionar de es llamar a la interfaz SQL

Analizador: Analizador

• Los comandos SQL son validados y analizados por el analizador cuando se pasan al analizador .

La función principal:

• Realice un análisis léxico y un análisis gramatical en la instrucción SQL, analícelo en un árbol de sintaxis, clasifíquelo de acuerdo con diferentes tipos de operaciones y luego envíelo a los siguientes pasos de manera específica.La transmisión y el procesamiento de la instrucción SQL en el futuro se basa en esta estructura.
• Si se encuentra un error durante el proceso de descomposición, entonces la instrucción sql no es razonable.

Optimizador: Optimizador de consultas

• La instrucción SQL utilizará el optimizador de consultas para optimizar la consulta antes de realizar la consulta . El optimizador de consultas genera el plan de ejecución de sentencias de SQL visto por la sentencia de explicación.

Caché y búfer: caché de consultas

• Su función principal es almacenar en caché el conjunto de resultados devueltos por la solicitud de selección enviada por el cliente a MySQL en la memoria, que corresponde a un valor hash de la consulta. MySQL invalidará automáticamente el caché de la consulta después de que ocurra cualquier cambio de datos en la tabla base de los datos obtenidos por la consulta. En un sistema de aplicaciones con una relación de lectura y escritura muy alta, la mejora del rendimiento de Query Cache es muy significativa. Por supuesto, también consume mucha memoria.
• Si la caché de consultas tiene un resultado de consulta de acierto, la declaración de consulta puede ir directamente a la caché de consultas para obtener datos. Este mecanismo de almacenamiento en caché consta de una serie de pequeños cachés. Como caché de tablas, caché de registros, caché de claves, caché de permisos, etc.

Motores de almacenamiento conectables: motores de almacenamiento

• A diferencia de otras bases de datos como Oracle y SQL Server, que tienen un solo motor de almacenamiento, MySQL tiene una función llamada "Arquitectura de motor de almacenamiento conectable", lo que significa que la base de datos MySQL cuenta con varios motores de almacenamiento.
• Además, el motor de almacenamiento es para tablas. Los usuarios pueden elegir diferentes motores de almacenamiento para tablas de datos según sus diferentes necesidades, y los usuarios también pueden escribir sus propios motores de almacenamiento según sus propias necesidades. Es decir, diferentes tablas en la misma base de datos pueden elegir diferentes motores de almacenamiento crear tabla xxx()engine=InnoDB/Memory/MyISAM

En resumen, un motor de almacenamiento es cómo almacenar datos , cómo crear índices para los datos almacenados y cómo actualizar y consultar datos .

3. Objeto de capa MySqlServer

3.1, proceso de ejecución de sentencias Sql

3.2 Conector

**El primer paso, primero te conectarás a esta base de datos, en este momento el conector te recibirá. Los conectores son responsables de establecer conexiones con los clientes, obtener permisos, mantener y administrar las conexiones. **El comando de conexión generalmente se escribe así:

mysql -h$ip -P$port -u$user -p

Después de ingresar el comando, deberá ingresar la contraseña en el cuadro de diálogo interactivo. Aunque la contraseña también se puede escribir en la línea de comando directamente después de -p, esto puede provocar que se filtre su contraseña. Si se está conectando a un servidor de producción, se recomienda enfáticamente que no lo haga.

El mysql en el comando de conexión es una herramienta de cliente que se utiliza para establecer una conexión con el servidor. Después de completar el protocolo de enlace TCP clásico, el conector comenzará a autenticar su identidad, esta vez utilizando el nombre de usuario y la contraseña que ingresó.

• Si el nombre de usuario o la contraseña son incorrectos, recibirá un error de "Acceso denegado para el usuario" y el programa cliente finaliza.
• Si se pasa la autenticación de nombre de usuario y contraseña, el conector verificará los permisos que tiene en la tabla de permisos. Después de eso, la lógica de juicio de permiso en esta conexión dependerá de la lectura de permiso en este momento.

Esto significa que después de que un usuario establezca una conexión con éxito, incluso si usa la cuenta de administrador para modificar los permisos del usuario, no afectará los permisos de la conexión existente. Una vez completada la modificación, solo las conexiones recién creadas utilizarán la nueva configuración de permisos.

Una vez completada la conexión, si no tiene ninguna acción de seguimiento, la conexión está en un estado inactivo, que puede ver en el comando show processlist. La figura en el texto es el resultado de show processlist, donde la columna Comando muestra la línea "Dormir", lo que significa que ahora hay una conexión inactiva en el sistema.

Si el cliente está inactivo durante demasiado tiempo, el conector lo desconectará automáticamente. Este tiempo está controlado por el parámetro wait_timeout, el valor predeterminado es de 8 horas.

Si el cliente vuelve a enviar la solicitud después de desconectar la conexión, recibirá un mensaje de error: Se perdió la conexión con el servidor MySQL durante la consulta. En este momento, si desea continuar, 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 teniendo solicitudes, siempre se usará la misma conexión. Una conexión corta significa que la conexión se desconecta cada vez que se ejecutan algunas consultas y se restablece una nueva para la siguiente consulta.

El proceso de establecer una conexión suele ser más complicado, por lo que le sugiero que minimice las acciones de establecer una conexión en uso, es decir, trate de usar una conexión larga.

Pero después de usar todas las conexiones largas, es posible que a veces la memoria ocupada por MySQL aumente muy rápido, porque la memoria utilizada temporalmente por MySQL durante el proceso de ejecución se administra en el objeto de conexión. Estos recursos solo se liberarán cuando se desconecte la conexión. Por lo tanto, si se acumulan conexiones largas, puede causar un uso excesivo de la memoria y ser eliminado por la fuerza por el sistema (OOM).A partir del fenómeno, MySQL se reinicia de manera anormal.

¿Cómo resolver este problema? Puedes considerar las siguientes dos opciones.

• Desconecte periódicamente las conexiones largas. Después de usarlo durante un período de tiempo, o después de que se considere que se ha ejecutado una consulta grande que ocupa memoria en el programa, la conexión se desconecta y luego la consulta debe volver a conectarse.
• Si está utilizando MySQL 5.7 o posterior, puede reinicializar los recursos de conexión ejecutando mysql_reset_connection después de cada operación grande. Este proceso no requiere reconexión ni reautenticación, pero restaurará la conexión al estado en el que se acaba de crear.

3.3 Consulta de caché (MySql 8.0 ha abandonado la función de caché)

Una vez establecida la conexión, puede ejecutar la declaración de selección. La lógica de ejecución llegará al segundo paso: consultar caché.

Después de que MySQL recibe una solicitud de consulta, primero irá a la caché de consultas para ver si esta declaración se ha ejecutado antes. Las declaraciones ejecutadas previamente y sus resultados pueden almacenarse en caché directamente en la memoria como pares clave-valor. La clave es el valor después del hash de la instrucción de consulta y el valor es el resultado de la consulta. Si su consulta puede encontrar la clave directamente en este caché, el valor se devolverá directamente al cliente.

Si la declaración no está en el caché de consultas, continuará con la siguiente etapa de ejecución. Una vez completada la ejecución, el resultado de la ejecución se almacenará en la caché de consultas. Puede ver que si la consulta llega al caché, MySQL puede devolver directamente el resultado sin realizar las operaciones complicadas detrás, lo cual es muy eficiente.

Pero la mayoría de las veces le aconsejaría que no use el 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 es muy fácil de invalidar. Si se modifica una tabla, se borrarán todas las cachés de consultas relacionadas con esta tabla. Para las tablas que se modifican con frecuencia, la tasa de aciertos de caché será muy baja. Por lo tanto, solo las tablas que no se modifican con frecuencia, como la tabla de configuración del sistema, son adecuadas para el almacenamiento en caché de consultas.

La caché de consultas está desactivada de forma predeterminada

show variables like 'query_cache_type'; 

Aciertos de caché de consulta

SHOW STATUS LIKE 'Qcache_hits'

Un valor de 0 o APAGADO deshabilita el uso de la memoria caché.

Un valor de 1 o ON habilita el almacenamiento en caché, excepto para las declaraciones que comienzan con SELECT SQL_NO_CACHE.

Cuando el valor es 2 o DEMAND, solo se almacenan en caché las declaraciones que comienzan con SELECT SQL_CACHE.

Debe modificar el archivo de configuración my.cnf de configuración y agregar el siguiente contenido al archivo para habilitar el caché:

query_cache_type=2 

Entonces, ¿cómo se borra el caché de consultas?

• FLUSH QUERY CACHE; // Limpiar la fragmentación de la memoria caché de consultas.
• RESET QUERY CACHE; // Elimina todas las consultas de la caché de consultas.
• FLUSH TABLES; //Cerrar todas las tablas abiertas y esta operación borrará el contenido de la caché de consultas.

Sin embargo, la versión MySQL 8.0 eliminó directamente toda la función del caché de consultas.

3.4 Analizador

Si no se alcanza la memoria caché, continúe con la ejecución de la declaración. En este momento, la declaración se analiza primero.

Esta etapa es la función del analizador analizador de MySQL y el módulo de preprocesamiento del preprocesador.

Primero, determine si la gramática del texto es correcta y luego extraiga las tablas, columnas y varias condiciones de consulta del texto, que es esencialmente el proceso de compilación de una declaración SQL, que involucra análisis léxico, análisis de sintaxis, análisis semántico y otras etapas. .

El analizador primero hará un "análisis léxico".

Es para dividir el SQL completo en cadenas:

select customer_id,first_name,last_name from customer where customer_id=14; 

Dividir en 10 cadenas:

select，customer_id,first_name,last_name，from，customer，where，customer_id， =，14 

MySQL lo reconoce por la palabra clave "select", que es una declaración de consulta que reconoce la cadena "cliente" como "nombre de tabla cliente" y la cadena "cliente_id" como "columna id_cliente".

El analizador luego hace un "análisis gramatical".

Este paso es para el resultado del análisis léxico, el analizador de sintaxis realiza una verificación de sintaxis para determinar si se ajusta a la sintaxis de MySQL.

Si la gramática es correcta, se generará un árbol de análisis de acuerdo con las reglas gramaticales definidas por MySQL:

como sql

select customer_id,first_name,last_name from customer where customer_id=14; 

preprocesador

El preprocesador verificará además si el árbol de análisis es legal, por ejemplo, si existe el nombre de la tabla, si existe la columna, etc. Al mismo tiempo, verificará si el usuario tiene permiso para operar la tabla.

3.5 Optimizador

Antes de comenzar a ejecutar SQL, también es procesado por el optimizador.

La función del optimizador de consultas es generar diferentes planes de ejecución de acuerdo con el árbol de análisis, y luego seleccionar un plan de ejecución óptimo. MySQL usa un optimizador basado en el modelo de costo, el plan de ejecución tiene el menor costo al ejecutarlo. Y es la suma de la sobrecarga de io_cost y cpu_cost, que suele ser un indicador común para evaluar la eficiencia de ejecución de una consulta.

#查看上次查询成本开销 show status like 'Last_query_cost'; 

Procesamiento de optimización por parte del optimizador:

• Cuando haya varios índices disponibles, decida qué índice usar.
• Cuando una declaración está asociada con varias tablas (unión), determine el orden de unión de cada tabla y use qué tabla como tabla de referencia.

3.6 Actuador

MySQL sabe lo que quiere hacer a través del analizador y sabe cómo hacerlo a través del optimizador y obtiene un plan de consulta. Entonces entra en la fase de ejecutor y comienza a ejecutar la declaración.

(1) Al iniciar la ejecución, primero debe juzgar si tiene el permiso para ejecutar la consulta en la tabla del cliente, de lo contrario, se devolverá un error de no permiso. (En la implementación de ingeniería, si se alcanza la caché de consultas, la verificación de permisos se realizará cuando la caché de consultas devuelva el resultado.

(2) Si tiene permiso, use el motor de almacenamiento especificado para abrir la tabla e iniciar la consulta. El ejecutor utilizará la interfaz de consulta proporcionada por el motor para extraer datos de acuerdo con la definición del motor de la tabla.

Por ejemplo, en la tabla cliente de nuestro ejemplo, el campo id_cliente es la clave principal, entonces el flujo de ejecución del ejecutor es el siguiente:

1. Llame a la interfaz del motor InnoDB para recuperar el registro con customer_id=14 del índice de clave principal.
2. La consulta equivalente del índice de clave principal solo consultará un registro y devolverá el registro directamente al cliente.

En este punto, la sentencia ha sido ejecutada.

Suponiendo que el campo customer_id no sea un índice, la consulta solo puede realizar una exploración completa de la tabla. Entonces el flujo de ejecución del ejecutor es el siguiente:

1. Llame a la interfaz del motor InnoDB para obtener la primera fila de esta tabla y determine si el valor de customer_id es 14; si no, sáltelo y, de ser así, almacene en caché esta fila en el conjunto de resultados;
2. Llame a la interfaz del motor para obtener la "fila siguiente" y repita la misma lógica de juicio hasta que se obtenga la última fila de la tabla.
3. El ejecutor devuelve al cliente un conjunto de resultados que consta de todas las filas que cumplen las condiciones en el proceso transversal anterior.

En este punto, la instrucción se ejecuta

Autor: Running Hairball
Enlace:
https://juejin.cn/post/6914301427355484174
Fuente: Nuggets