为啥人们如此讨厌 SQL 游标？ [关闭]

Posted 2023-02-16

【中文标题】为啥人们如此讨厌 SQL 游标？ [关闭]

【英文标题】：Why do people hate SQL cursors so much? [closed]为什么人们如此讨厌 SQL 游标？ [关闭]

【发布时间】：2010-09-22 04:39:37

【问题描述】：

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

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

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

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

相关信息：

SQL Server Fast Forward Cursors

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

【问题讨论】：

我认为您的编辑说明了一切......在几乎所有情况下（我遇到过）都有一种方法可以用性能更好的集合替换光标基于情况。您说的很简单，但您了解差异。

我喜欢这个问题的标签！

关于递归 CTE 限制为 32 的部分是无稽之谈。大概您正在考虑递归触发器和32 的最大值@@NESTLEVEL。可以在查询中使用OPTION (MAXRECURSION N) 设置，默认100 和0 表示无限制。

@MartinSmith：默认限制现在是 100，最大值是 32K sql-server-helper.com/error-messages/msg-310.aspx

@MartinSmith：谢谢，我的错误——实际上是两个错误；）第一个是误读了参考资料（我假设 32K 限制 = 'unlimited'），第二个是错误的原因——在引用的例子中, 32 的递归限制来自递归函数，而不是 CTE。当时我可能正在使用 SQL Server 2000，或者可能是 2008，希望现在更好:)。已编辑问题以澄清 - 感谢您的更正！

【参考方案1】：

游标使人们在基于集合的环境中过度应用程序性思维方式。

他们是慢！！！

来自SQLTeam：

请注意，光标是 在 SQL 中访问数据的最慢方法 服务器。仅应在以下情况下使用 您确实需要一次访问一行 时间。我能想到的唯一原因 因为那是调用存储过程 在每一行。在Cursor Performance article我发现 光标超过三十次 比基于集合的替代方案慢。

【讨论】：

那篇文章已有 7 年的历史了，您认为在此期间情况可能会发生变化吗？

我也认为游标真的很慢，通常应该避免。但是，如果 OP 指的是我认为他是的问题，那么游标是那里的正确解决方案（由于内存限制，一次流式记录一个）。

更新的文章没有更正相对速度测量，但它确实提供了一些很好的优化和替代方案。注意原文章说游标比while循环快50倍，这很有意思

@BoltBait：我个人认为，如果你做出这样的笼统断言，你就不可能真正活到 45 岁：-P

@BoltBait：你们这些孩子离开我的草坪！

【参考方案2】：

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

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

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

【讨论】：

听起来像是证明规则的例外。

@[Joel Coehoorn]：我一直没听懂这句话。

@[Steven A. Lowe] phrases.org.uk/meanings/exception-that-proves-the-rule.html 将异常理解为“遗漏的内容”，并注意这里的规则类似于“在大多数情况下游标不好”。

@delm：谢谢你的链接，现在我对这句话的理解更差了！

@[Steven A. Lowe] 基本上它的意思是，如果你用子案例“打破规则”，就必须打破一般规则，因此存在规则。例如来自链接：（“如果我们有类似‘周日免费入场’这样的声明，我们可以合理地假设，作为一般规则，入场是收费的。”）

【参考方案3】：

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

【讨论】：

SQL 调试起来很痛苦，即使没有游标。 Visual Studio 中的 MS SQL 单步执行工具似乎不喜欢我（它们经常挂起，或者根本不触发断点），所以我通常只使用 PRINT 语句 ;-)

【参考方案4】：

在 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 数量正在增加，因此并行化变得越来越成为一个问题。

【参考方案5】：

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

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

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

缓慢的问题

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

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

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

尺寸问题

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

替代品

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

【讨论】：

“游标是 RDBMS 在后台工作的方式。”如果你的意思是专门的 SQL Server，好吧，好吧，我对此一无所知。但是我研究过多个 RDBMS（和 ORDBMS）（在 Stonebraker 下）的内部，但没有一个人这样做。例如：Ingres 在内部使用相当于“结果集”的元组。

@Richard T：我正在处理有关 RDBMS 源的二手信息；我会修改声明。

“我见过真正史诗般的嵌套循环操作写成大量的游标。”我也经常看到他们。难以置信。

【参考方案6】：

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

【讨论】：

好的，谢谢！如果没有阻止它的选项（只读、只转发等），它们当然会，任何（sql server）操作都会继续占用几行，然后是几页行。

??这是您的锁定策略而不是游标的问题。即使是 SELECT 语句也会添加读锁。

【参考方案7】：

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

【讨论】：

如果你的意思是“运行总计”某种类型的聚合（最小、最大、总和），任何有能力的 DBMS 都会击败客户端、基于光标的解决方案，如果仅仅是因为该功能在引擎中执行，没有客户端 服务器开销。也许 SQL Server 不称职？

@[Richard T]：我们讨论的是存储过程中的服务器端游标，而不是客户端游标；很抱歉造成混乱！

【参考方案8】：

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

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

【讨论】：

请仔细阅读，汤姆——确切的说法是“疯狂的仇恨”； “讨厌”是形容词“疯狂”的宾语，而不是“人”。英语有时会有点难；-)

【参考方案9】：

基本上 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 毫秒。

【讨论】：

嗯，是的，它证明了这是使用光标的一种非常愚蠢的方式！但是如果每一行的更新都依赖于日期顺序中前一行的值呢？

BEGIN TRAN SELECT TOP 1 baseval FROM table ORDER BY timestamp DESC INSERT table (fields) VALUES (vals, 包括从先前记录的派生值) COMMIT TRAN

@doofledorfer：这将根据日期的最后一行插入一行，而不是按日期顺序按前一行的值更新每一行

要真正使用游标，你应该在更新中使用 WHERE CURRENT OF

【参考方案10】：

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

除了其他 cmets，游标在使用不当时（经常）会导致不必要的页/行锁。

【讨论】：

有一个更好的方法 - 一个怪异的光标;-)

【参考方案11】：

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

【参考方案12】：

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

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

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

【参考方案13】：

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

【讨论】：

你有这方面的基准或参考吗？我没有注意到任何如此剧烈的性能下降......但也许我的表没有足够的行数（通常是一百万或更少）？

哦，等一下，我明白你的意思了——但我绝不会提倡使用游标而不是集合操作，只是不会走极端来避免使用游标

我记得我第一次做 SQL 的时候，我们必须将 50k 的每日数据文件从大型机导入到 SQL Server 数据库中......我使用了一个游标，发现导入正在执行使用光标大约需要 26 小时...当我更改为基于集合的操作时，该过程需要 20 分钟。