Pergunta

O que é mais rápido no SQL Server 2005/2008, um procedimento armazenado ou uma View?

EDIT: Como muitos de você apontou, estou sendo muito vago. Deixe-me tentar ser um pouco mais específico.
Eu queria saber a diferença de desempenho para uma determinada consulta em uma exibição, contra exatamente a mesma consulta dentro de um procedimento armazenado. (Eu ainda apreciar todas as respostas que ponto as suas capacidades diferentes)

Foi útil?

Solução

Stored Procedures (SPs) e SQL exibições são diferentes "bestas", como declarou várias vezes neste post.

Se excluirmos algumas [tipicamente menor, exceto em casos marginais] considerações de desempenho associados ao cache do plano de consulta, o tempo associado com a ligação a um procedimento armazenado e tal, as duas abordagens estão em todo o equivalente , em termos de performance. No entanto ...

A vista é limitado para o que pode ser expresso em uma única instrução SELECT (bem, possivelmente com CTEs e alguns outros truques), mas, em geral, uma visão está ligada a formas declarativas de consultas . Um procedimento armazenado no outro pode usar vários tipos de procedimentos construções (bem como os declarativas), e, como resultado, usando SPs, pode-se mão-de artesanato uma maneira de resolver uma determinada consulta o que pode ser mais eficiente do que o otimizador de consulta do SQL-Server pode ter feito (com base em uma única consulta declarativa). Nestes casos, um SPs pode ser muito mais rápido (mas cuidado ... o otimizador é muito inteligente, e não é preciso muito para fazer um SP muito mais lento do que a visão equivalente.)

Para além destas considerações de desempenho, os SPs são mais versáteis e permitem uma ampla gama de consultas e ações do que os pontos de vista.

Outras dicas

Infelizmente, eles não são o mesmo tipo de besta.

Um procedimento armazenado é um conjunto de instruções T-SQL, e pode retornar dados. Ele pode realizar todos os tipos de lógica, e não necessariamente retornar dados em um conjunto de resultados.

A vista é uma representação de dados. É usado principalmente como uma abstração de uma ou mais tabelas com subjacente junta. É sempre um conjunto de resultados de zero, uma ou várias linhas.

Eu suspeito que sua pergunta é mais ao longo das linhas de:

O que é mais rápido:? SELECTing a partir de um ponto de vista, ou a instrução SELECT equivalente em um procedimento armazenado, dadas as mesmas tabelas base realizar a junta com o mesmo onde cláusulas

Isto não é realmente uma pergunta responde em que uma resposta será uma realidade em todos os casos. No entanto, como uma resposta geral para um SQL Server específico implementaion ...

Em geral, um procedimento armazenado tem uma boa chance de ser mais rápido do que uma instrução SQL direto porque o servidor faz todos os tipos de otimizações quando um procedimento armazenado é salva e executado pela primeira vez.

A vista é essencialmente uma instrução SQL salva.

Portanto, eu diria que, em geral, um procedimento armazenado será provável que seja mais rápido do que uma visão Se a instrução SQL para cada um é o mesmo, e se a instrução SQL pode se beneficiar de otimizações. Caso contrário, em geral, eles seriam semelhantes no desempenho.

documentação

Referência estas ligações apoiar a minha resposta.

http://www.sql-server-performance.com/tips/ stored_procedures_p1.aspx

http://msdn.microsoft.com/en-us/library/ ms998577.aspx

Além disso, se você está procurando todas as maneiras para otimizar o desempenho em SQL Server, o segundo link acima é um bom lugar para começar.

Eu prefiro procedimentos armazenados devido ao permitir maior controle sobre os dados, se você quiser construir uma boa, sistema modular seguro, em seguida, usar procedimentos armazenados, pode executar vários sql-comandos, tem instruções de controle-de-fluxo e aceita parâmetros. Tudo o que você pode fazer em uma visão que você pode fazer em um procedimento armazenado. Mas, em um procedimento armazenado, você pode fazer com muito mais flexibilidade.

