游标真的有多慢，以及哪种更好的替代方案？

我一直在阅读游标是漂亮的slow和一个应该除非选择避开它们。我试图优化我的存储过程，其中一个使用游标。它经常被我的应用程序和许多用户（20000）和行更新所调用。我在想，也许我应该使用别的东西作为替代。游标真的有多慢，以及哪种更好的替代方案？

我想要做的或想要的是获取记录列表，然后根据每个行值进行操作。因此，对于e.g我们不得不说 -

Employee - Id,Name,BenefitId,StartDate,EndDate

因此，基于benefitId我需要做的起始日期使用日期和结束日期和更新员工的详细信息之间的日期不同的计算。我只是用这个人为的例子来说明我的情况。

你对此有何看法？使用临时表或用户定义函数的游标是否有更好的选择？你应该什么时候选择他们，或者我们应该永远不使用游标？谢谢大家的帮助。

来源

2010-11-22 Vishal

我已经改变了游标和移动距离超过24小时的处理时间不到一分钟。

，以帮助您了解如何解决与基于集合的逻辑你的PROC，请阅读本： http://wiki.lessthandot.com/index.php/Cursors_and_How_to_Avoid_Them

来源

2010-11-22 22:50:25 HLGEM

我曾经将存储过程从游标更改为基于逻辑的设置。运行时间从8小时变为22秒。这就是我们正在谈论的那种差异。

而不是一次采取不同的行动记录，使用数据的几个通行证。更新并设置field1 = A，其中field2为X，然后更新并设置field1 = B，其中field2为Y等。

来源

2010-11-22 22:45:56 SteveCav

游标会逐行处理，或者如果您的名字是“Row By Agonizing Row” Jeff Moden。

这只是one example如何做基于集合的SQL编程，而不是RBAR，但它最终取决于您的光标在做什么。

而且，看看这个StackOverflow上：

RBAR vs. Set based programming for SQL

来源

2010-11-22 22:47:06

-1

首先，这听起来像你想在你的存储特效把一些业务逻辑。这通常是你想避免的事情。更好的解决方案是有一个封装了业务逻辑的中间层。这样你的数据层就保持纯粹的数据。

要回答你原来的问题，这真的取决于你使用的游标。在某些情况下，您可以使用表变量或临时表。你必须记住释放临时表，所以我建议尽可能使用表变量。但有时候，使用游标是没有办法的。也许原来的DBA没有足够标准化（或标准化太多），并且你不得不使用游标遍历多个表，而没有任何外键关系。

来源

2010-11-22 22:54:33 SRM

许多地方要求所有数据库通过存储的通配符。在存储过程中执行复杂的处理是一个更好的做法，dba可以调整性能而不是在应用程序中放置类似的东西。此外，几乎所有从应用程序运行的游标都可以轻松地用基于集合的逻辑来代替。除了一些面向dba的管理任务外，很少需要游标。如果您正在插入，更新或从一个或多个表中删除，那么您可以以基于集合的方式完成这项工作，几乎可以在100％的时间内完成。 – HLGEM 2010-11-22 23:20:17

游标真的有多慢，以及哪种更好的替代方案？

回答

相关问题