Novela: soy un DQL

El diagrama de flujo de ejecución de SQL es el siguiente:
Novela: soy un DQL
este artículo está adaptado de "High Performance Mysql", y Yan Ge usa la forma de una novela para hablar sobre este contenido.

El prólogo
me presenta . Soy un SQL, solo una cadena larga. No me pregunten cómo me veo, porque soy más arrogante.
Novela: soy un DQL
Um ~~ No es que no lo diga, porque en detalle, puedo subdividir en DML (Actualizar, Insertar, Eliminar), DDL (modificación de la estructura de la tabla), DCL (operación de permiso), operación DQL (Seleccionar), uno por uno Preséntate, ¡me temo que no agradaré a nadie!
Bueno, todo el mundo no tiene ningún comentario. Continuaré presentándome ~
Debido a los muchos tipos, aquí solo soy una consulta SQL, que es un DQL.
El cliente me envía al servidor de acuerdo con el protocolo de comunicación Mysql.
Cuando llegue al servidor, lo ejecutaré en un hilo separado. El servidor debe primero ...
Novela: soy un DQL
Nunca esperé que me interrumpieran de nuevo ~ bueno, porque estoy ejecutando en un hilo, debe haber una forma de ver el estado de ejecución del hilo. Mysql proporciona los siguientes comandos para que todos los revisen

SHOW [FULL] PROCESSLIST

El resultado es la
Novela: soy un DQL
columna Comando en la figura siguiente , que refleja el estado de ejecución actual de este hilo. Durante la ejecución de este hilo, el estado cambiará muchas veces.
En la imagen, hay un Sleep, que le dice que el hilo está esperando que el cliente envíe una nueva solicitud. También hay una consulta, que representa que el hilo está ejecutando una consulta o enviando los resultados al cliente.
En cuanto a los demás, hay Bloqueado, Enviando datos, etc., que respectivamente representan ...
Novela: soy un DQL
Uh, está bien, muchas molestias, la casa grande no me molesta, eh, en cuanto al significado de otros estados, puedes ir Consulta en el sitio web oficial de Mysql.
Bueno, volvamos al tema de ahora. Después de llegar al servidor, Mysql tiene que juzgar si mis primeros 6 personajes están seleccionados.
Además, la declaración no contiene la palabra clave SQL_NO_CACHE y, si se cumplen las condiciones, ingresa a la caché de consultas.

En el primer capítulo,
hablé de la caché de consultas, que en realidad es una tabla hash. Las declaraciones ejecutadas y sus resultados se almacenarán directamente en la memoria caché en forma de pares clave-valor.
Su clave es un valor hash, que se genera al consultar SQL (es decir, yo), la base de datos actual a consultar, la versión del protocolo del cliente, etc., y su valor es naturalmente el resultado de la consulta.

Por supuesto, si quiero omitir la caché de consultas, también es muy simple. Puedo escribir así:

Select SQL_NO_CACHE * from table

También puede establecer el parámetro query_cache_type en DEMAND para omitir la caché de consultas.

Sin embargo, un día, el caché de consultas me dijo con tristeza: "Nunca me volverás a ver en el futuro. Me ha eliminado el historial. ¡La versión Mysql 8.0 ya no me tendrá!" Después de
escuchar esta noticia, aparecí en la superficie. Fingir ser fuerte y decirle al caché de consultas: "¡No seas cuadrado, todos te extrañarán!"
Sin embargo, lo que realmente pensé fue: "¡Oye, haces trampa, finalmente ya no existe!" No creas que soy demasiado malvado Después de todo, el almacenamiento en caché de consultas no es realmente fácil de usar. A continuación, hablemos del analizador ...
Novela: soy un DQL
Nunca pensé que quería engañarlo. El resultado ... bueno, volvamos al tema, porque

  • Siempre que haya una actualización de una tabla, todas las cachés de consultas en esta tabla se vaciarán
  • Cualquier diferencia en los caracteres SQL, como espacios, comentarios, provocará errores de caché

Por lo tanto, puedo pensar en consultar la tabla en caché en un solo caso, y esa es la tabla de configuración. Otras tablas de negocios simplemente no pueden aprovechar las características del almacenamiento en caché de consultas. Quizás el equipo de Mysql también sintió que el uso del almacenamiento en caché de consultas era demasiado limitado, por lo que lo eliminaron sin piedad.

El segundo capítulo del amor y el odio entre el analizador y yo
(este artículo se refiere al analizador y al preprocesador como analizador)
decía que después de salir de la caché de consultas, entro en el analizador.
Parser: "Vamos, déjame analizarte léxicamente y decirme cómo te ves"
. Soy así

select username from userinfo

Analizador: "Está bien, está bien, está bien. Tengo dos etapas. Primero realizaré un análisis léxico en usted. Lo ingresaré carácter por carácter de izquierda a derecha, y luego reconoceré las palabras de acuerdo con las reglas de formación de palabras. Genere 4 tokens como se muestra a continuación ".

Palabra clave sin palabra clave palabra clave sin palabra clave
seleccione nombre de usuario del
analizador de información de usuario : "A continuación, realice un análisis gramatical para determinar si la declaración SQL que ingresó cumple con la gramática MySQL. Luego, genere el siguiente árbol de sintaxis".
Novela: soy un DQL

Yo: "¿Qué pasa si la sintaxis es incorrecta?"
Analizador: "¡Entonces recibirá un mensaje de la siguiente manera!"

You have an error in your SQL syntax

