129

我可以理解由于开销和不便而想要避免使用光标，但看起来有一些严重的光标恐惧症正在发生，人们会竭尽全力避免使用光标。

例如，一个问题询问如何用游标做一些明显微不足道的事情，并且接受的答案是使用带有递归自定义函数的公用表表达式 (CTE) 递归查询提出的，即使这将可以处理的行数限制为 32 （由于 sql server 中的递归函数调用限制）。这让我觉得这是一个糟糕的系统寿命解决方案，更不用说为了避免使用简单的光标而付出的巨大努力。

这种疯狂仇恨的原因是什么？是否有一些“著名的权威”发布了针对游标的教令？游标的心中是不是潜伏着某种无法言喻的邪恶，败坏了孩子们的品德之类的？

维基问题，对答案比代表更感兴趣。

相关信息：

SQL Server 快进游标

编辑：让我更准确地说：我知道不应使用游标代替正常的关系操作；这很简单。我不明白的是，即使光标是一个更简单和/或更有效的解决方案，人们也会竭尽全力避免光标，就像他们有笨蛋或其他东西一样。让我困惑的是非理性的仇恨，而不是明显的技术效率。

4

13 回答 13

74

游标的“开销”只是 API 的一部分。游标是 RDBMS 的各个部分在幕后工作的方式。经常CREATE TABLE和INSERT有SELECT语句，并且执行是明显的内部游标实现。

使用更高级别的“基于集合的运算符”将游标结果捆绑到单个结果集中，这意味着更少的 API 来回。

游标早于提供一流集合的现代语言。旧的 C、COBOL、Fortran 等必须一次处理一行，因为没有可以广泛使用的“集合”概念。Java、C#、Python 等具有一流的列表结构来包含结果集。

缓慢的问题

在某些圈子里，关系连接是个谜，人们会编写嵌套游标而不是简单的连接。我已经看到真正史诗般的嵌套循环操作被写成大量的游标。击败 RDBMS 优化。而且跑得很慢。

简单的 SQL 重写以用连接替换嵌套的游标循环，单个平面游标循环可以使程序在 100 次内运行。[他们认为我是优化之神。我所做的只是用连接替换嵌套循环。仍然使用游标。]

这种混淆常常导致对游标的指控。但是，问题不是光标，而是光标的滥用。

尺寸问题

对于真正史诗般的结果集（即，将表转储到文件），游标是必不可少的。基于集合的操作无法将非常大的结果集具体化为内存中的单个集合。

备择方案

我尝试尽可能多地使用 ORM 层。但这有两个目的。首先，游标由 ORM 组件管理。其次，将 SQL 从应用程序中分离到一个配置文件中。并不是游标不好。对所有这些打开、关闭和获取进行编码不是增值编程。

于 2008-11-13T16:52:42.947 回答
42

光标使人们过度地将程序性思维方式应用于基于集合的环境。

而且他们很慢！

从SQLTeam：

请注意，游标是访问 SQL Server 内部数据的最慢方式。仅当您确实需要一次访问一行时才应使用。我能想到的唯一原因是在每一行上调用一个存储过程。在Cursor Performance 文章中，我发现游标比基于集合的替代方案慢 30 倍以上。

于 2008-11-13T16:41:24.203 回答
20

上面有一个答案，上面写着“游标是访问 SQL Server 内部数据的最慢的方式......游标比基于集合的替代方案慢三十倍以上。”

这种说法在许多情况下可能是正确的，但作为一个笼统的说法，它是有问题的。例如，在我想要执行更新或删除操作影响正在接收持续生产读取的大表的许多行的情况下，我充分利用了游标。运行一次执行这些更新的存储过程最终比基于集合的操作更快，因为基于集合的操作与读取操作冲突并最终导致可怕的锁定问题（并可能完全杀死生产系统，在极端的情况下）。

在没有其他数据库活动的情况下，基于集合的操作普遍更快。在生产系统中，这取决于。

于 2008-11-13T16:48:09.743 回答
9

在基于集合的操作会更好的地方，初学 SQL 开发人员往往会使用游标。尤其是当人们在学习了传统的编程语言后学习 SQL 时，“迭代这些记录”的心态往往会导致人们不恰当地使用游标。

大多数严肃的 SQL 书籍都包含一章禁止使用游标；写得好的游标清楚地表明游标有它们的位置，但不应该用于基于集合的操作。

显然，在某些情况下，游标是正确的选择，或者至少是正确的选择。

于 2008-11-13T16:43:29.707 回答
9

当使用游标方法时，优化器通常不能使用关系代数来转换问题。游标通常是解决问题的好方法，但 SQL 是一种声明性语言，数据库中有很多信息，从约束到统计信息和索引，这意味着优化器有很多选项来解决问题。问题，而游标非常明确地指示解决方案。

于 2008-11-13T16:44:52.887 回答
8

在 Oracle PL/SQL 中，游标不会导致表锁定，并且可以使用批量收集/批量提取。

Oracle 10 中常用的隐式游标

  for x in (select ....) loop
    --do something 
  end loop;

一次隐式获取 100 行。显式批量收集/批量获取也是可能的。

但是 PL/SQL 游标是最后的手段，当您无法解决基于集合的 SQL 的问题时使用它们。

另一个原因是并行化，数据库并行化基于集合的大型语句比逐行命令式代码更容易。这与函数式编程变得越来越流行（Haskell、F#、Lisp、C# LINQ、MapReduce ...）的原因相同，函数式编程使并行化更容易。每台计算机的 CPU 数量正在增加，因此并行化变得越来越成为一个问题。

于 2009-01-10T13:08:21.167 回答
6

一般来说，因为在关系数据库上，使用游标的代码性能比基于集合的操作差一个数量级。

于 2008-11-13T16:41:13.080 回答
6

上面的答案并没有足够强调锁定的重要性。我不是游标的忠实拥护者，因为它们通常会导致表级锁定。

于 2008-12-28T16:51:08.667 回答
3

值得我读的是，游标将执行其基于集合的对应物的“一个”位置在运行总数中。在一个小表上，按列对行求和的速度有利于基于集合的操作，但随着表的行大小增加，游标将变得更快，因为它可以简单地将运行总值带到下一次遍历环形。现在你应该在哪里做一个运行总计是一个不同的论点......

于 2008-11-14T00:53:46.487 回答
2

除了性能（非）问题之外，我认为游标的最大失败是调试起来很痛苦。尤其是与大多数客户端应用程序中的代码相比，调试往往相对容易，语言功能往往更容易。事实上，我认为几乎所有在 SQL 中使用游标执行的操作都应该首先发生在客户端应用程序中。

于 2009-06-09T22:55:09.720 回答
1

您可以发布该光标示例或链接到该问题吗？可能有比递归 CTE 更好的方法。

除了其他注释之外，游标使用不当（通常）会导致不必要的页/行锁定。

于 2008-11-13T16:45:14.180 回答
1

您可能会在第二段之后结束您的问题，而不是仅仅因为他们与您的观点不同而称他们为“疯子”，或者试图嘲笑可能有充分理由感受他们的方式的专业人士。

至于您的问题，虽然在某些情况下可能需要使用光标，但根据我的经验，开发人员决定“必须”比实际情况更频繁地使用光标。在我看来，有人在过多使用游标与不使用游标时犯错的机会要高得多。

于 2008-11-13T17:55:37.453 回答
0

基本上 2 块代码做同样的事情。也许这是一个有点奇怪的例子，但它证明了这一点。SQL Server 2005：

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

单次更新需要 156 毫秒，而光标需要 2016 毫秒。

于 2008-11-13T16:56:39.787 回答