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

Question

我可以理解，我想避免由于开销和不便而不得不使用游标，但似乎出现了一些严重的光标恐惧症，人们为了避免使用光标而付出了很大的努力。

例如，有一个问题询问如何使用带有递归自定义函数的公共表表达式(CTE)递归查询来处理游标和接受的答案，尽管这限制了可以处理的行数为32 (因为sql server中的递归函数调用限制)。我觉得这是一个糟糕的系统寿命解决方案，更不用说为了避免使用简单的游标而付出的巨大努力。

这种疯狂仇恨的原因是什么？有什么“知名权威”对游侠发出了法特瓦吗？难道一些无法形容的邪恶潜藏在游侠的心中，腐蚀了孩子们的道德或什么的吗？

Wiki问题，更感兴趣的是答案而不是代表。

相关信息：

Server快速转发游标

编辑:让我更精确地说:我知道不应该使用游标来代替正常的关系操作；这是一个不需要考虑的问题。我不明白的是，即使光标是一个更简单和/或更有效的解决方案，人们还是会不顾一切地避开游标，比如它们有虱子之类的东西。令我困惑的是非理性的仇恨，而不是明显的技术效率。

Answer 1

带有游标的“开销”仅仅是API的一部分。游标是RDBMS的部分是如何在引擎盖下工作的。CREATE TABLE和INSERT通常都有SELECT语句，实现是明显的内部游标实现。

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

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

慢速问题

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

简单的SQL重写可以用联接替换嵌套的游标循环，而一个单一的平面游标循环可以使程序在第100次运行。他们认为我是优化之神。我所做的就是用联接替换嵌套循环。还用游标。

这种混乱常常导致对游标的起诉。然而，问题不在于游标，而是游标的误用。

的大小问题

对于真正具有史诗意义的结果集(即将表转储到文件中)，游标是必不可少的。基于集合的操作不能将非常大的结果集作为内存中的单个集合来实现。

替代品

我尽量使用ORM层。但这有两个目的。首先，游标由ORM组件管理。其次，将SQL与应用程序分离为一个配置文件。不是因为游标不好。就是编码所有这些打开、关闭和获取都不是增值编程。

Answer 2

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

他们是SLOW！

来自SQLTeam

请注意，游标是访问Server内部数据的最慢方式。应该只在真正需要一次访问一行时使用。我能想到的唯一原因是在每一行上调用一个存储过程。在光标性能项目中，我发现游标比基于集合的备选方案()慢30倍以上。

Answer 3

上面有一个答案：“游标是访问Server内部数据的最慢的方式.游标比基于集合的选项慢30倍以上。”

这种说法在许多情况下可能是正确的，但作为一种笼统的陈述，它是有问题的。例如，在需要执行更新或删除操作的情况下，我已经很好地利用了游标，这些操作影响到正在接收不断生成读取的大型表的许多行。运行存储过程(每次只更新一行)比基于集的操作更快，因为基于集合的操作与读取操作发生冲突，并最终导致可怕的锁定问题(在极端情况下，可能会完全杀死生产系统)。

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