用sp_开头用户存储过程的名称仍然错误吗？

我的一位同事在我们的SQL Server 2008 R2数据库中命名了一个存储过程sp_something。当我看到此消息时，我立即想到：“那是错误的！” 并开始在我的书签中搜索此在线文章，该文章解释了错误的原因，因此我可以向我的同事提供解释。

在这篇文章（由Brian Moran撰写）中，解释了给存储过程一个sp_前缀使SQL Server可以在master数据库中查看已编译的计划。由于sp_sproc不在此处，因此SQL Server将重新编译该过程（并为此需要一个专用的编译锁，从而导致性能问题）。

本文提供了以下示例，以显示两个过程之间的区别：

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

您运行此程序，然后打开Profiler（添加“存储过程-> SP:CacheMiss事件”）并再次运行存储过程。您应该看到两个存储过程之间的区别：sp_Select1存储过程将比存储过程生成一个更多的SP:CacheMiss事件Select1（本文引用了SQL Server 7.0和SQL Server 2000。）

当我在SQL Server 2008 R2环境中运行该示例时SP:CacheMiss，两个过程都得到相同数量的事件（在tempdb和另一个测试数据库中）。

所以我想知道：

• 我可以在执行示例时做错什么吗？
• sproc sp_something在新版本的SQL Server中，“不命名用户” adagium是否仍然有效？
• 如果是这样，是否有一个很好的示例显示其在SQL Server 2008 R2中的有效性？

非常感谢您对此的想法！

编辑

我在msdn上为SQL Server 2008 R2 找到了创建存储过程（数据库引擎），它回答了我的第二个问题：

我们建议您不要使用sp_作为前缀创建任何存储过程。SQL Server使用sp_前缀来指定系统存储过程。您选择的名称可能与将来的某些系统过程冲突。[...]

但是，这里没有提及使用前缀引起的性能问题sp_。我很想知道是否仍然如此，或者他们是否在SQL Server 2000之后解决了问题。

这很容易测试自己。让我们创建两个非常简单的过程：

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

现在，让我们构建一个包装器，执行该包装器多次，无论是否包含模式前缀：

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

结果：

结论：

• 使用sp_前缀较慢
• 省略模式前缀较慢

更为重要的问题：为什么要使用sp_前缀？您的同事希望从中获得什么？这不应该与您不得不证明这种情况更糟有关，而应该与他们证明将相同的三个字母的前缀添加到系统中的每个存储过程有关。我看不到好处。

我还在以下博客文章中对此模式进行了相当广泛的测试：

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

我们建议您不要使用sp_作为前缀创建任何存储过程。SQL Server使用sp_前缀来指定系统存储过程。您选择的名称可能与将来的某些系统过程冲突。[...]

尽管没有提及任何由于使用sp_前缀引起的性能问题。我很想知道是否仍然如此，或者他们是否在SQL Server 2000之后解决了问题。

正如Martin Smith的简单注释所显示的-是的，如果您有带sp_前缀的存储过程-SQL Server查询执行程序将始终master首先在数据库中检入以查看是否存在该名称的存储过程（标记为系统存储过程）。

而且，如果存在，master数据库中的系统存储过程将始终存在，并且将代替您自己执行该过程。

所以，是的-它依然存在：不使用的sp_前缀。

一个更好的测试是编写一个需要完全优化的查询，因为这可能更好地反映了您正在编写的proc在做什么。我将以下查询包装在SP中，并重复了测试并获得了相同的结果。

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

在这两种情况下，我都得到了相同数量的缓存未命中和命中事件，并且在两种情况下，都将计划添加到了缓存中。我还两次运行了两个proc，并且dm_exec_query_stats报告的CPU时间或经过时间没有一致的差异。

另一个问题是，由于可以从master执行“ sp_” proc，因此您可能会获得运行到master而不是您正在使用的DB的proc的副本，但是快速测试将显示情况并非如此。但是，如果proc从您正在使用的数据库中删除，并且在master中存在一个副本，则它将被执行，如果它是旧版本，则可能会出现问题。如果这是一个问题，我不会使用“ sp_”来命名该过程。

我相信当您不指定完全合格的对象名称时，就必须解决此问题。因此，“ EXEC sp_something”将首先检查主服务器，但“ EXEC dbname.dbo.sp_something”将永远不会先进入主服务器。

我记得，该课程是始终使用完全限定的名称。