Os especialistas sabem como escrever consultas eficientes em termos de desempenho. Embora a experiência amadureça a sabedoria, há certas coisas que devemos entender pelo menos para começar. Por exemplo, você deve entender as principais considerações do design da consulta; como uma consulta é executada internamente, onde ela falha, padrões de otimização, etc. Neste artigo, fornecerei alguns pontos de otimização para refletir ao projetar uma consulta no MySQL.
Por que algumas consultas são lentas?
Um problema comum com consultas SQL é que mais dados estão sendo recuperados do que o realmente necessário. Claro, existem consultas que vasculham muitos dados e não podemos fazer muito sobre elas, mas elas não são comuns. Na maioria dos casos, é um design de consulta ruim que leva a um desempenho de consulta ruim. Após cada design de consulta, você deve fazer uma introspecção em alguns aspectos, como o que pode acontecer depois que a consulta for disparada:
- A consulta SQL acessará muitas colunas ou linhas?
- O servidor MySQL analisará muitas linhas para recuperar o resultado desejado?
Existem consultas que fazem o servidor MySQL analisar muitos dados, mas os lançam à medida que são peneirados. Este é um trabalho extra para o servidor em termos de muitos aspectos, como sobrecarga de rede, muito consumo de memória ou muito uso de recursos da CPU no servidor. A consequência é o desempenho lento.
Há situações em que você pode não ser capaz de ajudar muito durante o design, mas há uma situação em que, se você for cuidadoso e estimar a consequência e introspecção, uma consulta ruim pode pelo menos ser boa, se não melhor.
Erros típicos e suas soluções
Existem alguns erros comuns frequentemente cometidos ao escrever uma consulta. Aqui estão alguns deles. Você pode encontrar mais alguns pensamentos na mesma linha. Aqui estão os motivos para o desempenho lento da consulta com possíveis soluções.
Muitas linhas
O erro geralmente é escrever uma consulta que recupera dados e assumir que o MySQL fornecerá o resultado sob demanda enquanto ignora a quantidade de processamento necessária para retornar o conjunto de resultados completo. Suponha que uma instrução SELECT seja acionada para buscar detalhes de 100 produtos para um site de comércio eletrônico quando apenas 10 deles realmente precisam ser exibidos primeiro. Você pode pensar que o MySQL busca apenas 10 linhas e para de executar a consulta. Mas não. O que o MySQL faz é gerar o conjunto de resultados completo e alimentar o cliente. A biblioteca cliente recebe o conjunto completo e descarta a maior parte dele e retém apenas 10 dos quais procura. Isso claramente desperdiça muito recurso.
No entanto, em tal situação, você pode fornecer uma solução usando a cláusula LIMIT com a consulta.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
A cláusula LIMIT aceita um ou dois parâmetros. O primeiro especifica o deslocamento e o segundo especifica a contagem. Se apenas um parâmetro for especificado, ele denotará o número de linhas desde o início do conjunto de resultados.
Por exemplo, para selecionar 10 linhas da tabela, você pode escrever:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
E para selecionar as próximas 10 linhas, a partir do registro 11, você pode escrever:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Muitas colunas
Sempre olhe para a consulta:SELECT * com suspeita. Essa consulta retorna todas as colunas e você provavelmente precisará apenas de algumas delas. A maior desvantagem de recuperar todas as colunas é que impede a otimização ao dificultar o uso de índices, demanda muito I/O, memória e recursos de CPU do servidor.
Entenda que essa consulta universal recuperando todas as colunas pode ser um desperdício. Alguns dizem que são úteis porque permitem que o desenvolvedor use o mesmo código em mais de um lugar. Tudo bem se o custo envolvido for limitado em consideração. Às vezes, armazenar em cache os dados recuperados ajuda nesse contexto. Mas seja cauteloso, alavancar o desempenho é um trabalho elegante e esse luxo pode não ter lugar para o desempenho.
A regra geral é evitar essas consultas universais ou manter o número de colunas obtido o mínimo possível.
Excesso de análise de dados
As consultas retornam o resultado desejado, mas às vezes essas consultas são escritas de tal forma que, durante o processamento, exigem o exame de muitos dados antes de gerar resultados. Portanto, no MySQL você deve medir de acordo com as seguintes métricas de custo:
- Tempo de execução
- Linhas examinadas
- Colunas examinadas
Você pode obter uma estimativa aproximada do custo da consulta dessas métricas. Isso reflete a quantidade de acesso de dados pelo MySQL internamente para processar a consulta e a rapidez com que a consulta é executada. Como essas métricas são registradas no log de consultas lentas, é uma boa ideia investigar e encontrar consultas que analisem dados demais para retornar o resultado. O banco de dados MySQL registra todas as consultas que excedem um determinado tempo de execução no log de consultas lentas. Este é o local ideal para procurar consultas lentas e descobrir com que frequência elas são lentas.
Um log de consulta lenta normalmente está localizado em /var/log/mysql/mysql-slow.log
Observe que, pode ser necessário definir e habilitar o registro de consultas lentas em mysqld.cnf arquivo de configuração da seguinte forma.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Antes e com o MySQL 5 havia sérias limitações, especialmente a falta de suporte para registro de baixa granularidade. A única pausa foi usar patches que habilitavam o registro. No entanto, o recurso faz parte dos servidores MySQL 5.1 e posteriores como parte de seu recurso principal.
As consultas que levam muito tempo na execução não significam necessariamente que são consultas ruins. O log de consulta lenta simplesmente oferece a oportunidade de examinar o desempenho da consulta e melhorá-lo ao máximo.
Reestruturação de consultas
Como você tem a oportunidade de reestruturar consultas problemáticas, seu objetivo principal deve ser encontrar uma solução alternativa para obter o efeito que desejamos. Você pode transformar a consulta em sua forma equivalente tendo em mente o efeito interno no servidor MySQL durante o processamento.
Uma decisão no design de consulta é se devemos favorecer uma consulta complexa no lugar de várias consultas simples ou vice-versa. A abordagem convencional de projeto de banco de dados é fazer o maior número possível de trabalhos com menos consultas. O motivo é que uma consulta grande/complexa é mais econômica em termos de estabelecimento de conexão com o banco de dados. A vantagem da redução de custos em favor de consultas complexas é o uso da rede, processamento/otimização de consultas e utilização de recursos. Mas esta abordagem tradicional não se encaixa bem com o MySQL. O MySQL foi projetado para lidar com a conexão e desconexão do banco de dados rapidamente. Portanto, estabelecer a conexão, disparar muitas consultas mais simples e fechar a conexão parece mais eficiente. Recuperar dados por meio de mais de uma consulta simples no lugar de uma grande e complexa é mais eficaz. Observe que a mesma ideia pode não ser aplicada com outros bancos de dados.
Conclusão
Estas são algumas dicas rápidas para a otimização de consultas. Entenda que, conhecer as sintaxes SQL, capaz de criar uma consulta que recupere o resultado desejado não é suficiente se o objetivo for o desempenho da consulta. Compreender o que está acontecendo por trás das consultas aparentemente simples é vital para escrever uma que não apenas recupere o que é desejado, mas imbua a arte da otimização exatamente de onde tudo começa. O que acontece nos bastidores do processamento de consultas fornece uma pista importante para entender o desempenho da consulta e esse conhecimento é essencial antes de uma incursão no domínio da otimização de consultas.
