O baixo desempenho do banco de dados é um espinho no lado de cada DBA. E nem sempre é fácil isolar a causa raiz dos problemas de desempenho, o que só aumenta o estresse.
Ajustar seus bancos de dados SQL Server é uma ótima maneira de resolver alguns de seus problemas de desempenho, mas nem sempre é óbvio onde você deve iniciar o processo de otimização. Se você descartar espaço em disco, memória e outros assassinos de desempenho de rede e hardware, e o desempenho do SQL Server ainda estiver atrasado, é hora de investigar suas consultas.
As consultas não otimizadas podem causar inúmeros problemas de desempenho para seus sistemas. Pelo lado positivo, alguns erros comuns de consulta são responsáveis pela maior parte da degradação do desempenho do banco de dados.
Se suas consultas sofrerem de algum desses seis problemas, prepare-se para um ajuste sério de desempenho.
Consulta de problema nº 1:expressões semelhantes com curingas iniciais
Os principais curingas impedem o MySQL de utilizar índices, forçando uma varredura completa da tabela, mesmo que você tenha indexado um campo dentro da tabela. A verificação de todas as linhas em uma tabela diminui significativamente a entrega dos resultados da consulta, portanto, elimine o caractere curinga principal para melhorar a eficiência.
Consulta de problema nº 2:colunas não indexadas usadas nas cláusulas "Onde" e "Agrupar por"
A indexação de colunas ajuda a retornar os resultados da consulta mais rapidamente porque elimina a necessidade de verificações completas de tabela. A indexação também ajuda a classificar os registros quando eles são retornados e garante que esses registros sejam exclusivamente identificáveis, o que é particularmente útil em tabelas com mais de 10 linhas.
Para um pouco de perspectiva, considere executar uma instrução “explain” em sua análise de consulta antes e depois da indexação. Isso lhe dará uma ideia de quantas linhas de digitalização você acabou de salvar.
Consulta de problema nº 3:declarações semelhantes que usam o operador 'or' em vez de uma cláusula de união
Executar consultas usando o operador de comparação “ou” em campos ou colunas em uma tabela pode ser útil, mas aplicar “ou” com muita frequência em uma cláusula “onde” é outro caminho rápido para uma verificação completa da tabela.
Uma cláusula de união pode tornar a consulta SQL mais rápida, especialmente se diferentes índices estiverem otimizando cada lado da consulta. Essencialmente, o operador de união pega os resultados de duas consultas rápidas e indexadas e as mescla em uma.
Consulta de problema nº 4:pesquisas com curinga
Se você está preso em uma situação em que precisa pesquisar com curingas, mas não deseja reduzir o desempenho, tente usar uma pesquisa de texto completo do MySQL. As pesquisas de texto completo são consideravelmente mais rápidas do que a pesquisa com caracteres curinga, e você obtém o benefício adicional de resultados mais relevantes ao pesquisar bancos de dados enormes.
Consulta de problema nº 5:esquema de banco de dados não otimizado
Você só pode melhorar o desempenho da consulta SQL se também não otimizar seu esquema de banco de dados. Aqui estão algumas dicas para melhorar:
Normalizar tabelas
A redundância de dados prejudica o desempenho, portanto, certifique-se de representar um fato apenas uma vez no banco de dados. Por exemplo, se fizer referência a um cliente em mais de uma tabela, use apenas “customer_name” uma vez e, em seguida, use “customer_ID” para referências subsequentes.
Use tipos de dados ideais
Alguns pontos importantes a serem lembrados quando se trata de tipos de dados:
- Menor é melhor ao projetar tabelas. Por exemplo, use o tipo de dados “TINYINT” para o campo “user_id” para uma tabela de usuários do sistema com menos de 100 usuários.
- Use um tipo de dados "date_time" se um campo espera um valor de data para que você não precise converter os registros para o formato de data após o fato.
- O MySQL funciona melhor com valores inteiros do que com tipos de dados de texto, incluindo varchar.
Evite valores nulos
Valores nulos em uma coluna podem prejudicar os resultados da consulta, portanto, talvez seja necessário atribuir um valor padrão para campos em que os registros não exigem um valor obrigatório.
Não use muitas colunas
Tabelas largas (mais de 100 colunas) requerem muita CPU e recursos para serem processadas. A menos que você absolutamente precise incluir uma tabela ampla, é melhor dividi-la em tabelas menores e lógicas.
Otimizar associações
Instruções SQL com muitas junções (e junções com muitas tabelas) afetam negativamente o desempenho. Atire para não mais de 12 junções para cada consulta.
Consulta de problema nº 6:consultas MySQL sem cache
Sites e aplicativos que realizam muitas consultas selecionadas se beneficiarão do armazenamento em cache de consultas MySQL. O cache de consulta do MySQL acelera o desempenho durante as operações de leitura porque ele armazena em cache a consulta selecionada junto com o conjunto de dados resultante e busca da memória (não do disco) se a consulta for executada mais de uma vez.
O ajuste de desempenho é essencial para manter a alta disponibilidade dos bancos de dados do SQL Server e garantir a satisfação dos usuários finais. Mas, infelizmente, nem sempre é imediatamente óbvio onde o ajuste é mais necessário. Se você eliminou as fontes óbvias de rede e hardware para problemas de desempenho, mude o foco para suas consultas.
Se você trabalha como DBA há algum tempo, provavelmente já encontrou uma (ou todas) dessas consultas de problemas. Agora que você sabe o que procurar, seja proativo em sua iniciativa de melhoria de desempenho e corrija esses pontos problemáticos de consulta comuns para que você possa colher os frutos da otimização de consulta do SQL Server.
