MSSQL游标的原理及示例

游标的原理 
    一般情况下,SQL查询结果都是多条纪录的结果集,而高级语言一次只能处理一条纪录,用游标机制,将多条纪录一次一条读取出来处理。
从而把对集合的操作转化为对单个纪录的处理。游标使用的步骤如下:

1、说明游标。说明游标的时候并不执行select语句。
 declare <游标名> cursor for <select语句>;
 
2、打开游标。打开游标实际上是执行相应的select语句,把查询结果读取到缓冲区中。这时候游标处于活动状态,指针指向查询结果集的第一条纪录。
 open <游标名>;
 
3、推进游标指针并读取当前纪录。用fetch语句把游标指针向前推进一条纪录,同时将缓冲区中的当前纪录读取出来送到变量中。
fetch语句通常用在一个循环结构体中,通过循环执行fetch语句逐条取出结果集中的行进行处理。现在好多数据库中,还允许任意方向任意步长易懂游标指针,
而不仅仅是把游标指针向前推进一行了。
 fetch <游标名> into <变量1>,<变量2>...
 
4、关闭游标。用close语句关闭游标,释放结果集占用的缓冲区及其他资源。游标关闭后,就不再和原来的查询结果集相联系。但游标可以再次打开,
与新的查询结果相联系。
 close <游标名>;

 5、释放游标
游标使用不再需要之后,要释放游标。DEALLOCATE语句释放数据结构和游标所加的锁。
语法如下:DEALLOCATE [GLOBAL] cursor_name | cursor_variable_name
游标的基本使用模板
declare 
        declare  游标名[scroll]  cursor  for select语句[for update [of列表名]]

        定义一个游标,使之对应一个select语句

       for update任选项,表示该游标可用于对当前行的修改与删除

open

       打开一个游标,执行游标对应的查询,结果集合为该游标的活动集

       open  游标名

fetch

       在活动集中将游标移到特定的行,并取出该行数据放到相应的变量中

       fetch [next | prior | first | last | current | relative n | absolute m] 游标名into  [变量表]

close

       关闭游标,释放活动集及其所占资源。需要再使用该游标时,执行open语句

       close  游标名

deallocate

       删除游标,以后不能再对该游标执行open语句

       deallocate 游标名

 

@@FETCH_STATUS返回被FETCH 语句执行的最后游标的状态.

       0 fetch语句成功
       -1 fetch语句失败
       -2 被提取的行不存在

DECLARE Employee_Cursor CURSOR FOR
SELECT EmployeeID, Title
FROM AdventureWorks.HumanResources.Employee
OPEN Employee_Cursor
FETCH NEXT FROM Employee_Cursor
WHILE @@FETCH_STATUS = 0
BEGIN
--//TO DO...  
FETCH NEXT FROM Employee_Cursor
END
CLOSE Employee_Cursor
DEALLOCATE Employee_Cursor
GO

游标性能问题
最好的改进游标性能的技术就是:能避免时就避免使用游标,尽可能用对应的语句完成相同的功能(一般情况下,考虑得当效率能大大提升)。

SQL Server是关系数据库,其处理数据集比处理单行好得多,单独行的访问根本不适合关系DBMS。若有时无法避免使用游标,
则可以用如下技巧来优化游标的性能。

(1). 除非必要否则不要使用static/insensitive游标。打开static游标会造成所有的行都被拷贝到临时表。这正是为什么它对变化不敏感的原因
——它实际上是指向临时数据库表中的一个备份。
很自然,结果集越大,声明其上的static游标就会引起越多的临时数据库的资源争夺问题。

(2). 除非必要否则不要使用keyset游标。和static游标一样,打开keyset游标会创建临时表。虽然这个表只包括基本表的一个关键字列(除非不存在唯一关键字),
但是当处理大结果集时还是会相当大的。

(3). 当处理单向的只读结果集时,使用fast_forward代替forward_only。使用fast_forward定义一个forward_only,则read_only游标具有一定的内部性能优化。
(4). 使用read_only关键字定义只读游标。这样可以防止意外的修改,并且让服务器了解游标移动时不会修改行。
(5). 小心事务处理中通过游标进行的大量行修改。根据事务隔离级别,这些行在事务完成或回滚前会保持锁定,这可能造成服务器上的资源争夺。
(6). 小心动态光标的修改,尤其是建在非唯一聚集索引键的表上的游标,因为他们会造成“Halloween”问题——对同一行或同一行的重复的错误的修改。
因为SQL Server在内部会把某行的关键字修改成一个已经存在的值,并强迫服务器追加下标,使它以后可以再结果集中移动。当从结果集的剩余项中存取时,
又会遇到那一行,然后程序会重复,结果造成死循环。
(7). 对于大结果集要考虑使用异步游标,尽可能地把控制权交给调用者。当返回相当大的结果集到可移动


原文地址:https://www.cnblogs.com/zhxhdean/p/2080012.html