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 que o MySQL usa para verificar o tamanho da tabela temporária interna é a menor dos dois valores 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ários v compatíveis com o CPUs Aurora 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.