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 workloads de gravação
A implementação do balanceamento de carga e a liberação da instância de gravação ajudarão sua workload de gravação a apresentar uma melhor performance durante os picos mais altos. Para obter uma melhor performance de gravação em alta simultaneidade, siga estas etapas adicionais.
## Mover a integridade referencial para a camada de aplicação
Embora as verificações de integridade referencial sejam importantes, com o hiperajuste de escala elas podem ser prejudiciais à sua workload. Para cada gravação, verificações extras devem ser realizadas antes que a gravação em si seja executada, o que resulta em baixa performance. Se a aplicação exigir verificações rigorosas de integridade, integre-as na camada de aplicação para evitar que elas restrinjam suas gravações.
## Evite usar chaves primárias pesadas
Mantenha suas chaves primárias leves. O mecanismo de armazenamento InnoDB anexa a chave primária a todos os outros índices criados por você em sua tabela. Quando sua chave primária é grande, o tamanho do índice é afetado. O armazenamento e a recuperação de páginas de dados diminuirão se a chave primária for muito grande. Um exemplo comum é o uso de identificadores universalmente exclusivos como chaves primárias. Essa não é uma boa abordagem se seu objetivo é performance em um ambiente com hiperajuste de escala.
## Usar troca de partições para carregar dados em tabelas particionadas
Se você estiver gravando grandes conjuntos de dados em tabelas particionadas, a combinação entre [LOAD DATA FROM S3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html) e a [troca de partições](https://dev.mysql.com/doc/refman/5.7/en/partitioning-management-exchange.html) pode melhorar a performance porque a tabela principal não está sendo acessada para as inserções. A troca de partições envolve uma linguagem de definição de dados (DDL) e coloca um bloqueio de metadados em sua tabela. Certifique-se de que isso seja feito quando houver poucas ou nenhuma consulta em execução na tabela para que a DDL de troca de partições possa implementar o bloqueio de metadados sem esperas. A troca em si leva apenas milissegundos para ser concluída.
## Remover índices não utilizados
O [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) otimiza seus planos de consulta com base no crescimento dos dados, e é uma boa ideia verificar se há índices não utilizados em seu banco de dados e removê-los. Os índices não utilizados consomem E/S quando a aplicação grava dados em uma tabela. Verifique a lista de índices não utilizados e certifique-se de que eles não sejam índices usados em situações raras, como relatórios trimestrais. Além disso, observe que alguns índices são usados para impor exclusividade ou ordenação e também devem ser considerados.
## Garanta que as versões antigas da linha sejam limpas com eficiência
Na implementação do InnoDB do controle de simultaneidade multiversão (MVCC), quando um registro é modificado, a versão atual (antiga) dos dados que estão sendo modificados é registrada pela primeira vez como *desfazer registro* em um log de desfazer. Um valor crescente do comprimento da lista de histórico (HLL) indica que os segmentos de coleta de resíduos do InnoDB (segmentos de limpeza) não estão acompanhando a workload de gravação ou que a limpeza está bloqueada por uma consulta ou transação de longa duração. Quando a coleta de resíduos é bloqueada ou atrasada, o banco de dados pode desenvolver um atraso substancial na limpeza que pode afetar negativamente a performance da consulta. Você pode usar as recomendações a seguir para otimizar o processo de limpeza.
+ Mantenha as transações pequenas.
+ Para consultas de leitura, use o nível de isolamento READ COMMITTED.
+ Aumente o número de threads de limpeza ([innodb\_purge\_threads](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_purge_threads) e [innodb\_purge\_batch\_size](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_purge_batch_size)). Observe que o ajuste desses parâmetros requer uma reinicialização.
+ Monitore o HLL regularmente e resolva quaisquer problemas de workload que impeçam o progresso da coleta de resíduos.
## Certifique-se de que o registro em log não cause contenção adicional
O log geral de consultas registra as conexões e desconexões do cliente, bem como todas as declarações recebidas pelo servidor na ordem em que foram recebidas. Quando ativado, o registro em log é síncrono, o que pode levar a uma penalidade substancial de performance em um sistema ocupado. A menos que seja necessário, recomendamos desativar o log geral.
O log de consultas lentas registra instruções que demoraram mais do que o número de segundos [long\_query\_time](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_long_query_time) para executar com a configuração padrão de 10 segundos. Quando a configuração é definida como 0, todas as instruções são registradas de forma síncrona, o que pode levar a uma penalidade de performance em bancos de dados com muita atividade.