可以理解由于开销和不便而想要避免使用光标，但看起来有一些严重的光标恐惧症正在发生，人们会竭尽全力避免使用光标。
例如，一个问题询问如何用游标做一些明显微不足道的事情，并且接受的答案是使用带有递归自定义函数的公用表表达式 (CTE) 递归查询提出的，即使这将可以处理的行数限制为 32 （由于 sql server 中的递归函数调用限制）。这让我觉得这是一个糟糕的系统寿命解决方案，更不用说为了避免使用简单的光标而付出的巨大努力。
这种疯狂仇恨的原因是什么？是否有一些“著名的权威”发布了针对游标的教令？游标的心里是不是潜伏着某种无法言喻的邪恶，败坏了孩子们的品德之类的？
维基问题，对答案比代表更感兴趣。
编辑：让我更准确地说：我知道不应使用游标代替正常的关系操作；这很简单。我不明白的是，即使光标是一个更简单和/或更有效的解决方案，人们也会竭尽全力避免光标，就像他们有笨蛋或其他东西一样。让我困惑的是非理性的仇恨，而不是明显的技术效率。
游标的“开销”只是 API 的一部分。游标是 RDBMS 的各个部分在幕后工作的方式。经常CREATE TABLE和INSERT有SELECT语句，并且执行是明显的内部游标实现。
CREATE TABLE
INSERT
SELECT
使用更高级别的“基于集合的运算符”将游标结果捆绑到单个结果集中，这意味着更少的 API 来回。
游标早于提供一流集合的现代语言。旧的 C、COBOL、Fortran 等必须一次处理一行，因为没有可以广泛使用的“集合”概念。Java、C#、Python 等具有一流的列表结构来包含结果集。
缓慢的问题
在某些圈子里，关系连接是个谜，人们会编写嵌套游标而不是简单的连接。我已经看到真正史诗般的嵌套循环操作被写成大量的游标。击败 RDBMS 优化。而且跑得很慢。
简单的 SQL 重写以用连接替换嵌套的游标循环，单个平面游标循环可以使程序在 100 次内运行。[他们认为我是优化之神。我所做的只是用连接替换嵌套循环。仍然使用游标。]
这种混淆常常导致对游标的指控。但是，问题不是光标，而是光标的滥用。
尺寸问题
对于真正史诗般的结果集（即，将表转储到文件），游标是必不可少的。基于集合的操作无法将非常大的结果集具体化为内存中的单个集合。
备择方案
我尝试尽可能多地使用 ORM 层。但这有两个目的。首先，游标由 ORM 组件管理。其次，将 SQL 从应用程序中分离到一个配置文件中。并不是游标不好。对所有这些打开、关闭和获取进行编码不是增值编程。
