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 e a troca de partições
Remover índices não utilizados
O InnoDB
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
e 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