Estados del subproceso Aurora MySQL

El subproceso comprueba si el servidor tiene los privilegios necesarios para ejecutar la instrucción.

El servidor comprueba si la consulta actual está presente en la caché de consultas.

Este es el estado final de una conexión cuyo trabajo está completo pero que el cliente no ha cerrado. La mejor solución es cerrar explícitamente la conexión en código. O bien, puede establecer un valor inferior para wait_timeout en el grupo de parámetros.

El subproceso está vaciando los datos de la tabla modificados en disco y cerrando las tablas usadas. Si no se trata de una operación rápida, verifique las métricas de consumo de ancho de banda de red con respecto al ancho de banda de red de clase de instancia. Además, verifique que los valores de los parámetros de table_open_cache y table_definition_cache permiten abrir simultáneamente suficientes tablas para que el motor no tenga que abrir y cerrar tablas con frecuencia. Estos parámetros influyen en el consumo de memoria de la instancia.

La consulta está convirtiendo una tabla temporal de en memoria a en disco. Esta conversión es necesaria porque las tablas temporales creadas por MySQL en los pasos intermedios del procesamiento de consultas crecieron demasiado grandes para la memoria. Verifique los valores de tmp_table_size y max_heap_table_size. En versiones posteriores, el nombre del estado de este subproceso es converting HEAP to ondisk.

El subproceso está convirtiendo una tabla temporal interna de una tabla en memoria a una tabla en disco.

El subproceso está procesando una instrucción ALTER TABLE. Este estado se produce después de crear la tabla con la nueva estructura, pero antes de copiar las filas en ella. Para un subproceso en este estado, puede utilizar el esquema de rendimiento para obtener información sobre el progreso de la operación de copia.

Aurora MySQL está realizando una ordenación porque no puede utilizar un índice existente para satisfacer la cláusula ORDER BY o GROUP BY de una consulta. Para obtener más información, consulte crear índice de ordenación.

El subproceso está creando una tabla permanente o temporal.

Una confirmación asíncrona en Aurora MySQL ha recibido un acuse de recibo y se ha completado.

El subproceso de Aurora MySQL ha iniciado el proceso de confirmación asíncrona, pero está a la espera de confirmación. Por lo general, es el tiempo de confirmación genuino de una transacción.

Un subproceso de trabajo de Aurora MySQL vinculado a una conexión se puede liberar mientras se envía una respuesta al cliente. El subproceso puede comenzar otro trabajo. El estado delayed send ok significa que se ha completado el acuse de recibo asíncrono al cliente.

Un subproceso de trabajo de Aurora MySQL ha enviado una respuesta asíncrona a un cliente y ahora es libre de trabajar para otras conexiones. La transacción ha iniciado un proceso de confirmación asíncrono que aún no se ha confirmado.

El subproceso ha comenzado a ejecutar una instrucción.

El subproceso ha ejecutado un comando. Parte de la liberación de elementos realizada durante este estado implica la caché de consultas. Este estado suele ir seguido de una limpieza.

Este estado se produce antes de la inicialización de las instrucciones ALTER TABLE, DELETE, INSERT, SELECT, o bien UPDATE. Las acciones en este estado incluyen vaciar el registro binario o el registro InnoDB y una limpieza de la caché de consultas.

El nodo principal ha finalizado su parte de la replicación. El subproceso está esperando que se ejecuten más consultas para poder escribir en el registro binario (binlog).

El subproceso intenta abrir una tabla. Esta operación es rápida a menos que un ALTER TABLE o una instrucción LOCK TABLE tenga que finalizar o supera el valor de table_open_cache.

El servidor está realizando optimizaciones iniciales para una consulta.

Este estado se produce durante la optimización de consultas.

Este estado se produce después de procesar una consulta, pero antes del estado de liberación de elementos.

Aurora MySQL no pudo optimizar una operación DISTINCT en la fase inicial de una consulta. Aurora MySQL debe eliminar todas las filas duplicadas antes de enviar el resultado al cliente.

El subproceso encuentra todas las filas coincidentes antes de actualizarlas. Esta etapa es necesaria si el UPDATE está cambiando el índice que utiliza el motor para buscar las filas.

El subproceso lee un evento del registro binario y lo envía a la réplica.

El servidor está tomando el resultado de una consulta de la caché de consultas y lo envía al cliente.

El subproceso está leyendo y procesando filas para una instrucción SELECT, pero aún no ha comenzado a enviar datos al cliente. El proceso identifica qué páginas contienen los resultados necesarios para satisfacer la consulta. Para obtener más información, consulte envío de datos.

El servidor está escribiendo un paquete para el cliente. En versiones anteriores de MySQL, este evento de espera estaba etiquetado writing to net.

Esta es la primera etapa al comienzo de la ejecución de la declaración.

El servidor está calculando estadísticas para desarrollar un plan de ejecución de consultas. Si un subproceso está en este estado durante mucho tiempo, es probable que el servidor esté vinculado al disco mientras realiza otro trabajo.

El servidor almacena el resultado de una consulta en la caché de consultas.

El subproceso ha llamado a mysql_lock_tables, pero el estado del subproceso no se ha actualizado desde la llamada. Este estado general se produce por muchas razones.

El subproceso se está preparando para comenzar a actualizar la tabla.

El subproceso busca filas y las está actualizando.

El subproceso emitió una llamada a GET_LOCK. El subproceso solicitó un bloqueo de aviso y lo está esperando, o planea solicitarlo.

El nodo principal ha finalizado su parte de la replicación. El subproceso está esperando que se ejecuten más consultas para poder escribir en el registro binario (binlog).

Es una espera para bloquear metadatos.

Es una espera para bloquear metadatos.

Es una espera para bloquear metadatos.

El subproceso está ejecutando FLUSH TABLES y está esperando a que todos los subprocesos cierren sus tablas. O el subproceso recibió una notificación de que la estructura subyacente de una tabla ha cambiado, por lo que debe volver a abrir la tabla para obtener la nueva estructura. Para volver a abrir la tabla, el subproceso debe esperar hasta que todos los demás subprocesos hayan cerrado la tabla. Esta notificación se lleva a cabo si otro subproceso ha utilizado una de las siguientes instrucciones de la tabla: FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, o bien OPTIMIZE TABLE.

Una sesión mantiene un bloqueo en una tabla mientras otra intenta adquirir el mismo bloqueo en la misma tabla.

Aurora MySQL utiliza el bloqueo de metadatos para administrar el acceso simultáneo a los objetos de base de datos y garantizar la coherencia de los datos. En este evento de espera, una sesión mantiene un bloqueo de metadatos en una tabla mientras otra sesión intenta adquirir el mismo bloqueo en la misma tabla. Cuando Performance Schema está habilitado, este estado de subproceso se informa como evento de espera synch/cond/sql/MDL_context::COND_wait_status.

El servidor está escribiendo un paquete para la red. En versiones posteriores de MySQL, este evento de espera está etiquetado Sending to client.