在 T-SQL 中,可以通过两种方式(据我所知)声明游标:
declare CursorName cursor for ...
declare @CursorName cursor
我正在运行一些测试,我注意到创建游标变量不会在sp_cursor_list
.
从性能、资源利用率等角度来看,使用第二种方法有什么优点/缺点吗?
PS:我知道潜在的光标性能问题。我不是要求比较游标与基于集合的比较。或光标while
与临时/表变量。
在 T-SQL 中,可以通过两种方式(据我所知)声明游标:
declare CursorName cursor for ...
declare @CursorName cursor
我正在运行一些测试,我注意到创建游标变量不会在sp_cursor_list
.
从性能、资源利用率等角度来看,使用第二种方法有什么优点/缺点吗?
PS:我知道潜在的光标性能问题。我不是要求比较游标与基于集合的比较。或光标while
与临时/表变量。
DECLARE @local_variable CURSOR
使用我刚刚发现的语法还有另一个好处。
当一个存储过程调用另一个存储过程并且两个过程同时打开游标时,优势就会出现。如果DECLARE cursor_name CURSOR
用于定义游标,并且两个过程使用相同的 cursor_name,那么您会得到
消息 16915:名称为“cursor_name”的游标已存在。
另一方面,IfDECLARE @local_variable CURSOR
用于定义父存储过程和子存储过程中的游标,then@local_variable
对于每个过程都是本地的,不存在冲突。对于那些以前没有使用过此方法的人,这里是一个示例,@C
用作局部变量:
DECLARE @C AS CURSOR;
SET @C = CURSOR FOR SELECT ...;
OPEN @C;
FETCH NEXT FROM @C INTO ...;
...
从我读到的游标变量的目的是能够将它用作存储过程中的输出变量,从而使您能够将游标中的数据发送到另一个控制过程。我没有尝试过,所以我不知道它是如何工作的,但这就是我从阅读在线图书中得到的。如果有任何可测量的性能差异,当然不是一开始不使用游标所能获得的改进,我会感到惊讶。如果您不打算将其用作输出变量,我建议使用更常见的游标定义可能会使代码更易于维护。
也就是说,实际上需要游标的情况非常非常少。
我会尽量避免使用诅咒(至少如果你考虑性能的话)。尝试为您的问题创建一个基于集合的解决方案。它们的处理速度通常比基于游标的解决方案要快得多。