El pasado y el presente de una instrucción SQL

Este artículo analizará el proceso de ejecución de la próxima instrucción SQL en MySQL, incluido cómo fluirá la consulta SQL dentro de MySQL y cómo se completa la actualización de la instrucción SQL.

Análisis de infraestructura MySQL

La siguiente figura es un breve diagrama de la arquitectura de MySQL. En la siguiente figura, puede ver claramente cómo se ejecuta la instrucción SQL del usuario dentro de MySQL.

Primero, permítanme presentarles brevemente las funciones básicas de algunos componentes involucrados en la figura a continuación para ayudarlo a comprender esta imagen, y las funciones de estos componentes se presentarán en detalle más adelante.

• 连接器: La autenticación de identidad está relacionada con la autoridad (al iniciar sesión en MySQL).
• 查询缓存: Al ejecutar una declaración de consulta, primero se consultará el caché (eliminado después de MySQL 8.0, porque esta función no es muy práctica).
• 分析器: Si no se alcanza la caché, la instrucción SQL pasará a través del analizador. Para decirlo sin rodeos, el analizador primero observa lo que está haciendo su instrucción SQL y luego verifica si la sintaxis de su instrucción SQL es correcta.
• 优化器: Ejecutar según la solución óptima considerada por MySQL.
• 执行器: ejecuta la instrucción y devuelve datos del motor de almacenamiento.

En pocas palabras, MySQL se divide principalmente en la capa del servidor y la capa del motor de almacenamiento:

• Server 层: Incluyendo principalmente conectores, cachés de consultas, analizadores, optimizadores, ejecutores, etc., todosCapacidades en los motores de almacenamientoTodos están implementados en esta capa, como procedimientos almacenados, disparadores, vistas, funciones, etc., y también hay un módulo de registro general binlog.
• 存储引擎: Es el principal responsable del almacenamiento y la lectura de datos. Adopta una arquitectura de complemento reemplazable y es compatible con múltiples motores de almacenamiento como InnoDB, MyISAM y Memory. El motor InnoDB tiene su propio módulo de registro, módulo redolog. El motor de almacenamiento más utilizado es InnoDB, que se ha utilizado como motor de almacenamiento predeterminado desde MySQL 5.5.

Luego, echemos un vistazo a las funciones específicas de estos componentes en la capa del servidor:

• Conector

  • Los conectores se relacionan principalmente con funciones relacionadas con la autenticación de identidad y los permisos, al igual que un controlador de acceso de alto nivel.
  • Es principalmente responsable del inicio de sesión del usuario en la base de datos y la autenticación de la identidad del usuario, incluida la verificación de las contraseñas de la cuenta, los permisos y otras operaciones. Si la contraseña de la cuenta del usuario ha pasado, el conector consultará todos los permisos del usuario en la tabla de permisos, y luego el juicio lógico de los permisos en esta conexión dependerá de los datos de permisos leídos en este momento. Es decir, siempre que la conexión no se desconecte más tarde, incluso si el administrador modifica los permisos del usuario, el usuario no se verá afectado .

• Caché de consultas (eliminado después de MySQL 8.0)

  • La caché de consultas se utiliza principalmente para almacenar en caché la declaración SELECT que ejecutamos y el conjunto de resultados de la declaración. Una vez que se establece la conexión, cuando se ejecuta la declaración de consulta, primero se consultará el caché. MySQL primero verificará si el SQL se ha ejecutado y lo almacenará en caché en la memoria en forma de clave-valor. La clave es la estimación de la consulta y el valor es el conjunto de resultados. Si se presiona la clave de caché, se devolverá directamente al cliente. Si no se presiona, se realizará la operación posterior y el resultado se almacenará en caché después de la finalización para la conveniencia de la próxima llamada. Por supuesto, cuando la consulta de caché se ejecuta realmente, los permisos del usuario aún se verifican para ver si existen condiciones de consulta para la tabla.
  • No se recomienda utilizar la memoria caché para consultas de MySQL, ya que la invalidación de la memoria caché de consultas puede ser muy frecuente en escenarios empresariales reales. Si actualiza una tabla, se borrarán todas las memorias caché de consultas de esta tabla. Para los datos que no se actualizan con frecuencia, aún es posible usar un caché. Por lo tanto, en la mayoría de los casos, no recomendamos utilizar el almacenamiento en caché de consultas. La función de almacenamiento en caché se eliminó después de MySQL 8.0 Los funcionarios también creen que esta función rara vez se usa en escenarios de aplicaciones reales, por lo que simplemente la eliminaron directamente.

