关于“模糊”游标事实的问题

Question

我知道基于集合的解决方案是理想的，通常优于游标。所以，请。通过弃用答案“不使用游标，使用基于集合的操作”来节省您的时间和节省时间。我问这个是因为我的谷歌搜索没有给出任何答案，知识可能来自经验：

1） FETCH NEXT FROM vs FETCH FROM 当我打开游标（fast_forward / static）时，在while循环中使用'fetch next from'和'fetch next'之间是否有区别？在表现，访问记录的顺序等。

2） ROW_NUMBER + SELECT / WHILE vs STATIC CURSOR 据我所知，静态游标会创建一个临时表，其中包含所选数据并遍历此临时表。那么，有没有理由使用select row_number() ..., ... from ... into ...并使用索引变量和select * from #tmp table where RowNumber = @IndexVar进行迭代？

3） FAST_FORWARD - 它可以分解吗？如果我有一个fast_forward本地游标，并且在游标内部对光标选择的表执行插入/更新操作，是否有任何问题？ （可能的周期等？）

4）计划强制有没有办法强制fast_forward游标使用静态/动态计划？

非常感谢您的回答

PS：对于你真正好奇的人，是的，问题可以改写成基于集合的方法，但是由于上级的一些决定，必须使用主表创建/插入新的行。存储过程。

Answer 1

1. NEXT是默认的抓取选项，因此FETCH = FETCH NEXT
2. 静态/动态是指是否反映了游标结果集所做的更改，即如果将新值插入到静态游标结果集中，它将不会循环遍历那些，这是当声明游标时的结果/打开，就是这样，我相信你的理解是正确的。
3. 我不确定。
4. 我不确定你的意思，你可以在声明光标时指示动态或静态。

Answer 2

  

在while循环中使用'fetch next'和'fetch next'之间有区别

否 - 如果未指定选项，则NEXT是默认值

  

那么，有没有理由使用select row_number() ..., ... from ... into ...并使用索引变量和select * from #tmp table where RowNumber = @IndexVar进行迭代？

我认为静态游标的优化效果会比你在每次迭代中创建临时表和搜索特定行时执行得更快，但我必须尝试一下。

  

如果我有一个fast_forward本地游标，并且在游标内部对光标选择的表执行插入/更新操作，是否有任何问题？ （可能的周期等？）

我不确定“循环”是什么意思 - 如果基础数据发生变化，光标也会改变（除非你将其声明为STATIC）

  

有没有办法强制fast_forward游标使用静态/动态计划？

我从未尝试过，但您可以在定义光标时尝试在OPTION( USE PLAN ...)中使用SELECT。我想不出它为什么不起作用的原因。

  

我对此感到生气，谷歌无能为力

Google只会报道人们在互联网上发布的内容......你为什么生气？你想解决什么问题？