SQL Server快进游标

Question

通常认为应尽可能避免在存储过程中使用游标(替换为基于集合的逻辑等).如果您采用需要迭代某些数据的情况,并且可以以只读方式进行,那么快进(只读向前)光标的效率是否比while循环更低或更低？从我的调查来看,它看起来好像光标选项通常更快,并且使用更少的读取和CPU时间.我没有做过任何广泛的测试,但这是其他人发现的吗？这种类型的游标(快进)会带来额外的开销或资源,这些资源可能很昂贵而且我不知道.

所有关于不使用游标的讨论都是关于在基于集合的方法可用时避免使用游标,以及使用可更新游标等.

谢谢

Answer 1

虽然快速游标在Sql Server 2005中确实有一些优化,但就性能而言,它们在任何接近基于集合的查询的位置都是不正确的.极少数情况下,游标逻辑不能被基于集合的查询替换.游标本身总是较慢,部分原因是你必须不断中断执行以填充你的局部变量.

这里有一些参考文献,如果你研究这个问题,它只会是冰山一角:

http://www.code-magazine.com/Article.aspx?quickid=060113

http://dataeducation.com/re-inventing-the-recursive-cte/

Answer 2

SQL Server 中避免使用游标的“最佳实践”可以追溯到 SQL Server 2000 及更早版本。SQL 2005 中引擎的重写解决了与游标问题相关的大多数问题，特别是引入了快进选项。游标并不一定比基于集合的游标差，并且在 Oracle PL/SQL (LOOP) 中得到了广泛且成功的使用。

您提到的“普遍接受的”是有效的，但现在已经过时且不正确 - 继续假设快进光标的行为如广告中所宣传和执行的那样。根据 SQL2005 及更高版本的发现进行一些测试和研究