你会为SQL Cursors...Any使用案例辩护吗？

Question

我先来。

我100%支持布景行动阵营。但是，当整个所需输入域上的集合逻辑导致查询显著减慢、爬行或基本上耗费无限时间时，会发生什么情况？

在这种情况下，我将使用一个很小的游标(或while循环)，它可能有几十行(而我的目标是数百万行)。因此，我仍然在(分区的子集)中工作，但我的检索速度更快。

当然，一种更快的解决方案是从外部并行调用分区的输入域，但这会在外部系统中引入交互，并且当“足够好”的速度可以通过串行循环实现时，可能不值得这样做(特别是在开发期间)。

Answer 1

当然，在很多地方，游标可能比基于集合的操作更好。

其一是，如果要更新表中的大量数据(例如，SQL Agent作业按计划预计算数据)，则可以使用游标在多个较小的集合(而不是一个较大的集合)中进行更新，以减少并发锁定的数量，从而减少与访问数据的其他进程发生锁争用和/或死锁的机会。

另一个是您是否希望使用sp_getapplock存储过程获取应用程序级别的锁，当您希望确保由多个进程轮询的行只被检索一次(example here)时，该存储过程非常有用。

但总的来说，我同意如果可能的话，最好开始使用基于集合的操作，并且只有在出于功能或性能原因需要时才使用游标(有证据支持后者)。

Answer 2

我在很多情况下都需要读取配置表中的行，并生成和执行代码，或者在许多元编程场景中。

也有一些情况下，游标只是因为优化器不够智能而表现更好。在这些情况下，要么是您头脑中的元信息根本没有通过表上的索引或统计信息透露给优化器，要么是代码太复杂，无法以基于指针的方式对连接(通常是重新连接)进行优化。在SQL Server 2005中，我相信CTE往往会使代码看起来简单得多，但很难知道优化器是否也将它们视为更简单-它归结为将执行计划与您认为可以最有效地完成的执行计划进行比较，并进行调用。

一般规则-除非必要，否则不要使用游标。但在必要的时候，不要让自己为此感到难受。

Answer 3

有很多不同的cursor behaviors。

• 静态vs密钥集vs动态
• 滚动vs仅向前vs FAST

或非

• 乐观或只读或非
• 本地vs全局(至少这很容易)

你应该永远不要使用游标，除非你能解释所有这些选项，以及哪些选项在缺省情况下是on 。

所以，我从来没有这样做过。

相反，当我想要遍历T-SQL中的某些东西时...我将它加载到一个变量表中，这有点像一个本地静态滚动游标……除了它可以被索引和连接(编辑:以及阻止使用并行性的缺点)。