• Analizador

  • Si MySQL no accede a la memoria caché, entrará en el analizador. El analizador se utiliza principalmente para analizar para qué sirve la instrucción SQL. El analizador también se dividirá en varios pasos:
    • El primer paso es el análisis léxico . Una declaración SQL consta de varias cadenas. Primero, se deben extraer palabras clave, como seleccionar, la tabla que se consultará, nombres de campo, condiciones de consulta, etc. Después de completar estas operaciones, ingresará al segundo paso.
    • El segundo paso, el análisis de sintaxis , consiste principalmente en juzgar si el SQL que ingresa es correcto y se ajusta a la sintaxis de MySQL.
  • Después de completar estos dos pasos, MySQL está listo para comenzar la ejecución, pero ¿cómo ejecutar y cómo ejecutar es el mejor resultado? En este momento, se necesita el optimizador.

• optimizador

  • El papel del optimizador es ejecutar lo que cree que es el mejor plan de ejecución (a veces puede no ser el mejor, este artículo implica una explicación detallada de esta parte del conocimiento), como elegir un índice cuando hay varios índices, cómo elegir el orden de asociación al consultar varias tablas, etc.
  • Se puede decir que después de pasar por el optimizador, se puede decir que se ha determinado la ejecución específica de esta instrucción.

• Solenoide

  • Cuando se selecciona el plan de ejecución, MySQL está listo para comenzar la ejecución. Primero, verificará si el usuario tiene permiso antes de la ejecución. Si no hay permiso, se devolverá un mensaje de error. Si hay permiso, llamará a la interfaz del motor y devolverá el resultado de la ejecución de la interfaz.

análisis de oraciones

Busca frases

Habiendo dicho tanto anteriormente, ¿cómo se ejecuta una declaración SQL? De hecho, nuestro SQL se puede dividir en dos tipos, uno es de consulta y el otro es de actualización (agregar, modificar, eliminar). Analicemos primero la declaración de consulta, la declaración es la siguiente:

select * from tb_student  A where A.age='18' and A.name=' 张三 ';

Combinado con la descripción anterior, analizamos el flujo de ejecución de esta declaración:

• Primero verifique si la declaración tiene permiso. Si no hay permiso, se devolverá un mensaje de error directamente. Si hay permiso, antes de la versión MySQL8.0, primero se consultará el caché, y esta declaración SQL se usa como clave para consultar si hay un resultado en la memoria. Si hay un caché directo, si no, vaya al siguiente paso.

• Realice un análisis léxico a través del analizador para extraer los elementos clave de la declaración SQL. Por ejemplo, la declaración anterior se extrae como una selección de consulta, y el nombre de la tabla que se consultará es tb_student, y todas las columnas deben consultarse. La condición de consulta es el id = '1' de esta tabla. Luego, juzgue si la declaración SQL tiene errores gramaticales, como si las palabras clave son correctas, etc. Si no hay ningún problema en la verificación, vaya al siguiente paso.

• El siguiente paso es que el optimizador determine el plan de ejecución.La instrucción SQL anterior puede tener dos planes de ejecución:

  • Primero consulte al estudiante cuyo nombre es "Zhang San" en la tabla de estudiantes y luego determine si la edad es 18.
  • Primero busque a los estudiantes que tienen 18 años entre los estudiantes y luego consulte a los estudiantes cuyo nombre es "Zhang San".

• Luego, el optimizador elige una solución con la mejor eficiencia de ejecución de acuerdo con su propio algoritmo de optimización (el optimizador cree que a veces no es necesariamente la mejor). Luego, después de confirmar el plan de ejecución, está listo para comenzar la ejecución.

• Realice la verificación de permisos, si no hay permiso, se devolverá un mensaje de error, si hay permiso, se llamará a la interfaz del motor de la base de datos y se devolverá el resultado de ejecución del motor.

declaración de actualización

Lo anterior es el proceso de ejecución de una consulta SQL, así que veamos cómo se ejecuta una declaración de actualización. La sentencia SQL es la siguiente:

update tb_student A set A.age='19' where A.name=' 张三 ';

