所以我有这个数据库可以帮助组织学术会议的信息，但是有时候我们需要知道某个项目是否“不完整” - 可能导致某些不完整项目的规则有点复杂，所以我将它们构建为一个标量函数，如果项目完成，则返回true，否则返回0。使用函数的SQL效率
我遇到的问题是，当我在大型数据表上调用函数时，大约需要1分钟才能返回结果。这会导致网站暂停。
我不认为我能做的事情很多。但是我想知道是否有人知道这种情况下的任何技术？当你有这样一个大功能时，你会怎么做？我真的可以存储函数的结果，然后让它每隔一段时间刷新一次吗？有没有一种好的和有效的方法来存储它，但如果记录被更新，刷新它？我认为我可以将其作为触发器或某种东西，但如果有人经历了一次大的更新，它将会持续下去。
感谢，
迈克
如果您的功能效率低下，则必须处理过期数据或缓慢结果。
听起来你更关心性能，就像@cmsjr说的那样，将数据添加到表中。
此外，创建一个cron作业来定期刷新结果。也许在数据库表中添加一个updated列，然后cron作业只需要重新处理这些行。
还有一件事，功能有多复杂？您可以通过将它从SQL中拉出来减少函数的运行时间，也许将它写入数据库层之上的一层？
如果函数是确定性的，你可以将其添加为一个计算列，然后指数吧，这可能会提高你的表现。
MSDN文档。
问题是该函数查看单个记录，并具有诸如“如果此列为空”或“如果该列大于0”等逻辑。这个逻辑基本上是查询优化器的一个黑盒子。它可能会使用这些字段上的索引，但无法知道它。它必须在每个可用记录上运行此逻辑，而不是使用功能上的条件来削减结果集。用数据库的说法，我们会说UDF是不可靠的。
因此，您需要的是将不完整会议的逻辑构建到查询优化器可以更好地利用的结构中：将条件匹配到索引等等。离开我的头顶，您的选择包括视图或计算列。
我遇到过在SQL Server 2000中至少有一个函数会执行非常糟糕的事情，只是将该逻辑打破并将其放入查询可以极大地加快速度的情况。这是一个边缘案例，但如果您认为该功能很好，那么您可以尝试。否则，我会计算列并将其存储为其他人所建议的。
不要太确定你不能调整你的功能。
通常，对于“完整性”检查，最糟糕的时间是记录实际完成时。对于其他任何事情，您可以尽早中止，因此要么先测试计算速度最快的案例，要么测试最有可能导致记录被标记为不完整的案例。
对于批量更新，您必须只是坐下来等待，或者想出一个系统，您可以先通过更快的检查运行较不完整的系统，然后在后台执行更彻底的检查。
SQL Server中的标量UDF目前表现很差。我只是将它们用作精心策划的最后手段。使用其他技术（甚至是深度嵌套视图或内嵌TVF，它们构建所有规则并重新加入）可能有解决您的问题的方法，但很难说没有看到需求就可以知道。
正如Cade Roux所说的Scalar functions are evil它们被解释为每行，因此在涉及性能方面是一个大问题。如果可能的话，使用表值函数或计算列
感谢球员......我想我要添加一个固定列，然后定期刷新它。我也可以通过网站设法运行刷新程序。我不认为我能做些什么关于这个功能。只有很多规则，他们都是愚蠢的和小规则，但他们打了很多桌子，每个人都必须检查。例如，我们必须检查父项目（面板）上有多少个子项目（论文）。然后，我们将这些数据与有多少孩子应该在这种类型的面板上进行比较......无论如何 - 感谢您的帮助。 – Mike 2009-08-14 14:39:19