En términos generales, el ciclo de vida de una consulta puede ser más o menos en el orden de vista: desde el cliente al servidor, y luego analizar en el servidor, el plan de ejecución, ejecutar y devolver los resultados al cliente.
Tres indicadores de MySQL, el más simple de medir el costo de una consulta de la siguiente manera:
Tiempo de respuesta
El número de líneas de escaneado
Número de filas devueltas
La ejecución de la consulta subyacente:
El cliente envía una consulta al servidor.
El servidor comprueba primero la caché de consultas si una de aciertos de caché, y luego volver inmediatamente los resultados almacenados en la memoria caché. De lo contrario, proceder a la siguiente etapa.
del lado del servidor de análisis de SQL, el tratamiento previo, y luego el correspondiente plan de ejecución generada por el optimizador.
Según el plan de implementación de MySQL generada por el optimizador, la API de motor de almacenamiento llama para ejecutar la consulta.
Los resultados se devuelven al cliente.
Comprobar el estado de:
Sueño: el hilo está esperando que el cliente envíe una nueva solicitud.
Consulta: hilo está ejecutando una consulta o envía los resultados al cliente.
Bloqueado: En la capa de servidor MySQL, el hilo está esperando un bloqueo de tabla.
El análisis y estadísticas: el hilo es recoger motor de almacenamiento de información estadística, y generar un plan de ejecución de la consulta.
Copiando a tmp tabla [en el disco]: el hilo se ejecuta una consulta, y el conjunto de resultados se copian en una tabla temporal, este estado es generalmente bien hacer GROUP BY operaciones, cualquiera de los archivos de clasificación, operaciones u operaciones UNION. Si este estado allá atrás "en el disco" marca, significa que MySQL es una tabla temporal en la memoria en el disco.
Ordenando resultado: el hilo es para ordenar el conjunto de resultados.
El envío de datos: Esto representa una variedad de situaciones: hilo puede transferir datos entre una pluralidad de estados, o generar un conjunto de resultados, o los datos devueltos al cliente.
MySQL Hay dos algoritmos de ordenación:
Dos transmisiones de pedidos (versión antigua):
Leer campo de puntero de fila y necesidad de ordenar, clasificar, y luego de leer la fila de datos de acuerdo con el resultado de la clasificación deseada.
Ordenar transferencia individual (nueva versión):
En primer lugar leer todas las columnas necesarias para la consulta, y luego se ordenan de acuerdo a la columna dada, y, finalmente, regresó directamente a ordenar los resultados.
optimizador de consultas punta (pista):
LOW_PRIORITY HIGH_PRIORITY 和
Esta sugerencia le dice a MySQL, cuando varios estados accedan simultáneamente una tabla en particular, la prioridad de los cuales son declaraciones comparativamente alta prioridad que la declaración es relativamente baja.
Cuando HIGH_PRIORITY para las sentencias SELECT, MySQL será reprogramado a la mesa hasta que todos están a la espera de la cerradura para modificar los datos de esta declaración instrucción SELECT. HIGH_PRIORITY también se puede utilizar para la instrucción INSERT, el efecto es simplemente para compensar el impacto de la sentencia global ajustes LOW_PRIORITY.
LOW_PRIORITY es todo lo contrario: se hace la declaración ha estado en un estado de espera, hay largas colas necesitan tener acceso a la misma sentencia una mesa ---- incluso aquellos que la declaración que la declaración también se presentó más tarde al servidor.
Ambas ideas son válidas sólo para el uso del motor de almacenamiento bloqueo de tabla.
RETRASADO
Este consejo es válido para INSERT y REPLACE. MySQL se usa la línea de comando retorna inmediatamente al cliente, y se colocan en filas insertadas en el búfer, y luego escribe los datos en la tabla de lotes está inactivo.
STRAIGHT_JOIN
Después de este consejo se puede colocar en la palabra clave SELECT SELECT comunicado, también se puede colocar entre dos nombres de tabla asociada. La primera es hacer uso de todas las tablas de la consulta asociada con el orden en que aparecen en el comunicado. La segunda regla se asocia con una secuencia fija antes y después de las dos tablas.
SQL_SMALL_RESULT 和 SQL_BIG_RESULT
Estas dos ideas son válidas sólo para las instrucciones SELECT. Ellos dicen que el optimizador de consulta GROUP BY o DISTINCT cómo utilizar una tabla temporal y tipo. SQL_SMALL_RESULT decir al optimizador que el resultado es muy pequeña manifestación, el conjunto de resultados se puede colocar en la memoria temporal en la tabla de índices para evitar la operación de clasificación. Si SQL_BIG_RESULT, a continuación, decir al optimizador que el conjunto de resultados puede ser muy grande, se recomienda utilizar una tabla temporal para realizar operaciones de clasificación de discos.
SQL_BUFFER_RESULT
Esta sugerencia le dice a los pone optimizador de los resultados de consulta en una tabla temporal, y luego desbloquear las tablas lo más rápido posible.
SQL_CACHE suma SQL_NO_CACHE
Esta sugerencia le dice a MySQL conjunto de resultados si este debe almacenar en caché en la memoria caché de consultas.
SQL_CALC_FOUND_ROWS
Esto hará que los rendimientos de MySQL el conjunto de resultados contiene más información. MySQL consulta más la extracción inmediata del total se calculará después de la cláusula LIMIT del resultado de una consulta a devolver, pero en realidad sólo se devuelve un resultado requisitos de consigna de límite. Este valor puede ser obtenido por un FOUND_ROW función ().
ACTUALIZACIÓN DE 和 LOCK IN SHARE MODE
Esto llevó a los dos principales mecanismos de control de cierre de la instrucción SELECT, pero sólo es eficaz para lograr el motor de almacenamiento bloqueo de filas. Utilice los consejos coincidirá con las filas de bloqueo consulta.
USO INDEX, IGNORE ÍNDICE 和 FORCE INDEX
Estos consejos le dirá que el optimizador utiliza o que no utiliza un índice de registro de consulta.
En MySQL5.0 y posteriormente, añadir algunos de los parámetros que se utilizan para controlar el comportamiento del optimizador:
optimizer_search_depth
Este parámetro controla limitan el optimizador en el plan de aplicación exhaustiva.
optimizer_prune_level
Este parámetro está activado por defecto, lo que hace que el optimizador decidirá si se debe omitir algunos de los plan de implementación basado en el número de líneas que deben analizarse.
optimizer_switch
Esta variable contiene una serie de encendido / apagado de la bandera características del optimizador.