sql - 为什么人们如此讨厌 SQL 游标？

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 11 年前。

我可以理解由于开销和不便而希望避免使用光标，但似乎存在一些严重的光标恐惧症狂热，人们竭尽全力避免使用光标。

例如，一个问题询问如何使用游标做一些明显微不足道的事情，并且接受的答案建议使用带有递归自定义函数的公共(public)表表达式 (CTE) 递归查询，尽管这限制了可能的行数处理到32(由于sql server中的递归函数调用限制)。在我看来，这是一个延长系统生命周期的糟糕解决方案，更不用说为了避免使用简单的光标而付出的巨大努力。

造成这种疯狂仇恨的原因是什么？是否有一些“知名权威”发布了针对游标的追杀令？游标的内心是否潜藏着某种难以言喻的邪恶，败坏了 children 的道德什么的？

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

相关信息:

SQL Server Fast Forward Cursors

编辑:让我更准确地说:我理解不应使用游标来代替正常的关系操作；这是理所当然的。我不明白的是，人们会不遗余力地避免使用光标，就像他们有虱子之类的东西一样，即使光标是一个更简单和/或更有效的解决方案。让我困惑的是非理性的仇恨，而不是明显的技术效率。

Answer 1

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

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

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

缓慢的问题

在某些圈子中，关系连接是一个谜，人们会编写嵌套游标而不是简单的连接。我见过真正史诗般的嵌套循环操作被写成很多很多的游标。击败 RDBMS 优化。而且运行速度非常慢。

简单的 SQL 重写以用联接替换嵌套游标循环，并且单个扁平游标循环可以使程序的运行时间缩短 100 倍。 [他们认为我是优化之神。我所做的只是用连接替换嵌套循环。仍然使用光标。]

这种困惑常常会导致对游标的指责。然而，问题不是光标，而是光标的误用。

尺寸问题

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

替代方案

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