Alta Performance em Querys

Muitos programadores usam o banco de dados como se fosse um escravo obrigado a retornar dados de forma rapida e estruturada usando Query pesadas e mal elaboradas.Depois que a aplicação está no ar, e tudo fica lento. Joga a culpa no banco de dados, porém na aplicação está cheia de query e estrutura ineficiente e ineficaz.

É certo que poucas equipes possuem DBA, mas faz parte do conjunto de conhecimentos de um bom programador saber SQL, mas na verdade a maioria dos programados não sabem nada de banco de dados, sabem somente operações basicas e não tentam estudar, entender assuntos relacionados a performance.

Veja abaixo algumas dicas que traduzi de um site Gringo sobre performance.

1. SQL Performance Tuning recomenda usar COUNT (1) em vez COUNT (*) para otimização de desempenho.

2. Nunca compare NULL com NULL. Considere que o NULL não é como cadeia vazia ou como número 0 e um nulo não pode ser diferente de um NULL  Exemplo:

SELECT COUNT(1) FROM all_users WHERE 1 = 1;

SELECT COUNT(1) FROM all_users WHERE NULL = NULL;

SELECT COUNT(1) FROM all_users WHERE NULL != NULL;

3. Se você estiver usando mais de uma tabela de aliases de tabela de uso.

Exemplo:

SELECT COUNT(1) FROM master m, detail d WHERE m.id = d.master_id;

4. Use o nome de colunas em uma consulta.
A instrução SQL será mais legível, mas que não é a razão principal. Se você vai usar em INSERT instrução SELECT * FROM x e você vai mais tarde adicionar nova coluna na tabela x SQL irá retornar erro. A terceira razão é que você pode reduzir o tráfego de rede.

5. Em WHERE comparar string com string ou número com número.  Exemplo:

Nota: ID coluna é tipo de dados número.

Não use:

SELECT id, apn, charging_class FROM master WHERE id = ‘4343’;

Use:

SELECT id, apn, charging_class FROM master WHERE id = 4343;

6. Se é possível utilizar os valores da coluna não transformadas, recomenda SQL Performance Tuning.  Exemplo:

Não use:

WHERE SUBSTR(a.serial_id, INSTR(b.serial_id, ‘,’) – 1) = SUBSTR(b.serial_id, INSTR(b.serial_id, ‘,’) – 1)

Use:

WHERE a.serial_id = b.serial_id

7. Evite o uso de expressões complexas.

Exemplos:

Evite:

WHERE serial_id = NVL(:a1, serial_id)

WHERE NVL(serial_id,-1) = ( 1, etc…)

8. Se você precisa usar functioncs SQL em predicados de junção, não usá-los em colunas indexadas.

9. Exsists versus em para subconsultas  Nota: Se o predicado é seletiva na subconsulta, então use IN. Se o predicado seletivo é na consulta principal, em seguida, usar existe.

10. RETURNING cláusula  Use INSERT, UPDATE ou DELETE RETURNING quando apropriado. Em que forma é reduzido o número de chamadas para o banco de dados.

11. SQL Performance Tuning recomenda a utilização de instruções CASE  É mais eficiente para executar única instrução, se possível de duas declarações separadas para o mesmo resultado.

Exemplo:

Não use:

SELECT COUNT (1)   FROM emp  WHERE salary < 1000;

SELECT COUNT (1)   FROM emp  WHERE salary BETWEEN 1000 AND 2000;

Use:

SELECT COUNT (CASE WHEN salary < 1000

                   THEN 1 ELSE null END) count_1,

       COUNT (CASE WHEN salary BETWEEN 1001 AND 2000

                   THEN 1 ELSE null END) count_2   FROM emp;

12. Use UNION ALL em vez UNION se possível  Exemplo:

Não use:

SELECT id, name   FROM emp_bmw  UNION SELECT id, name   FROM emp_bmw_welt

Use:

SELECT id, name   FROM emp_bmw  UNION ALL SELECT id, name   FROM emp_bmw_welt

13. SQL Performance Tuning recomenda a utilização de um número mínimo de subconsultas, se possível.

Exemplo:

Não use:

SELECT id, manufacturer, model   FROM cars  WHERE price = ( SELECT MAX(price)

FROM cars_bmw

)    AND year =  ( SELECT MAX(year)

FROM cars_bmw

)

Use:

SELECT id, manufacturer, model   FROM cars  WHERE (price, year) = ( SELECT MAX(price), MAX(year)

                           FROM cars_bmw

                       )

14. SQL Performance Tuning recomenda para armazenar resultados intermediários Allways ponderar sobre os benefícios de tabelas intermediárias. Se as informações em que as tabelas são reutilizados algumas vezes, então você deve usá-los.