sql-server – 哪个在SQL中更快,While循环,递归存储proc或Cursor?

前端之家收集整理的这篇文章主要介绍了sql-server – 哪个在SQL中更快,While循环,递归存储proc或Cursor?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
哪个在sql中更快,While循环,递归存储proc或Cursor?
我想在存储过程中优化几个点的性能.
我正在优化的代码将一些字符串格式化输出到一个文件.

解决方法

我会假设你正在使用sql Server.

首先,正如有人在声明中所说,递归存储过程虽然可能,但由于堆栈大小,在sql Server中不是一个好主意.所以,任何深刻递归的逻辑都会破裂.
但是,如果最多有2-3级嵌套,则可以尝试使用递归或使用CTE,这也是一个递归(sql Server 2005及更高版本).一旦你设法围绕CTE包围,这是一个非常有用的技术.
我没有测量,但是我在使用CTE的地方从来没有出现过性能问题.

另一方面,游标是大型性能猪,所以我(and half the internet)建议不要在经常调用代码中使用它们.但是,由于游标更为经典的编程结构,类似于C#中的foreach,有些人发现使用游标进行数据操作的sql代码,通过一些复杂的多内部选择sql怪异,可以更容易地查看,理解和维护.在一段时间内被调用代码中使用它们并不是最糟糕的主意.

说到这一点,它也将编程思维从一个基于设置的一个转移到一个基于过程的思想,所以当它相对较快并且不消耗大量资源时,仍然可以大大增加你发布的数据操作语句的数量数据库本身.

总而言之,如果我必须使一个复杂的存储过程,其性能至关重要,我会尝试:

>使用基于集合的方法(内部选择,连接,联合等)
>使用CTE(清晰可管理的经验丰富的用户,对于初学者来说有点阴影)
>使用control-flow语句(如果while …)
>使用光标(程序代码,易于遵循)

以该顺序.

如果代码的使用少得多,我可能会在1和2之前移动3和4,但是再次,仅适用于使用大量表的复杂场景,以及很多关系.当然,YMMV,所以我会测试我在现实世界中所做的任何程序,以实际测量性能,因为我们可以谈论,直到我们是蓝色的面对这是快速,这是慢的,但直到你得到真正的测量,就像一个天主教修道院的性别约会*

而且,别忘了,代码与数据一样快.没有替代良好的索引.

>几年前,这种比喻很有趣,现在有点难过.

猜你在找的MsSQL相关文章