As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Ajustar sua workload de consulta
Uma workload bem ajustada ajudará você a obter uma solução estável para o hipercrescimento. Se sua workload não estiver bem ajustada, não importa a potência do cluster Amazon Aurora utilizado, haverá gargalos que degradarão a performance e afetarão a experiência do usuário da sua aplicação. A prática recomendada é ter um processo implementado desde o início que ajude a identificar e ajustar consultas problemáticas em seu sistema.
## Rastrear e ajustar consultas problemáticas em sua workload
Ao se deparar com um hipercrescimento, ter uma workload bem ajustada já é meio caminho percorrido. Para entender a natureza das workloads em tempo real e os problemas de performance que seu cluster Aurora está enfrentando, garanta que sua equipe reúna consultas problemáticas das instâncias de gravação e leitura. Essas consultas problemáticas precisam ser ajustadas para que sua workload seja executada em um estado ideal. O Amazon Aurora Edição Compatível com MySQL fornece duas maneiras de fazer isso:
+ Insights de Performance
+ Log de consultas lentas
**Usar o Performance Insights**
O Performance Insights rastreia a carga na instância de gravação ou leitura do Aurora com base na média de sessões ativas (AAS). O valor do AAS é calculado por meio de amostragem e o número de sessões ativas que estão aguardando que uma CPU pegue sua workload de consulta e a processe. O Performance Insights fornece uma interface gráfica na qual você pode verificar as instruções SQL que estão causando a maior carga por conta de esperas por sessões ativas.
Na captura de tela anterior, a chamada para o procedimento armazenado `my_sqrt` está fazendo com que uma média de 13,03 sessões aguardem o processamento de suas cargas. A próxima etapa lógica é ajustar esse procedimento. É necessário identificar instruções SQL em seus leitores e gravadores que estão causando carga em suas respectivas instâncias e ajustá-las para melhorar a performance até que os valores de AAS caiam e permaneçam abaixo da linha pontilhada máxima de vCPU no Performance Insights. Se você atingiu um limite máximo com seus esforços de ajuste e continua observando o AAS acima da linha Max vCPU, é possível selecionar uma classe de instância maior para lidar com sua workload. Não opte por uma instância maior sem antes tentar ajustar sua workload de consultas, pois o aumento do tráfego começará a expor as falhas criadas por consultas incorretas na workload.
**Usando registros de consulta lentos e publicando-os no CloudWatch**
O log de consultas lentas é um recurso nativo do MySQL que complementa o Performance Insights. A prática recomendada é usar esses dois métodos para evitar consultas problemáticas que podem causar estragos em suas instâncias. O log de consultas lentas registra qualquer consulta mais lenta do que a variável dinâmica `long_query_time`. Essa variável pode ser configurada sem que seja necessário reiniciar suas instâncias de cluster.
Para fornecer flexibilidade e isolamento no exercício de ajuste, use grupos de parâmetros separados para suas instâncias de gravação e de leitura. Isso é especialmente importante quando a divisão de leitura-gravação é usada. Estabeleça um limite confortável para `long_query_time` em suas instâncias de cluster com base em suas necessidades. Ao ajustar sua carga, você pode buscar valores agressivos na variável `long_query_time` porque você pode definir o limite no nível de milissegundos. Com alta simultaneidade e uma workload bem ajustada, quase todas as suas consultas devem ser executadas em milissegundos.
Quando você configura o Amazon Aurora Edição Compatível com MySQL para registrar consultas lentas em um arquivo, ele grava os logs de consultas lentas no sistema de arquivos do Aurora Edição Compatível com MySQL e os retém por 24 horas. Para reter os registros de consulta lentos por um período mais longo para análise, publique-os na Amazon CloudWatch. Você também pode criar um CloudWatch painel para monitorar suas consultas lentas. Para obter mais informações, consulte a postagem do blog [Criação de um CloudWatch painel da Amazon para monitorar o Amazon RDS e o Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/). Além de analisar suas consultas lentas na Amazon CloudWatch, você pode criar um perfil de registros de consultas lentas usando pt-query-digest uma ferramenta do [Percona](https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-digest.html) Toolkit.
Você também pode optar por automatizar esse processo de download e criação de perfil de consultas para maior eficiência em sua equipe. Sua equipe deve verificar as consultas que são executadas com frequência e por intervalos mais longos e priorizar seu ajuste. Procure um estado em que poucas consultas sejam registradas no log de consultas lentas e você possa reduzir o valor de `long_query_time` para se tornar mais agressivo à medida que você entende e ajusta a workload.