Em suma, com base na minha experiência em algumas consultas complexas, Procedimento armazenado dá um melhor desempenho do que a função.

Mas você não pode usar resultados de procedimento armazenado em selecione ou consultas de junção.

Se você não quiser usar o conjunto de resultados de outra consulta, melhor para uso SP.

E resto dos detalhes e diferenças são mencionados por pessoas neste fórum e em outros lugares.

Os procedimentos armazenados e vistas são diferentes e têm finalidades diferentes. Eu olho para vistas como consultas enlatados. Eu olho para procedimentos armazenados como módulos de código.

Por exemplo, digamos que você tem uma tabela chamada tblEmployees com essas duas colunas (entre outros): DateOfBirth e MaleFemale.

A exibição chamada viewEmployeesMale que filtra única empregados do sexo masculino pode ser muito útil. A exibição chamada viewEmployeesFemale também é muito útil. Ambos os pontos de vista são auto descrever e muito intuitivo.

Agora, vamos dizer que você precisa para produzir uma lista todos os trabalhadores do sexo masculino entre as idades de 25 e 30. Eu tenderia a criar um procedimento armazenado para produzir este resultado. Enquanto ele certamente poderia ser construído como uma visão, na minha opinião, um procedimento armazenado é mais adequado para lidar com isso. Data de manipulação especialmente onde nulos são um fator pode se tornar muito complicado.

Eu acredito que uma outra maneira de pensar seria a utilização de procedimentos armazenados para selecionar os pontos de vista. Isso fará com que sua arquitetura de um sistema de baixo acoplamento. Se você decidir mudar o esquema no futuro, você não terá que se preocupar 'so' tanto que ele vai quebrar o front-end.

Eu acho que o que estou dizendo é, em vez de sp vs pontos de vista, acho sp e vistas:)

Um par de outras considerações: Embora o desempenho entre um SP e uma vista são essencialmente os mesmos (dado que eles estão realizando exatamente a mesma seleção), o SP lhe dá mais flexibilidade para a mesma consulta .

  • O SP apoiará encomendar o conjunto de resultados; ou seja, incluindo uma instrução ORDER BY. Você não pode fazê-lo de vista.
  • O SP é totalmente compilado e requer apenas um exec para invocá-lo. A visão ainda requer um SELECT * FROM view para invocá-lo; isto é, uma escolha sobre o compilado selecione a vista.

Eu sei que não sou suposto transformar isso em uma "discussão", mas estou muito interessado neste e apenas pensei que eu iria partilhar as minhas observações empíricas de uma situação específica, com especial referência a todos os comentários acima que afirmam que uma instrução SELECT equivalente executado a partir de um procedimento armazenado e uma vista deve ter praticamente a mesma performance.

Eu tenho uma visão na base de dados "A" que se junta 5 tabelas em um banco de dados separado (db "B"). Se eu anexar a DB "A" no SSMS e SELECT * do ponto de vista, é preciso> 3 minutos para retornar 250000 linhas. Se eu tomar a instrução SELECT a partir da página de desenho da visualização e executá-lo diretamente no SSMS, leva <25 segundos. Colocar a mesma instrução select em um procedimento armazenado dá o mesmo desempenho quando eu executar esse procedimento.

Sem fazer quaisquer observações sobre o desempenho absoluto (db "B" é um banco de dados AX que não estão autorizados a tocar!), Ainda estou absolutamente convencido de que, neste caso, usando um SP é uma ordem de magnitude mais rápido que usar uma exibição para recuperar os mesmos dados, e isso se aplica a muitos outros pontos de vista semelhantes, neste caso particular.

Não pensar é qualquer coisa a ver com a criação de uma conexão com o outro db, a menos que usando uma visão de alguma forma nunca pode armazenar em cache a conexão enquanto o seleto faz, porque eu posso alternar entre os 2 selecciona na janela mesmas SSMS repetidamente e o desempenho de cada consulta permanece consistente. Além disso, se eu conectar diretamente a DB "B" e executar a escolha sem a dbname.dbo .... refs, leva-se ao mesmo tempo.

Qualquer pensamentos alguém?

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top