SQL Server 2008 中的函数

发布于 2024-08-07 10:18:58 字数 30 浏览 7 评论 0原文

sql server 是否缓存函数的执行计划？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

请止步禁区 2024-08-14 10:18:58

是的，请参阅 rexem 的 Tibor 链接和 Andrew 的答案。

然而......无论如何，一个简单的表值函数都不会嵌套/扩展到外部查询中。就像风景一样。我的答案（带链接）在这里

也就是说，这种类型：

CREATE FUNC dbo.Foo ()
RETURNS TABLE
AS
RETURN (SELECT ...)
GO

Yes, see rexem's Tibor link and Andrew's answer.

However... a simple table value function is unnested/expanded into the outer query anyway. Like a view. And my answer (with links) here

That is, this type:

CREATE FUNC dbo.Foo ()
RETURNS TABLE
AS
RETURN (SELECT ...)
GO

回复收藏 0 原文

时光沙漏 2024-08-14 10:18:58

根据 dmv 是的，http://msdn.microsoft.com/en- us/library/ms189747.aspx 但我必须运行测试来确认。

输出中的对象 ID 是“此查询计划的对象（例如，存储过程或用户定义函数）的 ID”。

测试了一下，是的，看起来他们确实获得了一个单独的计划缓存条目。

测试脚本：

create function foo (@a int)
    returns int
as
begin
    return @a
end

创建的最基本的函数。

-- clear out the plan cache
dbcc freeproccache
dbcc dropcleanbuffers
go

-- use the function
select dbo.foo(5)
go

-- inspect the plan cache
select * from sys.dm_exec_cached_plans
go

计划缓存有 4 个条目，其中 objtype = Proc 列出的条目是函数计划缓存，抓住句柄并将其打开。

select * from sys.dm_exec_query_plan(<insertplanhandlehere>)

我测试中的第一个临时查询是实际查询，第二个临时查询是请求计划缓存的查询。因此，它肯定会在与发出的即席查询不同的过程类型下收到一个单独的条目。计划句柄也不同，当使用计划句柄提取时，它会向原始函数提供一个对象 ID，而即席查询不提供对象 ID。

According to the dmv yes, http://msdn.microsoft.com/en-us/library/ms189747.aspx but I'd have to run a test to confirm.

Object ID in the output is "ID of the object (for example, stored procedure or user-defined function) for this query plan".

Tested it and yes it does look like they are getting a separate plan cache entry.

Test Script:

create function foo (@a int)
    returns int
as
begin
    return @a
end

The most basic of functions created.

-- clear out the plan cache
dbcc freeproccache
dbcc dropcleanbuffers
go

-- use the function
select dbo.foo(5)
go

-- inspect the plan cache
select * from sys.dm_exec_cached_plans
go

The plan cache then has 4 entries, the one listed as objtype = Proc is the function plan cache, grab the handle and crack it open.

select * from sys.dm_exec_query_plan(<insertplanhandlehere>)

The first adhoc on my test was the actual query, the 2nd ad-hoc was the query asking for the plan cache. So it definitely received a separate entry under a different proc type to the adhoc query being issued. The plan handle was also different, and when extracted using the plan handle it provides an object id back to the original function, whilst an adhoc query provides no object ID.

回复收藏 0 原文

~没有更多了~