Uma das melhores partes da linguagem SQL é que é fácil aprender e seguir os comandos, tudo graças à sua simples sintaxe.

Mas aqui está o senão: nem todas as funções da base de dados são eficientes. Duas consultas podem parecer semelhantes mas variam em termos de tempo de computação, e é isto que faz toda a diferença. É por isso que o ajuste fino das consultas SQL é essencial.

Se for uma organização que utiliza base de dados de produção em tempo real para efeitos de relatórios e para extrair dados actualizados, é mesmo importante optimizar as consultas SQL para evitar colocar uma carga desnecessária nos recursos da base de dados de produção.

Modos para ajustar as suas consultas SQL

Disponha um conjunto claro de requisitos empresariais antes de começar

Uma das melhores formas de optimizar as consultas SQL é fazer as coisas certas a partir do quadrado. Assim, antes de começar, certifique-se de que marcou as seguintes caixas:

Deixar reconhecer os intervenientes relevantes?

É essencial envolver todos os indivíduos e equipas relevantes enquanto desenvolve a consulta. Além disso, é mesmo importante envolver a equipa da DBA enquanto se questiona as bases de dados de produção.

Disponha os seus requisitos?

A melhor prática para assegurar que todos os seus requisitos são satisfeitos é responder a 5 conjuntos de perguntas – Quem? Porquê? Porquê? Quando? Onde?

As necessidades identificadas são específicas e ao ponto?

p>Base de dados de produção desempenha um papel crucial. A tributação da base de dados com requisitos ambíguos é demasiado arriscada. Assim, antes de executar uma consulta, certifique-se de que todos os requisitos são específicos, e discutidos com os interessados apropriados

Masterizar adequadamente a arte de criar índices

Ajuste de desempenho em SQL pode ser feito através de uma indexação adequada, o que se traduz num acesso mais rápido à base de dados durante os tempos críticos. Esta é uma área em que a maioria dos principiantes da base de dados fica aquém das expectativas. Ou tentam indexar tudo ou não indexam nada, e nenhuma destas abordagens funciona a seu favor.

Isto é porque quando não se faz qualquer indexação, as suas consultas correrão lentamente e colocarão uma carga desnecessária na base de dados. Por outro lado, se indexar tudo, os gatilhos da sua inserção não funcionarão como esperado, tornando assim a sua base de dados ineficiente. A chave aqui é atingir o equilíbrio certo.

Evite usando SELECT*

SELECT* (lido como select all) é muitas vezes usado como abreviatura para consultar todos os dados de uma tabela. Embora este método funcione bem para tabelas mais pequenas, sobrecarrega desnecessariamente os recursos da base de dados quando uma consulta é disparada sobre uma tabela com muitos campos e linhas.

A melhor maneira aqui é definir os campos na declaração SELECT para instruir a base de dados a consultar apenas os dados necessários para cumprir os objectivos finais.

Deixamos compreender melhor isto com a ajuda de um exemplo:

Aqui está uma forma ineficiente, pois esta consulta irá buscar todos os dados armazenados na tabela Utilizadores, independentemente das suas necessidades.

SELECT*

FROM Users

Esta é a forma mais eficiente de consulta, uma vez que apenas retira a informação necessária e evita que a sua base de dados fique sobrecarregada.

SELECT LastName, Address, Contact

FROM Users

Utilizar sabiamente as tabelas temporárias

Embora as tabelas temporárias sejam óptimas de utilizar, aumentam exponencialmente a complexidade de uma consulta. É altamente recomendado evitar a utilização de tabelas temporárias se o seu código puder ser escrito simplesmente.

No entanto, se precisar de lidar com um procedimento armazenado que não possa ser tratado com uma única consulta, a utilização de tabelas temporárias como intermediários pode pôr fim às suas preocupações.

Anular utilizando COUNT()

Uma das formas comuns através das quais os programadores verificam se um determinado registo existe é utilizando COUNT() em vez de EXISTS(). COUNT() é ineficiente porque analisa toda a tabela e conta todas as consultas que satisfazem a sua condição. Por outro lado, EXISTS() é mais eficiente porque sai do laço assim que detecta o resultado desejado. Isto contribui para um melhor funcionamento, e faz com que seja possível um código mais limpo.

Evite o uso de caracteres curinga no início do padrão LIKE

Para afinar as suas consultas SQL, deve evitar usar o padrão LIKE da seguinte forma:

SELECT* FROM Customers WHERE address LIKE ‘%bar%’;

Aqui, a base de dados não será capaz de usar um índice adequado se este existir devido a % de curinga. O sistema começa por realizar uma varredura completa da tabela e isto leva a uma portagem na sua velocidade. Assim, a melhor maneira de escrever esta consulta é:

SELECT* FROM Customers WHERE address LIKE ‘bar%’;

Anular usando SELECT DISTINCT

Embora se possa eliminar facilmente duplicações de uma consulta usando SELECT DISTINCT, esta função consome uma quantidade apreciável de poder de processamento. Além disso, esta consulta funciona agrupando todos os campos da consulta para apresentar resultados distintos. Isto, por sua vez, torna-a altamente imprecisa.

A melhor maneira de evitar qualquer duplicação de registos na sua consulta é adicionando mais campos. Desta forma, não haverá necessidade de agrupar, e os registos obtidos serão exactos.

Por exemplo, aqui está uma forma ineficiente de o fazer:

SELECT DISTINCT FirstName, LastName, State

FROM Users

E aqui está a forma eficiente de o fazer:

SELECT FirstName, LastName, Contact, Address, State, Zip

FROM Users

Bonus tip: Mantenha algumas consultas para os tempos fora de pico

Para garantir que a sua base de dados de produção se mantém sã e salva, é altamente recomendável programar certas consultas para os tempos fora de pico, idealmente quando o número de utilizadores simultâneos é mais baixo. Assim, a meio da noite, 3-5 da manhã. é a melhor altura para realizar consultas como:

• Looping statements
• Executar SELECT* em tabelas grandes com mais de 1 milhão de registos
• Subconsultas aninhadas
• Pesquisas de cartões selvagens
• CROSS JOINs
• SELECT DISTINCT statements

The Wrap Up

Performance tuning in SQL é importante para manter a sua base de dados saudável, mas não é a tarefa mais fácil de realizar. O desempenho das suas consultas SQL depende de uma série de factores como o modelo da sua base de dados, o tipo de informação que precisa de ir buscar e assim por diante.

É altamente recomendado evitar qualquer situação incómoda, mantendo um registo de todas as consultas que em breve serão lançadas, e fornecendo as melhores soluções. Como DBA, poderá também equipar os programadores com um painel de dados de forma a que não tenham de disparar consultas de vez em quando para ir buscar a informação essencial. Aqui está um artigo surpreendente sobre como pode criar um painel de controlo SQL que extrai dados directamente da base de dados.

Qual é a sua opinião sobre isto? Como é que afina as suas consultas SQL? Deixe-nos saber.