# Estados de threads do Aurora MySQL
<a name="AuroraMySQL.Reference.thread-states"></a>

Os seguintes são alguns estados de thread comuns do Aurora MySQL.

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

**checking query cache for query**  
O servidor está verificando se a consulta atual está presente no cache de consulta.

**cleaned up**  
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.

**closing tables**  
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.

**converting HEAP to MyISAM**  
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`.

**converting HEAP to ondisk**  
O thread está convertendo uma tabela temporária interna de uma tabela "na memória" para uma tabela "no disco".

**copy to tmp table**  
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.

**creating sort index**  
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](ams-states.sort-index.md).

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

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

**delayed commit ok initiated**  
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.

**delayed send ok done**  
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.

**delayed send ok initiated**  
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.

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

**freeing items**  
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.

**init**  
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.

**A origem enviou todos os logs binários à réplica; aguardando mais atualizações.**  
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).

**opening tables**  
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`.

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

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

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

**removing duplicates**  
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.

**searching rows for update**  
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.

**sending binlog event to slave**  
O thread fez a leitura de um evento do log binário e o está enviando para a réplica.

**sending cached result to client**  
O servidor está obtendo o resultado de uma consulta do cache de consultas e o enviando ao cliente.

**sending data**  
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](ams-states.sending-data.md).

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

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

**estatísticas**  
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.

**storing result in query cache**  
O servidor está armazenando o resultado de uma consulta no cache de consultas.

**system lock**  
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.

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

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

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

**waiting for more updates**  
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).

**waiting for schema metadata lock**  
Uma espera por um bloqueio de metadados.

**waiting for stored function metadata lock**  
Uma espera por um bloqueio de metadados.

**waiting for stored procedure metadata lock**  
Uma espera por um bloqueio de metadados.

**waiting for table flush**  
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`.

**waiting for table level lock**  
Uma sessão está mantendo um bloqueio em uma tabela enquanto outra sessão tenta obter esse mesmo bloqueio na mesma tabela.

**waiting for table metadata lock**  
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`.

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