Início > JAVA > Obtendo melhor desempenho em aplicações SQL

Obtendo melhor desempenho em aplicações SQL

Eventualmente vemos queixas da lentidão na execussão de Stored Procedures ou selects em geral em nossas aplicações Java, PHP, etc. Muitos fatores podem colaborar para que o desempenho seja pífio e é possível escrever um livro a respeito. De qualquer forma, vou compartilhar a seguir algumas dicas que podem ajudar. A tempo, acreditem, ainda que as pessoas saibam do que vou falar a seguir, parece que ninguem lembra no momento de implementar uma aplicação. Vamos lá:

1- Criar indices adequados
Quando temos uma busca, por exemplo: select max(data_inclusao) from tabela , vemos que o banco irá fazer uma busca pela maior data de inclusão na Tabela. Se este campo não for indice, ele varrerá toda a tabela até encontrar o maior. Caso você crie um indice para o campo, a busca irá ser muito mais rapida, podendo ser otimizada ainda mais se o indice a ser criado NESTE CASO for descendente, ou seja, do maior para o menor.

2- Comparações adequadas
Temos que dar preferência a utilizar nas clausulas “where” os indices citados acima. Caso um where demande uma busca que não seja por um indice, obviamente será muito mais lento devido a leitura que o banco irá efetuar na tabela.

3- Buffer Pool
Está é uma configuração do tanto de memória (RAM) que o banco irá utilizar. Quanto maior, mais espaço o banco terá para trabalhar com os dados em memória RAM, fazendo menos acessos ao disco (muito mais lento). Um valor aceitável para um banco de dados, é ter 95% de acerto em memória.

4- Sort Heap
É o espaço em memória disponível para o banco fazer sorts, deve ser estabelecido um valor adequado para evitar estouros de memória. Assim como o buffer pool, é um ajuste fino e vai sendo adequado de acordo com o uso da aplicação, observando-se os logs e solicitando análises de desempenho ao DBA.

5- Rotinas de expurgo
Quanto mais registros temos em uma tabela, mais trabalho o sgbd terá para encontrar informações. Uma boa prática é criar rotinas nos sistemas para expurgar dados históricos, ou seja, criar tabelas “mortas”, cuja finalidade é guardar histórico e remover estes dados se não forem necessários em tabelas quentes.

6- Particionamento de tabelas
Relacionado ao ítem anterior, se não pudermos limpar uma tabela e ela realmente tenha muitos dados, um boa idéia é particionar a mesma utilizando algum critério inteligente, por exemplo, suponha que você tenha uma tabela de VENDAS, podemos particionar a mesma num critério parecido com o abaixo:
A- Vendas realizadas a partir de 2010
B- Vendas realizadas entre 2000 e 2010
C- Vendas realizadas entre 1990 e 2000
D- Vendas realizadas antes de 1990

7- Select *
SEMPRE escreva suas buscas limitando o número de colunas, trazendo somente os dados necessários.
Limite tambem o número de linhas retornadas, sempre utilizando filtros nas clausulas WHERE.
Caso não tenha um filtro, por exemplo: o usuário não informou NOME, ENDERECO, CNPJ, ETC, para buscar um cliente, traga somente um número limitado de linhas. OBRIGUE seu usuário a utilizar critérios. É inadimissivel um “select *” em uma base de dados, ainda mais, sem Where.

8- Organização da procedure
Tenha em mente que toda clausula sql é “compilada” e o banco gera um plano de acesso para executar a mesma. Supondo que você tenha uma Stored Procedure que, dependendo dos parametros de entrada, não irá fazer chamadas a determinadas tabelas, por exemplo, se o usuário não informar a cidade do cliente, a sql não irá fazer um join com a tabela cidades. Agora imagine que em sua tabela você tem TODAS as cidades do Brasil cadastradas. Ganhamos desempenho se não envolver tal tabela na consulta (é um exemplo bobo, mas pode ser utilizado em outras escalas)!

Veja o exemplo abaixo, ele faz exatamente o que falo no ítem anterior:

CREATE PROCEDURE DBAPRD1.PSELXIMBICA(
IN PAR_CIDADE                varchar(10)
)
SPECIFIC DBAPRD1.PSELXIMBICA
DYNAMIC RESULT SETS 1

P1:BEGIN
-- declaro dois cursores, criando dois planos de acesso
DECLARE cursorListagem CURSOR WITH RETURN TO CLIENT FOR
SELECT
nome,
endereco
FROM DBAPRD1.CLIENTES;
-- este utiliza a tabela cidade, sendo bem mais lento
DECLARE cursorListagem2 CURSOR WITH RETURN TO CLIENT FOR
SELECT
A.nome,
A.endereco
FROM DBAPRD1.CLIENTES A, DBAPRD1.CIDADES B
WHERE   B.cidade LIKE PAR_CIDADE;

IF PAR_CIDADE IS NULL THEN
OPEN cursorListagem;
ELSE
OPEN cursorListagem2;
END IF;
END P1@

Enjoy!

Categorias:JAVA Tags:, , , , ,
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: