-
a) não se deve utilizar stored procedures para consultas realizadas com frequência em ambientes de rede. - Ao contrário, deve usar stored procedures.
b) deve-se utilizar DISTINCT ao invés de EXISTS quando se fizer joins que envolvam tabelas com relacionamento um-para-muitos. - O EXISTS tem melhor performance*, dado que o DISTINCT ordena as tuplas antes de removê-las. Já o EXISTS assim que achar uma tupla correspondente já encerra a procura.
c) deve-se trocar o operador EXISTS ou NOT EXISTS por IN ou NOT IN. - O EXISTS também tem melhor performance nesse caso* mas para casos em que tem-se várias tuplas e colunas. Já para pequenas comparações o IN é melhor. OBS: Encontrei fontes falando que ambos tem a mesma performance nos SGBD's atuais, e que essa diferença existe nos antigos.
d) deve-se utilizar funções nas consultas em lugar do operador LIKE. - Não encontrei nada a respeito, mas não parece intuitivo.
e) deve-se substituir o UNION por UNION ALL. - UNION ALL remove duplicatas, enquanto o UNION as preserva. Logo unindo menos tuplas e com performance melhor. - Correto
-
Rafael,
Pequena correção na LETRA e.
Pois é o contrário. O UNION ALL preserva os duplicados, por isso é mais rápido no processo de seleção, não precisa verificar no resultado se aquela tupla já está lá. O UNION não retorna duplicados.
-
UNION ALL TRAZ LINHAS REPETIDAS
UNION PRESERVA AS LINHAS REPETIDAS (NAO VERIFICA ANTES DE TRAZER E POR ISSO É MAIS RÁPIDO)
-
Dica de Perfomance: Se você precisa unir resultados que não podem se repetir e você conhece os resultados do SELECT e já sabem que eles não se repetem, então você deve usar o UNION ALL, pois ele não utilizará o DISTINCT entre os SELECTS o que causa um ganho de PERFOMANCE. Já se você usar o UNION o SQL Server utilizará um DISTINCT em cima de um resultado que não se repete, ou seja, consumirá recursos à toa.
https://social.technet.microsoft.com/wiki/contents/articles/4436.union-x-union-all-pt-br.aspx