通常认为，应尽可能避免在存储过程中使用游标(用基于集合的逻辑等代替)。如果我们遇到需要迭代某些数据并且可以以只读方式进行操作的情况，那么快进(只读前向)游标的效率比while循环差多少？从我的调查来看，似乎光标选项通常更快，并且使用的读取次数和CPU时间更少。我没有做任何广泛的测试，但这是别人发现的吗？这种游标(快进)是否会带来额外的开销或者资源，而这些开销或者资源可能是我不知道的昂贵资源。

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

谢谢

解决方案

回答

人们之所以避免使用游标，是因为它们通常比简单的while循环难于编写，但是while循环可能会很昂贵，因为我们不断从表中选择数据，无论是临时的还是其他方式。

使用游标(快进只读)，数据将保留在内存中，并且专门为循环而设计。

本文强调，普通游标的运行速度比while循环快50倍。

回答

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

我们所指的"一般接受的"是有效的，但现在已经过时且不正确，这是假定快进游标的行为与广告中所宣传和执行的相同。基于SQL2005及更高版本进行一些测试和研究

回答

尽管快进游标确实在Sql Server 2005中进行了一些优化，但从性能的角度来看它们并不接近基于集合的查询。在极少数情况下，不能将游标逻辑替换为基于集合的查询。游标在本质上总是会变慢，部分原因是我们必须不断中断执行才能填充局部变量。

以下是一些参考资料，如果我们研究此问题，这只会是冰山一角：

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

http://sqlblog.com/blogs/adam_machanic/archive/2007/10/13/cursors-run-just-fine.aspx

回答

如果我们想要比FAST FORWARD更快的光标，请使用STATIC光标。它们比快速前进更快。速度不是特别快，但可以有所作为。

回答

该答案希望巩固迄今为止给出的答复。

1)尽可能使用基于集合的查询逻辑，即尝试仅将SELECT，INSERT，UPDATE或者DELETE与相应的FROM子句或者嵌套查询一起使用，这些查询几乎总是会更快。

2)如果上述方法不可行，则在SQL Server 2005+中，" FAST FORWARD"游标非常有效且性能良好，因此应优先使用while循环。

回答

"如果我们想要比FAST FORWARD更快的游标，请使用STATIC游标。它们比FAST FORWARD快。不是非常快，但可以有所作为。"

没那么快！根据微软的说法：
"通常，当发生这些转换时，游标类型会降级为更昂贵的游标类型。通常，(快速)仅向前游标是性能最高的，其次是动态，键集，最后是静态(通常是性能最低的)。 "

来自：http://blogs.msdn.com/b/mssqlisv/archive/2006/06/23/644493.aspx