sql-server - SQL Server 2000 中的缓存功能结果

Question

我想记住函数结果以提高性能，即延迟填充在函数参数上索引的缓存。我第一次调用函数时，缓存不会有任何输入参数，因此它将计算它并在返回之前存储它。后续调用只需使用缓存即可。

但是，SQL Server 2000 似乎对函数“确定性”有一个愚蠢的任意规则。禁止插入、更新和常规存储过程调用。但是，允许扩展存储过程。这是如何确定性的？如果另一个 session 修改了数据库状态，函数输出无论如何都会改变。

我快气疯了。我原以为我可以使缓存对用户透明。这可能吗？我没有部署扩展存储过程的权限。

编辑:

这个限制在 2008 年仍然存在。看在上帝的份上，你不能调用 RAND!

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

编辑:

除了基础数据的更改之外，函数的相同参数不会产生不同的结果。这是一个 BI 平台，唯一的更改来自计划的 ETL，此时我将 TRUNCATE 缓存表。

这些是 I/O 密集型时间序列计算，数量级为 O(n^4)。我无权更改基础表或索引。此外，许多这些函数都使用相同的中间函数，并且缓存允许使用这些函数。

UDF 并不是真正确定性的，除非它们考虑了数据库状态的变化。重点是什么？ SQL Server有缓存吗？ (具有讽刺意味。)如果 SQL Server 正在缓存，那么它一定会在对架构绑定(bind)的表进行更改时过期。如果它们是架构绑定(bind)的，那么为什么不绑定(bind)函数修改的表呢？我明白为什么不允许使用 procs，尽管这很草率；只是模式绑定(bind)过程。而且，顺便说一句，为什么允许扩展存储过程？你不可能跟踪那些为确保确定性所做的事情!啊!!!

编辑:

我的问题是:有没有办法以可在 View 中使用的方式延迟缓存函数结果？

Answer 1

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

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

我使用过的一个技巧是(我想我将其发布在此处):

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

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

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

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

可以通过首先左连接查找丢失的缓存条目来添加到表中。

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