Eficiência de procedimentos armazenados versus consultas brutas

Eu li muito sobre os dois lados deste debate: existe um ganho significativo de desempenho usando apenas procedimentos armazenados em consultas brutas? Estou especificamente interessado no SQL Server, mas estaria interessado em todo e qualquer banco de dados.

É menos no SQL Server 2008 e superior, mas ainda está lá. O que se resume é o cache do plano de execução e o SQL Server poder parametrizar automaticamente as consultas enviadas. Ao usar procedimentos armazenados (que não possuem SQL dinâmico), as consultas já estão parametrizadas para que o SQL Server não ' não é necessário gerar um plano para cada consulta quando ela for executada, pois os planos já estão armazenados no cache do plano.

E não se esqueça dos problemas de segurança (SQL dinâmico, permissões mínimas etc.) que desaparecem ao usar procedimentos armazenados.

Quando o aplicativo está usando SQL dinâmico nas tabelas base para selecionar, inserir, atualizar e excluir os dados nas tabelas, o aplicativo precisa ter direitos sobre todos esses objetos diretamente. Portanto, se alguém usar o SQL Injection para acessar o servidor, ele terá o direito de consultar, alterar ou excluir todos os dados nessas tabelas.

Se você estiver usando procedimentos armazenados, eles terão apenas o direito de executar os procedimentos armazenados, retornando apenas as informações que o procedimento armazenado retornaria. Em vez de emitir uma instrução de exclusão rápida e remover tudo, eles precisariam descobrir quais procedimentos podem ser usados ​​para excluir dados e descobrir como usar o procedimento para fazer isso.

Dado que a injeção de SQL é a maneira mais fácil de invadir um banco de dados, isso é meio importante.

Como um adendo à resposta de Denny, não é incomum encontrar sistemas em que uma memória significativa do buffer pool é desperdiçada em planos de execução ad-hoc de uso único ou baixo, criados como resultado de consultas sendo usadas em procs.

Nos piores casos recentemente, 8 GB alocados a uma instância, cache de plano de 3 GB, planos de uso único de 2,5 GB. A maioria deles foi o SQL2005, portanto, não foi uma opção tentar a configuração de otimização para cargas de trabalho ad-hoc.

Certamente está ficando mais difícil incluir desempenho em uma justificativa para procedimentos em consultas brutas. Um dos argumentos mais fortes para mim agora é "Se você usa procedimentos, é muito mais fácil para mim ajudar quando surgem problemas de desempenho". Uma interface dinâmica / linq / orm não impede o ajuste, mas pode limitar severamente suas opções.

O SQL Server armazena em cache e otimiza os procedimentos armazenados e o SQL ad-hoc da mesma maneira. Por exemplo, este procedimento:

create procedure dbo.TestSB(@id int) as select * from Orders where id = @id

Será otimizado e armazenado em cache de forma idêntica para:

select * from Orders where id = @id

No entanto, o seguinte SQL ad-hoc não pode ser armazenado em cache efetivamente, devido ao valor codificado:

select * from Orders where id = 42

Embora o desempenho seja o mesmo, existem boas razões para usar procedimentos armazenados. Os procedimentos armazenados fornecem uma separação clara entre o DBA e os desenvolvedores de aplicativos. É bom ter uma camada extra de defesa entre seus dados valiosos e programas em constante mudança :)