Question

我正在使用SQL Server，我希望从重用查询计划中受益。我发现了这个document，但我仍然不清楚我的查询计划是否被重复使用。

declare @su dbo.IntCollection      -- TABLE (Value int not null)

insert into @su values (1),(2),(3) --... about 500 values

update mt
set mt.MyField = getutcdate()
from MyTable mt
join @su vsu on mt.Id = vsu.Value -- Clustered PK, int

从技术上讲，批处理的文本因运行而异，因为@su中插入了不同的值。但更新查询的文本保持不变。如果我使用.NET，我基本上会将一个表变量传递给SQL命令，但我使用的是Python，看起来没有办法从我的程序中传递table参数。

问题1 ：更新查询计划是否重复使用？或者优化器是否看起来批处理文本不同并且不批量分析单个查询？换句话说，它与

相同

update MyTable
set MyField = getutcdate()
where Id in (1, 2, 3 ...)

问题2 ：我可以通过引入带有table参数的存储过程来强制SQL在调用之间保持相同，但是我会从中受益吗？

问题3 ：如何识别给定查询其计划是重新使用还是重新计算？

问题4 ：在我的具体案例中，我是否应该担心以上所有问题？毕竟它只是一堆ID表的更新......

Answer 1

回答你的问题..

问题1：更新查询计划是否重复使用？或者优化器是否看起来批处理文本不同并且不批量分析单个查询？换句话说，它与
相同

您的两个更新语句都被视为新查询，因为SQL会尝试计算查询的哈希值，并且任何简单更改都不会与旧哈希值匹配

问题2：我可以通过引入带有table参数的存储过程来强制SQL在调用之间保持相同，但是我会从中受益吗？

这对我来说听起来不错......比一堆IN's

更好

问题3：如何识别给定查询其计划是重新使用还是再次计算？

select usecounts from sys.dm_exec_cached_plans ec
cross apply
sys.dm_exec_sql_text(ec.plan_handle) txt
where  txt.text like '%your query text%'

问题4：在我的具体案例中，我是否应该担心以上所有问题？毕竟它只是一堆ID表的更新......

在我看来，你很担心......正如你提到的白皮书所指出的那样，有许多规则强制执行查询计划重用行为。因此大多数情况下，查询计划将被重用..

只有当我看到高SQL Compilations/sec加上Batch Requests/sec

时，我才开始担心计划的可用性

取自此处的答案：https://dba.stackexchange.com/questions/19544/how-badly-do-sql-compilations-impact-the-performance-of-sql-server

SQL Compilations / sec是一个很好的指标，但只有在与Batch Requests / sec结合使用时才会出现。就其本身而言，每秒的编辑并没有真正告诉你太多。

你看到170.如果每秒批量请求只有200（有点夸大效果）那么是的，你需要深入到原因的底部（最有可能过度使用临时查询和一次性使用）计划）。但是如果你的每秒批量需求大约为5000，那么每秒170次编译就不算差了。一般的经验法则是，Compilations / sec应该比批量请求总数/秒小10％或更少。

在SQL Server 2012中重用查询计划

1 个答案: