Orientações para ajuste de consultas - AWS Orientação prescritiva

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á.

Orientações para ajuste de consultas

Depois que você identificar consultas problemáticas em sua workload, cada consulta deverá ser ajustada. Use as orientações a seguir sobre ajuste para ajudar a executar a workload com mais eficiência.

Minimize o número de linhas verificadas

Por mais básico que pareça, esse é um ótimo conselho para usar ao ajustar consultas. Use a instrução EXPLAIN e revise a coluna de linhas para ver quantas linhas o otimizador verifica em cada união. Tente reduzir o número de linhas verificadas criando um índice ideal e, em seguida, explique novamente sua consulta para confirmar seu trabalho. Para obter mais informações, consulte a documentação do MySQL.

Se você usa tabelas particionadas, consulte-as sempre com a cláusula WHERE, a qual permite a remoção de partições para que o otimizador não precise verificar cada partição. Se a cláusula WHERE contiver uma constante para a coluna particionada, o otimizador saberá qual partição procurar e isso tornará sua consulta mais eficiente.

Outra faceta dessa recomendação é o design do seu banco de dados. Quanto menos tabelas em sua consulta, mais rápida ela será. Se você puder desnormalizar o design do banco de dados, poderá fazer com que o otimizador verifique menos linhas, o que resultará em uma melhor performance da consulta.

Minimizar uso de tabelas temporárias e tabelas temporárias em disco

O otimizador do Aurora MySQL Edição Compatível criará tabelas temporárias na RAM e no disco se não conseguir obter os resultados desejados da sua consulta diretamente dos índices. Consequentemente, uma grande parte do ajuste é ter os índices certos que atendam à workload. No entanto, pode haver consultas em sua workload que não podem depender apenas de índices. Portanto, algumas operações podem ser executadas em um arquivo temporário. Isso é bom, desde que você os mantenha no mínimo e garanta que poucas tabelas sejam criadas no disco. O MySQL cria tabelas em disco quando a tabela temporária é muito grande para ser armazenada na memória. A lógica usada pelo MySQL para verificar o tamanho da tabela temporária interna é a menor dos dois valores de variáveis tmp_table_size e max-heap-table-size. É possível ajustar essas variáveis para um valor ideal com base na sua workload para que, nos casos em que não é possível evitar tabelas temporárias, você as envie para o disco somente em raras ocasiões.

Evite classificar arquivos

Se a workload tiver muitas consultas ORDER BY, a melhor maneira de resolvê-las é usar os índices corretos em suas tabelas. Certifique-se de que seus índices de várias colunas sejam bem projetados para evitar a classificação em arquivos. A classificação não poderá ocorrer em uma coluna se as colunas anteriores não forem verificadas com constantes (in, >, <, != e BETWEEN não permitirão a classificação na próxima coluna à direita). A melhor maneira de classificar no MySQL é colocar um índice de várias colunas que posiciona as colunas que contêm valores constantes fornecidos na consulta à esquerda da coluna de classificação em uma estrutura contígua. Se, em última instância, sua consulta não conseguir retornar resultados sem uma classificação de arquivo, mova a classificação para a aplicação.

Evite executar consultas de agregação em alta simultaneidade

A workload pode ter um pequeno número de consultas de agregação para atender a algumas funcionalidades da aplicação. Esse caso de uso exige muita cautela. O mecanismo InnoDB é voltado para cargas adequadas de processamento de transações online (OLTP), mas até mesmo algumas consultas agrupadas em alta simultaneidade podem sobrecarregar a CPU e degradar rapidamente a performance do cluster. Para resolver casos de uso em que conjuntos de resultados agregados são necessários, pré-agregue os dados em tabelas prontas para leitura para que você possa evitar completamente consultas de agrupamento.

Testar as consultas quanto à simultaneidade

Ao ajustar consultas individuais, lembre-se de que essas consultas são executadas simultaneamente em várias vCPUs no Aurora Edição Compatível com MySQL. Sua consulta pode ser executada em alguns milissegundos em seu ambiente de teste em execuções únicas. Mas esse não é o quadro completo. Certifique-se de testar a consulta com o nível esperado de simultaneidade no cluster de produção e avaliar sua performance. Libere a consulta para produção somente quando ela atender às suas metas de simultaneidade. Certifique-se de usar o otimizador hint sql_no_cache em seus scripts de teste para evitar buscar resultados no cache. É possível usar ferramentas como mysqlslap para realizar o teste em simultâneo e comparar os resultados.