É fácil começar a mexer nas engrenagens da otimização de consultas SQL. Você abre o SQL Server Management Studio (SSMS), monitora o tempo de espera, revisa o plano de execução, reúne informações do objeto e começa a otimizar o SQL até executar uma máquina bem ajustada.
Se você for bom o suficiente, você consegue uma vitória rápida e volta ao seu caos programado regularmente. Mas se você ajustar a coisa errada, ou ajustar a coisa certa na direção errada, bem, lá se foi sua quarta-feira.
Otimização de consulta SQL? O que faz você pensar que precisa?
Na maioria das vezes, é um pico de tíquetes de problemas ou reclamações de usuários. “Por que o sistema é tão lento?” seus usuários reclamam. “Está levando uma eternidade para executar nossos relatórios habituais esta semana.”
Essa é uma descrição bastante vaga, é claro. Seria bom se eles pudessem lhe dizer:“As coisas estão lentas porque você tem uma conversão implícita na linha 62 de CurrentOrderQuery5.sql. A coluna é varchar e você está passando um número inteiro.” Mas não é provável que seus usuários possam ver esse nível de detalhe.
Pelo menos tíquetes de problemas e ligações telefônicas são uma métrica ativa:fácil de detectar, fácil de medir. Quando eles começam a aparecer, você pode ter certeza de que é hora de ajustar o SQL.
Mas existem outras métricas passivas que tornam a necessidade menos clara. Coisas como queda nas vendas, o que pode ser devido a vários fatores. É porque as consultas dolorosamente lentas em sua loja online estão fazendo com que seus clientes abandonem seus carrinhos de compras? É porque a economia está em má forma?
Ou pode ser coisas como desempenho lento do SQL Server. É porque uma consulta mal escrita está enviando leituras lógicas através do telhado? É porque o servidor está com poucos recursos físicos, como memória e armazenamento?
Em ambos os cenários, a otimização de consulta SQL pode ajudar com a primeira opção, mas não com a segunda.
Por que aplicar a solução certa ao problema errado?
Antes de seguir o caminho da otimização, certifique-se de que o ajuste é a solução certa para o problema certo.
Ajustar o SQL é um processo técnico, mas cada etapa técnica tem raízes no bom senso comercial. Você pode passar dias tentando reduzir o tempo de execução em alguns milissegundos ou reduzir o número de leituras lógicas em cinco por cento, mas a redução vale o seu tempo? É verdade que é importante atender aos requisitos dos usuários, mas todo esforço chega ao ponto de retornos decrescentes eventualmente.
Considere estes problemas de desempenho de consulta SQL e o contexto de negócios em torno deles:
- Desempenho aceitável — Uma consulta leva 10 minutos para ser executada e o usuário deseja que ela seja executada em um minuto; isso parece uma disparidade razoável e uma meta alcançável para otimização. No entanto, se a consulta demorar a noite toda e o usuário achar que ela deve ser executada em um minuto, pode ser mais do que um problema de ajuste. Por um lado, você pode ter que educar o usuário sobre a quantidade de trabalho que a consulta está realmente realizando. Por outro lado, pode ser um problema com o modo como o banco de dados foi projetado ou o modo como o aplicativo cliente foi escrito.
- Utilitário — Suponha que você seja responsável por administrar o banco de dados financeiro em uma empresa de manufatura. No final de cada mês, os usuários reclamam do mau desempenho. Você rastreia o problema a uma série de relatórios de fim de mês executados pela Contabilidade que levam horas cada e vão direto para um arquivo sem serem examinados por ninguém. Em vez de ajustar, você explica o problema aos gerentes de negócios e obtém permissão para excluir os relatórios.
- Mudança de tempo — Ou suponha que esses mesmos relatórios sejam importantes para a governança, mas não urgentes para os negócios. Se eles forem executados uma vez por semana ou por mês, eles podem ser agendados para horários fora de pico, pré-armazenando em cache o conjunto de dados e enviando os resultados para um arquivo. Isso elimina o gargalo para os outros usuários de negócios e libera o usuário de Contabilidade de ter que esperar pelos relatórios.
Quando você considera o contexto de negócios em sua decisão de otimizar, pode definir prioridades e ganhar tempo.
Ao otimizar consultas SQL, experimente a diagramação SQL
O SSMS e as ferramentas integradas ao SQL Server oferecem a maior parte do que você precisa para uma otimização de consulta SQL eficaz. Combine as ferramentas com uma abordagem metódica em torno das etapas a seguir, conforme descrito no e-book “O guia fundamental para otimização de consultas SQL“:
- Monitorar o tempo de espera
- Revisar o Plano de Execução
- Reunir informações do objeto
- Encontre a mesa de direção
- Identifique os inibidores de desempenho
Na etapa 4, seu objetivo é conduzir a consulta com a tabela que retorna menos dados. Ao estudar junções e predicados e filtrar mais cedo na consulta em vez de depois, você reduz o número de leituras lógicas. Esse é um grande passo na otimização de consultas SQL.
A diagramação SQL é uma técnica gráfica para mapear a quantidade de dados nas tabelas e descobrir qual filtro retornará o menor número de registros. Primeiro, você determina quais tabelas contêm as informações detalhadas e quais tabelas são as tabelas mestre ou de pesquisa. Considere o exemplo simples desta consulta em um banco de dados de registro universitário:
A tabela de detalhes é o registro. Ele tem duas tabelas de pesquisa, aluno e classe. Para diagramar essas tabelas, desenhe uma árvore de cabeça para baixo conectando a tabela de detalhes (no topo) com setas (ou links) às tabelas de pesquisa, assim:
Agora, calcule o número relativo de registros necessários para os critérios de junção (ou seja, a proporção média de linhas relacionadas entre a tabela de detalhes e as tabelas de pesquisa). Escreva os números em cada extremidade da seta. Neste exemplo, para cada aluno há cerca de 5 registros na tabela de matrículas, e para cada turma há cerca de 30 registros em matrículas. Isso significa que nunca deve ser necessário JOIN mais de 150 (5 × 30) registros para obter um resultado para qualquer aluno ou turma.
Esse exercício é útil se suas colunas de junção não estiverem indexadas ou se você não tiver certeza de que elas estão indexadas.
Em seguida, observe os predicados de filtragem para descobrir com qual tabela conduzir a consulta. Esta consulta tinha dois filtros:um no registro cancelado =‘N’ e outro no signup_date entre duas datas. Para ver quão seletivo é o filtro, execute esta consulta no registro:
selecione count(1) do registro onde cancelado ='N'
AND r.signup_date BETWEEN :beg_date AND :beg_date +1
Ele retorna 4.344 registros do total de 79.800 registros em registro. Ou seja, 5,43% dos registros serão lidos com esse filtro.
O outro filtro está na classe:
selecione contagem(1) da classe onde nome ='INGLÊS 101'
Ele retorna dois registros de 1.000, ou 0,2 por cento, o que representa um filtro muito mais seletivo. Assim, a classe é a tabela de condução e aquela na qual você deve focar primeiro o ajuste do SQL.
A voz do usuário
Se você tem certeza de que precisa de ajuste de SQL, "O guia fundamental para otimização de consultas SQL" oferece mais informações. Ele orienta você por cinco dicas de ajuste de desempenho com consultas de copiar e colar e estudos de caso, incluindo o descrito acima.
Você provavelmente descobrirá que a ferramenta de otimização de consulta SQL mais importante é a voz do usuário. Por quê? Porque essa voz permite que você saiba quando começar a otimizar e informa quando você otimizou o suficiente. Ele pode garantir que você comece a mexer nas engrenagens quando precisar e pare enquanto ainda estiver à frente.
