sql-server - 使用游标的优缺点(在SQL Server中)

Question

我在这里问了一个问题Using cursor in OLTP databases (SQL server)

人们回答说永远不要使用游标。

我觉得游标是非常有用的工具(我不认为Microsoft支持差劲的开发人员使用游标)。假设您有一个表，其中一行中的列值取决于同一列的值在上一行中。如果这是一次后端流程，您是否认为使用游标是可以接受的选择？

在我的脑海中，我可以想到一些场景，在这些场景中，我觉得使用游标应该不会感到羞耻。如果让您感到不适，请告诉我。

1>一个一次性的后端流程，用于清除不良数据，该过程将在几分钟内完成执行。
2>批处理过程长时间运行一次(每年一次)。
如果在上述情况下，其他进程没有明显的负担，那么花额外的时间编写代码来避免游标是否合理？换句话说，在某些情况下，开发人员的时间比几乎不影响其他任何事情的过程的性能更为重要。

我认为，在某些情况下，您应认真尝试避免使用游标。
1>从网站调用的存储过程可以很经常地被调用。
2> SQL作业每天要运行多次，并且消耗大量资源。

我认为在不分析手头的任务并将其与替代方案进行权衡的情况下做出“不应该使用游标”这样的概括性表述是非常肤浅的。

请让我知道您的想法。

Answer 1

在几种情况下，游标实际上比基于集合的等效项表现更好。运行总计是经常想到的-寻找Itzik的话(并忽略涉及SQL Server 2012的任何内容，SQL Server 2012添加了新的开窗功能，可以在这种情况下让游标赚钱)。

人们使用游标的最大问题之一是它们执行缓慢，使用临时存储等。这部分是因为默认语法是带有各种无效默认选项的全局游标。下次您使用不需要做诸如UPDATE...WHERE CURRENT OF之类的游标的操作时(我已经避免了整个职业)，请比较以下两个语法选项，以使其相当合理:

DECLARE c CURSOR 
    FOR <SELECT QUERY>;

DECLARE c CURSOR 
    LOCAL STATIC READ_ONLY FORWARD_ONLY
    FOR <SELECT QUERY>;

实际上，第一个版本表示未记录的存储过程sp_MSforeachdb中的错误，如果任何数据库的状态在执行过程中发生更改，则该错误会跳过数据库。随后，我编写了自己的存储过程版本(请参见 here)，该版本既修复了该错误(仅通过使用上述语法的后一版本)，又添加了一些参数来控制选择哪个数据库。

许多人认为方法论不是游标，因为它没有说 DECLARE CURSOR。我见过有人争论说while循环比游标( which I hope I've dispelled here)快，或者使用 FOR XML PATH进行组连接并没有执行隐藏的游标操作。在很多情况下查看计划都会显示出事实。

在许多情况下，在基于集合的情况下更适合使用游标。但是，在许多有效的用例中，基于集合的等价项要编写起来要复杂得多，以至于优化器无法为两者生成计划，也可能无法(例如，在维护表中循环访问以更新统计信息的维护任务，为结果中的每个值调用存储过程等)。对于许多大型多表查询而言，情况也是如此，其中计划变得过于庞大，以至于优化程序无法处理。在这些情况下，最好先将一些中间结果转储到临时结构中。对于某些基于集合的游标等效项(例如运行总计)也是如此。我还写了另一种方法，人们几乎总是本能地考虑使用while循环/游标，并且存在 clever set-based alternatives that are much better。

更新2013-07-25

只是想添加一些我写过的有关游标的博客文章，如果必须使用游标，应该使用哪些选项，并使用基于集合的查询而不是循环来生成集合:

Best Approaches for Running Totals - Updated for SQL Server 2012

What impact can different cursor options have?

生成没有循环的集合或序列: [Part 1] [Part 2] [Part 3]