Ainda errado ao iniciar o nome de um procedimento armazenado pelo usuário com sp_?

Um dos meus colegas de trabalho nomeou um procedimento armazenado em nosso banco de dados SQL Server 2008 R2 sp_something. Quando vi isso, pensei imediatamente: "Está errado!" e comecei a pesquisar nos meus favoritos este artigo on-line que explica por que está errado, para que eu pudesse fornecer uma explicação ao meu colega de trabalho.

No artigo (de Brian Moran ), é explicado que atribuir ao procedimento armazenado um prefixo sp_ faz com que o SQL Server procure no banco de dados mestre um plano compilado. Como o sp_sprocarquivo não reside lá, o SQL Server recompilará o procedimento (e precisará de um bloqueio de compilação exclusivo para isso, causando problemas de desempenho).

O exemplo a seguir é fornecido no artigo para mostrar a diferença entre dois procedimentos:

USE tempdb;
GO

CREATE PROCEDURE dbo.Select1 AS SELECT 1;
GO

CREATE PROCEDURE dbo.sp_Select1 AS SELECT 1;
GO

EXEC dbo.sp_Select1;
GO

EXEC dbo.Select1;
GO

Você executa isso, abra o Profiler (adicione o SP:CacheMissevento Stored Procedures -> ) e execute os procedimentos armazenados novamente. Você deve ver uma diferença entre os dois procedimentos armazenados: o sp_Select1procedimento armazenado gerará mais um SP:CacheMissevento que o Select1procedimento armazenado (o artigo faz referência ao SQL Server 7.0 e SQL Server 2000 ).

Quando executo o exemplo no meu ambiente do SQL Server 2008 R2, recebo a mesma quantidade de SP:CacheMisseventos para os dois procedimentos (no tempdb e em outro banco de dados de teste).

Então, eu estou pensando:

• Posso ter feito algo errado na execução do exemplo?
• O sproc sp_somethingadágio ' não nomear um usuário ' ainda é válido nas versões mais recentes do SQL Server?
• Em caso afirmativo, existe um bom exemplo que mostra sua validade no SQL Server 2008 R2?

Muito obrigado por seus pensamentos sobre isso!

EDITAR

Encontrei Criando procedimentos armazenados (mecanismo de banco de dados) no msdn para SQL Server 2008 R2, que responde minha segunda pergunta:

Recomendamos que você não crie procedimentos armazenados usando sp_ como prefixo. O SQL Server usa o prefixo sp_ para designar procedimentos armazenados do sistema. O nome escolhido pode entrar em conflito com algum procedimento futuro do sistema. [...]

Nada é mencionado lá sobre problemas de desempenho causados ​​pelo uso do sp_prefixo. Gostaria de saber se esse ainda é o caso ou se eles o corrigiram após o SQL Server 2000.

Isso é bastante fácil de se testar. Vamos criar dois procedimentos muito simples:

CREATE PROCEDURE dbo.sp_mystuff
AS
  SELECT 'x';
GO
CREATE PROCEDURE dbo.mystuff
AS
  SELECT 'x';
GO

Agora vamos criar um wrapper que os execute várias vezes, com e sem o prefixo do esquema:

CREATE PROCEDURE dbo.wrapper_sp1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC sp_mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_sp2
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC dbo.sp_mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_2
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC dbo.mystuff;
      SET @i += 1;
    END
END
GO

Resultados:

Conclusões:

• usar o prefixo sp_ é mais lento
• deixar de fora o prefixo do esquema é mais lento

A questão mais importante: por que você deseja usar o prefixo sp_? O que seus colegas esperam ganhar com isso? Isso não deve significar que você precisa provar que isso é pior, mas justificar a adição do mesmo prefixo de três letras a cada procedimento armazenado no sistema. Não vejo o benefício.

Também realizei alguns testes bastante extensos desse padrão na seguinte postagem no blog:

http://www.sqlperformance.com/2012/10/t-sql-queries/sp_prefix

Recomendamos que você não crie procedimentos armazenados usando sp_ como prefixo. O SQL Server usa o prefixo sp_ para designar procedimentos armazenados do sistema. O nome escolhido pode entrar em conflito com algum procedimento futuro do sistema. [...]

Nada é mencionado lá sobre problemas de desempenho causados ​​pelo uso do prefixo sp_. Gostaria de saber se esse ainda é o caso ou se eles o corrigiram após o SQL Server 2000.

Como mostra o comentário simples de Martin Smith - sim, se você tiver um procedimento armazenado com um sp_prefixo - o executor de consultas do SQL Server sempre fará check-in no masterbanco de dados primeiro para ver se existe um procedimento armazenado (marcado como um procedimento armazenado no sistema) com esse nome.

E, se existir, o procedimento armazenado no sistema do masterbanco de dados sempre prevalecerá e será executado em vez do seu.

Então sim - ele ainda permanece: não use o sp_prefixo.

Um teste melhor é escrever uma consulta que exija otimização total, pois provavelmente é um reflexo melhor do que o processo que você está escrevendo está fazendo. Embrulhei a consulta a seguir em um SP e repeti seu teste e obtive os mesmos resultados.

select * from Person.BusinessEntity b
inner join Person.BusinessEntityAddress ba on b.BusinessEntityID = ba.BusinessEntityID
inner join Person.Address a on ba.AddressID = a.AddressID

Recebi o mesmo número de eventos de falta e acerto de cache nos dois casos e, nos dois casos, o plano foi adicionado ao cache. Também executei os dois procs várias vezes e não houve diferença consistente no tempo da CPU ou no tempo decorrido relatado pelo dm_exec_query_stats.

A outra preocupação é que, como "sp_" procs podem ser executados a partir do master, você pode obter uma cópia do proc executada no master em vez do DB em que está trabalhando, mas um teste rápido mostrará que não é esse o caso. No entanto, se o proc for retirado do banco de dados em que você está trabalhando e uma cópia existir no master, ela será executada, o que pode ser um problema se for uma versão antiga. Se isso é uma preocupação, eu não usaria "sp_" para nomear o proc.

Acredito que o problema tenha que ser resolvido quando você não especificar o nome completo do objeto. Portanto, "EXEC sp_something" verificará o mestre primeiro, mas "EXEC dbname.dbo.sp_something" nunca irá dominar primeiro.

A lição, se bem me lembro, é sempre usar o nome completo.