Modifiquemos la edad de Zhang San. De hecho, esta declaración básicamente sigue el proceso de la consulta anterior, pero al ejecutar una actualización, debe registrar un registro, que introducirá un módulo de registro. El módulo de registro que viene con MySQL es binlog (registro de archivo), que puede ser utilizado por todos los motores de almacenamiento. Nuestro motor InnoDB de uso común también viene con un módulo de registro redo log (registro de redo). Analicemos el proceso de ejecución de esta declaración en modo InnoDB. El proceso es el siguiente:

• Primero consulte los datos de Zhang San, si hay un caché, también usará el caché.
• Luego obtenga la declaración de consulta, cambie la edad a 19 y luego llame a la interfaz API del motor para escribir esta línea de datos. El motor InnoDB guarda los datos en la memoria y registra el registro de rehacer al mismo tiempo. En este momento, el registro de rehacer ingresa al estado de preparación y luego le dice al ejecutor que la ejecución se completó y se puede enviar en cualquier momento.
• Después de que el ejecutor recibe la notificación, registra el binlog, luego llama a la interfaz del motor y envía el registro de rehacer como estado de envío.
• actualización completada.

¿Por qué usar dos módulos de registro aquí? ¿No podemos usar un módulo de registro?

Esto se debe a que MySQL no tenía un motor InnoDB al principio (el motor InnoDB fue insertado en MySQL por otras compañías en forma de complemento). El motor integrado de MySQL es MyISAM, pero sabemos que el registro de rehacer es exclusivo del motor InnoDB y otros motores de almacenamiento no lo tienen.

No es que sea imposible usar solo un módulo de registro, pero el motor InnoDB admite transacciones a través del registro de rehacer. Luego, algunos estudiantes volverán a preguntar, uso dos módulos de registro, pero no es tan complicado, ¿por qué el registro de rehacer debería introducir el estado de preparación previa al envío? Aquí usamos el método de contra-evidencia para explicar por qué hacemos esto.

• Primero escriba el registro de rehacer y envíelo directamente, y luego escriba el binlog . Suponiendo que después de escribir el registro de rehacer, la máquina se cuelga y el registro de binlog no se escribe, luego de que la máquina se reinicie, la máquina restaurará los datos a través del registro de rehacer, pero el binlog no registra los datos en este momento. Cuando se haga una copia de seguridad de la máquina más tarde, esta información se perderá y la sincronización maestro-esclavo también perderá esta información.
• Escriba el binlog primero y luego escriba el registro de rehacer . Suponga que la máquina se reinicia de forma anormal después de escribir el binlog. Dado que no hay un registro de rehacer, la máquina no puede recuperar este registro, pero hay otro registro en el binlog. Entonces, la misma razón que la anterior causará inconsistencia en los datos.

Si se utiliza el método de confirmación de dos fases del registro de rehacer, es diferente.Después de escribir el binlog y luego enviar el registro de rehacer, evitará que ocurran los problemas anteriores, lo que garantiza la coherencia de los datos. Entonces la pregunta es, ¿hay una situación extrema? Suponiendo que el registro de rehacer se encuentra en el estado previo a la confirmación y que se ha escrito el binlog, ¿qué sucederá si se produce un reinicio anómalo en este momento? Esto depende del mecanismo de procesamiento de MySQL.El proceso de procesamiento de MySQL es el siguiente:

• Al juzgar si el registro de rehacer está completo, si se considera que está completo, envíelo de inmediato.
• Si el registro de rehacer solo se envía previamente pero no está en el estado de confirmación, juzgará si el binlog está completo en este momento. Si está completo, se enviará el registro de rehacer y, si no está completo, la transacción se revertirá.

Esto resuelve el problema de la consistencia de los datos.

Resumir

Resumamos:

• MySQL se divide principalmente en la capa del servidor y la capa del motor. La capa del servidor incluye principalmente conectores, cachés de consulta, analizadores, optimizadores y ejecutores. También hay un módulo de registro (binlog). Este módulo de registro puede ser compartido por todos los motores de ejecución. Redolog solo está disponible en InnoDB.
• La capa del motor es un complemento, que actualmente incluye principalmente MyISAM, InnoDB, Memory, etc.
• El flujo de ejecución de la declaración de consulta es el siguiente:权限校验（如果命中缓存）--->查询缓存--->分析器--->优化器--->权限校验--->执行器--->引擎
• El flujo de ejecución de la declaración de actualización es el siguiente:分析器---->权限校验---->执行器--->引擎---redo log(prepare 状态)--->binlog--->redo log(commit 状态)