Analizador: "¡Después de generar con éxito el árbol gramatical, te enviaré al preprocesador!"
Preprocesador: "¡Hermano, puedes hacerlo!"
Yo: "¡Sí!"
Preprocesador: "Hermano, te ayudaré Verifique si el nombre de su columna es correcto y si esta columna está realmente en esta tabla en la base de datos. Verifique si el nombre de la tabla es correcto, si no, verá el siguiente error ".

Unknown column xxx in ‘where clause’

Preprocesador: "Finalmente, lo enviaré para que realice la verificación de permisos. Si no tiene permiso para operar esta tabla, se informará del siguiente error".

ERROR 1142 (42000): SELECT command denied to user 'root'@'localhost' for table 'xxx'

(En este lugar, es posible que tenga preguntas, porque algunos artículos dicen que la verificación de autoridad la realiza el ejecutor, puede tirarla directamente al final de este artículo para ver la explicación)

Finalmente, este árbol de sintaxis se pasará al optimizador.

Capítulo 3 El pasado con el optimizador
Después de despedirme del analizador, entré en el optimizador.
El hermano optimizador: "Dime, ¿cómo te ves?"
Le dije: "No te preocupes, me veo así ~" (La optimización aquí debería ser en realidad el árbol de sintaxis. Solo uso SQL como explicación. Como ejemplo, en realidad está optimizado para el árbol de sintaxis)

select t1.*
from Table1 t1
inner join Table2 t2
on t1.CommonID = t2.CommonID

Optimizador hermano: "Mi tarea es ayudarlo a juzgar cómo ejecutar más rápido, como primero verificar Table1 y luego Table2, o verificar Table2 y luego Table1? Después de juzgar cómo ejecutar, ¡simplemente genere un plan de ejecución!"
Dije con desconfianza: "¡Eh, no cometas un error de juicio!" El
hermano optimizador: "Entonces tienes que reescribir el SQL. Por ejemplo, si traes la palabra clave STRAIGHT_JOIN, se verá así".

select t1.*
from Table1 t1
STRAIGHT_JOIN  Table2 t2
on t1.CommonID = t2.CommonID

"Entonces sé que es obligatorio encontrar Table1 y luego encontrar Table2 en asociación. Hay muchos ejemplos similares, ¡así que no los enumeraré uno por uno!"
(La función STRAIGHT_JOIN es similar a join, pero la tabla de la izquierda puede impulsar la tabla de la derecha. Puede cambiar el orden de ejecución del optimizador de tablas para la consulta de la tabla de unión).

Dije: "¡Vaya, cómo escribir un SQL eficiente es realmente una ciencia!"
Entonces, el hermano optimizador me convirtió en un plan de ejecución, y luego se lo dio al ejecutor ~

Capítulo 4 Mi trágica experiencia con el ejecutor
I: "Hermano ejecutor, ¿qué usas para ello?" El
ejecutor: "ejecuta la consulta de acuerdo con el plan de ejecución. Voy a llamar a la capa inferior una a una según tus instrucciones. Motor de almacenamiento, paso a paso ".
MySQL define una serie de API de motor de almacenamiento abstracto para admitir la arquitectura del motor de almacenamiento enchufable. Mysql implementa una capa de interfaz abstracta llamada handler (sql / handler.h), que define funciones de interfaz, como ha_open, ha_index_end, ha_create, etc. El motor de almacenamiento necesita implementar estas interfaces para ser utilizadas por el sistema.

Algunas emociones en el
último capítulo En la última etapa, Mysql devolverá los resultados de la consulta al cliente.
Lo único que debe explicarse es que si es un tipo SELECT de SQL, Mysql almacenará en caché los resultados de la consulta. En cuanto al otro SQL, se
vaciará la tabla relacionada con la caché de consultas.

Algunas preguntas
, es posible que tenga algunas preguntas sobre en qué etapa se realiza la verificación del permiso.
Había un gran artículo que decía que la verificación de permisos está en la etapa de ejecución. Verifique los permisos antes de la ejecución. Si ha leído este artículo, es posible que tenga preguntas. No estoy cuestionando a la gente al azar, después de todo, soy solo un pequeño café. Solo estoy aquí para expresar mis propios argumentos y todos pueden hacer comentarios.

Argumento 1: La verificación de permisos en el ejecutor no tiene sentido lógicamente
Una consulta SQL pasa por el caché de consultas, el analizador, el optimizador y el ejecutor. Si encuentra que los permisos son insuficientes en la última etapa del ejecutor, entonces la serie anterior de procesos no se hace en vano, Mysql no debería ser tan estúpido ~

Argumento 2: No coincide con el contenido del
libro "High Performance Mysql" . Hay una oración en la página 209 del libro, como se muestra en la figura siguiente.
Novela: soy un DQL
El libro también especifica que la verificación de permisos se realiza en el preprocesador. En este artículo, el preprocesamiento y el analizador se unifican en la categoría de analizador.

Argumento 3: El código fuente no coincide.
Miré el código fuente de Mysql5.7.25. El código central para procesar la consulta es el siguiente.
En el archivo sql_parse.cc, hay un fragmento de código como sigue

case SQLCOM_SELECT:
 {
    //省略
    res= select_precheck(thd, lex, all_tables, first_table);
    if (!res)
      res= execute_sqlcom_select(thd, all_tables);
    //省略
  }

Entre ellos, select_precheck es para la verificación de permisos. El optimizador y el ejecutor están en el método execute_sqlcom_select.
Por supuesto, todo el mundo tiene nuevas ideas, bienvenido a dejar un mensaje.

Supongo que te gusta

Origin blog.51cto.com/1991785/2543288
Recomendado
Clasificación