Estados de threads do Aurora MySQL

O thread está verificando se o servidor tem os privilégios necessários para executar a instrução.

O servidor está verificando se a consulta atual está presente no cache de consulta.

Este é o estado final de uma conexão cujo trabalho está concluído, mas que não foi encerrada pelo cliente. A melhor solução é encerrar a conexão explicitamente no código. Outra alternativa é definir um valor mais baixo para wait_timeout no grupo de parâmetros.

O thread está liberando os dados de tabelas alterados no disco e encerrando as tabelas utilizadas. Se esta não for uma operação rápida, verifique as métricas de consumo de largura de banda de rede em relação à largura de banda de rede da classe de instância. Verifique também se os valores dos parâmetros para table_open_cache e table_definition_cache permitem que tabelas suficientes sejam abertas ao mesmo tempo, para que o mecanismo não precise abrir e fechar tabelas com frequência. Esses parâmetros influenciam o consumo de memória na instância.

A consulta está convertendo uma tabela temporária de "na memória" para "no disco". A conversão é necessária porque as tabelas temporárias criadas pelo MySQL nas etapas intermediárias do processamento de consultas se tornaram grandes demais para a memória. Verifique os valores de tmp_table_size e max_heap_table_size. Em versões posteriores, o nome desse estado de thread é converting HEAP to ondisk.

O thread está convertendo uma tabela temporária interna de uma tabela "na memória" para uma tabela "no disco".

O thread está processando uma instrução ALTER TABLE. Esse estado ocorre após a criação da tabela com a nova estrutura, mas antes que as linhas sejam copiadas para ela. Para um thread nesse estado, é possível utilizar o Performance Schema para obter informações sobre o progresso da operação de cópia.

O Aurora MySQL está fazendo uma classificação porque não consegue utilizar um índice existente para satisfazer a cláusula ORDER BY ou GROUP BY de uma consulta. Para obter mais informações, consulte criar índice de classificação.

O thread está criando uma tabela permanente ou temporária.

Uma confirmação assíncrona no Aurora MySQL recebeu um reconhecimento e está concluída.

O thread do Aurora MySQL iniciou o processo de confirmação assíncrona, mas está aguardando reconhecimento. Em geral, esse é o tempo de confirmação autêntico de uma transação.

Um thread de operador do Aurora MySQL que está vinculado a uma conexão pode ser liberado enquanto uma resposta é enviada ao cliente. O thread pode iniciar outro trabalho. O estado delayed send ok indica que o reconhecimento assíncrono para o cliente foi concluído.

Um thread de operador do Aurora MySQL enviou uma resposta assíncrona a um cliente e está livre para trabalhar com outras conexões. A transação iniciou um processo de confirmação assíncrona que ainda não foi reconhecido.

O thread iniciou a execução de uma instrução.

O thread executou um comando. Algumas liberações de itens realizadas nesse estado envolvem o cache de consulta. Em geral, esse estado é seguido por uma limpeza.

Esse estado ocorre antes da inicialização de instruções ALTER TABLE,DELETE,INSERT,SELECT ou UPDATE. As ações nesse estado incluem liberar o log binário ou o log do InnoDB e a limpeza do cache de consulta.

O nó primário terminou sua parte da replicação. O thread está aguardando mais consultas serem executadas para poder gravar no log binário (binlog).

O thread está tentando abrir uma tabela. Essa operação é rápida, a menos que uma instrução ALTER TABLE ou LOCK TABLE precise ser encerrada ou exceda o valor de table_open_cache.

O servidor está fazendo otimizações iniciais para uma consulta.

Esse estado ocorre durante a otimização de consultas.

Esse estado ocorre após o processamento de uma consulta, mas antes do estado de liberação de itens.

O Aurora MySQL não conseguiu otimizar uma operação DISTINCT no estágio inicial de uma consulta. O Aurora MySQL precisa remover todas as linhas duplicadas antes de enviar o resultado ao cliente.

O thread está localizando todas as linhas correspondentes antes de as atualizar. Este estágio será necessário se o UPDATE estiver alterando o índice usado pelo mecanismo para localizar as linhas.

O thread fez a leitura de um evento do log binário e o está enviando para a réplica.

O servidor está obtendo o resultado de uma consulta do cache de consultas e o enviando ao cliente.

O thread está fazendo a leitura e o processamento de linhas para uma instrução SELECT, mas ainda não começou a enviar dados ao cliente. O processo está identificando quais páginas contêm os resultados necessários para atender à consulta. Para obter mais informações, consulte enviar dados.

O servidor está gravando um pacote para o cliente. Em versões anteriores do MySQL, esse evento de espera se chamava writing to net.

Este é o primeiro estágio no início da execução da instrução.

O servidor está calculando estatísticas para desenvolver um plano de execução de consultas. Se um thread estiver nesse estado por um longo tempo, o servidor provavelmente está associado ao disco durante a realização de outros trabalhos.

O servidor está armazenando o resultado de uma consulta no cache de consultas.

O thread chamou mysql_lock_tables, mas o estado desse thread não foi atualizado desde a chamada. Esse estado geral ocorre por diversos motivos.

O thread está se preparando para iniciar a atualização da tabela.

O thread está procurando linhas e as está atualizando.

O thread emitiu uma chamada GET_LOCK. O thread solicitou um bloqueio consultivo e está aguardando por ele ou está planejando solicitá-lo.

O nó primário terminou sua parte da replicação. O thread está aguardando mais consultas serem executadas para poder gravar no log binário (binlog).

Uma espera por um bloqueio de metadados.

Uma espera por um bloqueio de metadados.

Uma espera por um bloqueio de metadados.

O thread está executando FLUSH TABLES e aguardando todos os threads fecharem suas tabelas. Ou, o thread recebeu uma notificação de que a estrutura subjacente de uma tabela foi modificada e, portanto, precisa reabrir essa tabela para obter a nova estrutura. Para reabrir a tabela, o thread deve aguardar até que todos os outros threads s tenham fechado. Essa notificação ocorre quando outro thread utilizou uma das seguintes instruções na tabela: FLUSH TABLES, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE ou OPTIMIZE TABLE.

Uma sessão está mantendo um bloqueio em uma tabela enquanto outra sessão tenta obter esse mesmo bloqueio na mesma tabela.

O Aurora MySQL utiliza o bloqueio de metadados para gerenciar o acesso simultâneo a objetos de banco de dados e garantir a consistência dos dados. Nesse evento de espera, uma sessão está mantendo um bloqueio de metadados em uma tabela enquanto outra sessão tenta obter esse mesmo bloqueio na mesma tabela. Quando o Performance Schema está habilitado, esse estado de thread é indicado como o evento de espera synch/cond/sql/MDL_context::COND_wait_status.

O servidor está gravando um pacote na rede. Em versões posteriores do MySQL, esse evento de espera se chama Sending to client.