SQL Server 2000中的缓存函数结果

jen*_*wan 6 sql-server caching sql-server-2000

我想记住函数结果的性能,即懒惰地填充索引在函数参数上的缓存.第一次调用函数时,缓存将没有输入参数的任何内容,因此它将在返回之前计算并存储它.后续调用只使用缓存.

但是,似乎SQL Server 2000有一个关于函数"确定性"的愚蠢任意规则.INSERT,UPDATE和常规存储过程调用是被禁止的.但是,允许扩展存储过程.这是如何确定的?如果另一个会话修改了数据库状态,则函数输出仍会发生变化.

我疯了.我以为我可以让缓存对用户透明.这可能吗?我没有部署扩展存储过程的权限.

编辑:

这种限制仍然存在于2008年.出于上帝的缘故,你不能叫兰德!

缓存将由我在DB中实现.缓存是用于缓存的任何数据存储...

编辑:

在基础数据的更改之外,不存在函数的相同参数将产生不同结果的情况.这是一个BI平台,唯一的变化来自计划的ETL,此时我将TRUNCATE缓存表.

这些是I/O密集型时间序列计算,大约为O(n ^ 4).我没有权限更改基础表或索引.此外,许多这些函数使用相同的中间函数,缓存允许使用这些函数.

UDF不是真正的确定性,除非它们考虑到数据库状态的变化.重点是什么?是SQL Server缓存吗?(Ironic.)如果SQL Server正在缓存,那么它必须在对模式绑定的表的更改时到期.如果它们是模式绑定的,那么为什么不绑定函数修改的表?我可以看到为什么不允许触发,尽管这只是草率的; 只是架构绑定过程.而且,BTW,为什么允许扩展存储过程?你无法跟踪那些确保确定性的行为!哎呀!

编辑:

我的问题是:有没有办法以一种可以在视图中使用的方式懒惰缓存功能结果?

Cad*_*oux 2

确定性意味着相同的输入返回相同的输出,与时间和数据库无关。

SQL Server(任何版本)不会缓存 UDF - 我相信它会避免在一行上调用 UDF 两次,但仅此而已。

我用过的一个技巧是(我想我把它发布在这里):

如果可以的话,重构 UDF,以便为给定的输入集返回有效的可用离散值子集。对于数值计算,有时可以重构逻辑以返回一个因子或比率,该因子或比率在 UDF 外部相乘,而不是在 UDF 内部与传入的值相乘。

通过 DISTINCT 行集调用 UDF 并将结果缓存到临时表中。如果您仅在 17,000,000 行集上使用 100,000 个参数元组调用 UDF,则效率要高得多

JOIN 到临时表(基本上从基于代码的逻辑转换为基于表的逻辑)以获取值。

该表可以根据需要重复使用甚至保留。

可以通过首先 LEFT JOINing 查找丢失的缓存条目来完成对表的添加。

这适用于单行表值 UDF 和标量 UDF。我主要将它用于表值 UDF。SQL Server 2005 有一个修补程序,应该可以解决 UDF 性能问题 - 我正在等待 DBA 在部署到生产环境之前对其进行测试。