MSSQL游标的原理及示例 游标使用不再需要之后，要释放游标。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). 对于大结果集要考虑使用异步游标，尽可能地把控制权交给调用者。当返回相当大的结果集到可移动
2024最新激活全家桶教程，稳定运行到2099年，请移步至置顶文章：https://sigusoft.com/99576.html
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。 文章由激活谷谷主-小谷整理,转载请注明出处：https://sigusoft.com/64859.html
