写了那么多天的学习之路系统文章，感觉进入了一个怪圈，就是写来写去又回到一些知识点的讲解里面去了，这点并不是我的初衷。
既然要写就要写一些有用的的东西，我相信大家如果随便搜索相关的资料都能找到比我这上面更好的。但是学习经验这些东西那就不那么好搜了，毕竟每个人的理解接受能力不一样。还是希望能够帮助到更多的人，能让更多人更好的掌握SQL这门技术。当然这里有个小愿望，如果大家觉得我写的还行，还请多多分享推荐一下，谢谢您了~
上面说了一堆废话，今天说说工作中可能会用的游标，为什么说可能？因为我更希望大家能不用就不用。不用的理由有以下几个：
-
首先也是最重要的，如果使用游标，就严重违背了关系模型，关系模型要求按照集合来考虑问题。
-
其次，游标逐行操作会带来一定开销，与集合相比，游标的代码比集合的代码要慢很多倍
-
第三，使用游标需要写的代码很多，因为你得表述如何处理数据(声明游标，打开游标，遍历游标，关闭游标，释放游标)。而集合的解决方法，只要关注逻辑方面。只要描述要获取什么，不必描述如何获取。因此与集合相比，游标的解决方法代码更长，可读性低，也比较难维护。
但是有些地方用集合的方法无法解决的时候，必须使用游标的话还是得使用。
这里还是介绍一下基本的用法：
-
在查询的基础上声明游标。
-
打开该游标
-
从第一个游标记录中把列值提取到指定的变量
-
当还没有到游标最后一行时，循环遍历游标记录；在每次遍历中，从当前游标记录中把列值去到指定的变量，在为当前执行相应的处理。
-
关闭游标
-
释放游标
针对上面的操作步骤我们写个例子给大家看一下会更清楚一些：
SET NOCOUNT ON;
USE TSQLFundamentals2008;
DECLARE @Result TABLE
(
custid INT,
ordermonth DATETIME,
qty INT,
runqty INT,
PRIMARY KEY(custid,ordermonth)
);
DECLARE
@custid AS INT,
@prvcustid AS INT,
@ordermonth DATETIME,
@qty AS INT,
@runqty AS INT;
--声明游标
DECLARE c CURSOR FAST_FORWARD/*read only,forward only*/ FOR
SELECT custid,ordermonth,qty
FROM Sales.CustOrders
ORDER BY custid,ordermonth;
--打开游标
OPEN c
--遍历游标
FETCH NEXT FROM c INTO @custid,@ordermonth,@qty;
SELECT @prvcustid=@custid,@runqty=0;
WHILE @@FETCH_STATUS = 0
BEGIN
IF @custid<>@prvcustid
SELECT @prvcustid=@custid,@runqty=0;
SET @runqty=@runqty+@qty;
INSERT INTO @Result
VALUES ( @custid, @ordermonth, @qty, @runqty );
FETCH NEXT FROM c INTO @custid,@ordermonth,@qty;
END
--关闭游标
CLOSE c;
--释放游标
DEALLOCATE c;
--查询游标执行完后的结果
SELECT custid,
CONVERT(VARCHAR(7),ordermonth,121) AS ordermonth,
qty,
runqty FROM @Result
ORDER BY custid,ordermonth
上面的代码先是声明了一个游标，用CustOrders视图中按客户ID和订单月份的顺序返回基本数据行；之后通过循环来遍历每个记录。代码跟踪客户当前连续总订货量，把值保存到变量@runqty中，每次找到一个新客户时重置这个变量。对于结果中返回的每一行，代码把当前月份的订货量@qty和变量@runqty相加，就可以得出当前月份的连续总订货量，再把客户ID，订单月份，当前月份订单货量以及连续货量作为一行插入到表@Result中。处理完成所有游标记录后，再查询表变量以显示生成的连续聚合值。下图是查询结果：
从图上我们就可以清楚的看到runqty列根据客户ID连续计算qty列的和。这就是游标的一个示例。
我在做项目的时候也有过这样的经历，因为业务需求，必须对两行之间的数进行相减返回相减后的结果，这就必须使用到游标来予以解决了，当时因为数据量比较少，计算的还比较快。但是随着数据的增加，这样的计算效率肯定会大打折扣。所有还是建议在迫不得已的情况下尽量减少游标的使用。