Todos os produtos
Search
Central de documentação

ApsaraDB RDS:Alto número de threads ativas no ApsaraDB RDS for MySQL

Última atualização: Oct 14, 2026

Este tópico descreve as causas de um alto número de threads ativas em uma instância do ApsaraDB RDS for MySQL e fornece soluções.

Informações de contexto

O número de threads ativas (também conhecidas como conexões ativas) é uma métrica fundamental para medir a carga de trabalho de uma instância MySQL. Em uma instância saudável, o número de threads ativas costuma ser inferior a 10. Para instâncias de alta especificação e alto QPS, esse número pode chegar a 20 ou 30. Se a contagem atingir centenas ou até milhares, isso indica que as consultas SQL estão se acumulando e os tempos de resposta aumentam. Em casos graves, a instância pode parar de responder e deixar de processar solicitações SQL.

Verificar threads ativas

O console do ApsaraDB RDS fornece vários métodos para visualizar o número de threads ativas:

  • Monitoramento e alertas

    Na página Monitoring and Alerts do console, clique na guia Standard Monitoring e, em seguida, clique em Standard View para visualizar as métricas de threads ativas da instância.

  • Database Autonomy Service (DAS)

    Na página Autonomy Services > Dashboard do console, clique na guia Dashboard para visualizar o status de conexão das sessões. Se o número de threads for muito alto, isso indica que as sessões da instância estão bloqueadas.

Acúmulo de SQL lento

  • Sintoma

    Se o monitoramento mostrar um aumento nas threads ativas, execute primeiro o comando show processlist; para verificar se há consultas SQL lentas. Um grande número de consultas que varrem muitas linhas costuma causar o aumento do número de threads ativas.

    Visualize as informações sobre SQL lento na página Autonomy Services > Slow SQL no console.

  • Resolução

    Use o recurso SQL throttling ou encerre as sessões para reduzir o impacto das consultas SQL lentas.

Problemas no cache de tabelas

  • Sintoma

    Se o cache de tabelas for insuficiente, um grande número de instruções SQL permanece no estado Opening table. Isso geralmente ocorre quando o QPS é alto ou quando há um grande número de tabelas.

  • Resolução

    Aumente os valores do parâmetro table_open_cache (não requer reinicialização da instância) e do parâmetro table_open_cache_instances (requer reinicialização da instância).

Problemas de bloqueio de metadados (MDL)

  • Sintoma

    Quando ocorre um bloqueio de metadados (MDL), um grande número de consultas SQL entra no estado Waiting for table metadata lock. Durante as fases prepare e commit, uma instrução DDL deve adquirir um MDL. Se a tabela tiver transações não confirmadas ou consultas SQL lentas, a operação DDL será bloqueada. Isso, por sua vez, bloqueia outras consultas SQL e, eventualmente, aumenta o número de threads ativas.

  • Resolução

    Para resolver esse problema, encerre as transações não confirmadas, as consultas SQL lentas ou a instrução DDL em execução.

Conflitos de bloqueio de linha

  • Sintoma

    Um aumento nas métricas innodb_row_lock_waits e innodb_row_lock_time indica conflitos de bloqueio de linha.

    Na página Autonomy Services > Dashboard do console, clique na guia Dashboard para visualizar os itens de monitoramento em row lock.

  • Resolução

    Execute o comando show engine innodb status; para verificar se um grande número de sessões está no estado Lock wait. Se sim, a contenção de bloqueio de linha é grave. Para reduzir a contenção, otimize as atualizações de hotspots, diminua o tamanho das transações e confirme as transações rapidamente.