SQL Server 2005中没有过程的查询计划

我们有一个具有150-200个存储过程的SQL Server DB，所有这些过程都会在sys.dm_exec_query_plan中生成一个可查看的查询计划，只有一个除外。根据：

在以下条件下，sys.dm_exec_query_plan返回表的query_plan列中不返回Showplan输出：

如果使用plan\u handle指定的查询计划已从计划缓存中退出，则返回表的query\u plan列为null。例如，如果在捕获计划句柄和将其与sys.dm_exec_query_plan一起使用之间存在时间延迟，则可能发生此情况。 某些Transact-SQL语句未缓存，例如批量操作语句或包含大于8 KB字符串文本的语句。除非批处理当前正在执行，否则无法使用sys.dm_exec_query_plan检索此类语句的XML showplan，因为它们不在缓存中。 如果Transact-SQL批处理或存储过程包含对用户定义函数的调用或对动态SQL的调用（例如使用EXEC字符串），则用户定义函数的已编译XML Showplan不会包含在批处理或存储过程的sys.dm_EXEC_query_plan返回的表中。相反，您必须单独调用sys.dm_exec_query_plan以获取对应于用户定义函数的计划句柄。 后来

由于xml数据类型中允许的嵌套级别数量有限，sys.dm_exec_query_plan无法返回满足或超过128个嵌套元素级别的查询计划

我相信这些都不适用于本程序。结果从来没有查询计划，无论时间如何，因此1不适用。没有长字符串文字或批量操作，因此2不适用。没有用户定义的函数或动态SQL，因此3不适用。而且几乎没有嵌套，所以最后一个不适用。事实上，这是一个非常简单的过程，我完整地包含了一些表名，以保护无辜者。请注意，参数嗅探诡计将问题的日期推迟。即使我直接在查询中使用参数，这种情况仍然会发生。关于为什么我没有这个过程的可查看查询计划，有什么想法吗

ALTER PROCEDURE [dbo].[spGetThreadComments] 
    @threadId int, 
    @stateCutoff int = 80, 
    @origin varchar(255) = null, 
    @includeComments bit = 1, 
    @count int = 100000
AS

if (@count is null)
begin
    select @count = 100000
end

-- copy parameters to local variables to avoid parameter sniffing
declare @threadIdL int, @stateCutoffL int, @originL varchar(255), @includeCommentsL bit, @countL int
select @threadIdL = @threadId, @stateCutoffL = @stateCutoff, @originL = @origin, @includeCommentsL = @includeComments, @countL = @count

set rowcount @countL

if (@originL = 'Foo')
begin
    select * from FooComments (nolock) where threadId = @threadId and statusCode <= @stateCutoff 
    order by isnull(parentCommentId, commentId), dateCreated
end
else
begin       
    if (@includeCommentsL = 1)
    begin
        select * from Comments (nolock) 
            where threadId = @threadIdL and statusCode <= @stateCutoffL
            order by isnull(parentCommentId, commentId), dateCreated
    end
    else
    begin
        select userId, commentId from Comments (nolock) 
            where threadId = @threadIdL and statusCode <= @stateCutoffL
            order by isnull(parentCommentId, commentId), dateCreated
    end
end

试着放dbo。或者所有表名前面的模式，然后再次检查

见本文：

文章引述：

如你所见，我参考了所有的表格 用两部分表示法。就是我也 指定在SQL中使用的架构 通常指的是7/2000术语 作为拥有者。如果我能省去这个问题 模式，每个用户都将获得自己的 他自己的私人版本的查询 计划

---

嗯，也许这些桌子不是真正的桌子。它们可能是视图或其他内容。

您能为这3个查询中的每一个都提供一个查询计划吗？那些表真的是调用函数的视图吗？嘿，大卫。我可以通过dm_exec_query_stats确认，没有给我查询计划的计划句柄实际上正在工作，所以我不认为我只是在看一些总括计划，而不是运营计划。哇。很好，大卫。虽然理论上两个表都只是表，但其中一个实际上是不存在的表。FooComment在途中的某个地方被删除了。这并没有导致运行时问题，因为该分支显然从未被使用过，但似乎由于缺少表而无法正确生成和/或显示查询计划。如果你想写下来作为答案，我会给你荣誉。嘿，KM。这看起来是一个很好的实践，事实上我们确实遇到了一些问题，sql跟踪将显示性能差的查询，在我运行它们时，这些查询运行得很好。可能是每个连接获得不同查询计划的情况。但在本例中，我们在所有进程中都忽略了完全限定名，只有这一个缺少查询计划。我们的商店在将数据库结构从一个数据库复制到另一个数据库时遇到了许多不存在的对象。最终我们得到了一个工具来检测缺失的依赖项。奇怪的是，在您实际执行该代码分支之前，SQL中不会有任何抱怨。似乎有什么值得一提的。