tsql - 什么时候 TSQL 游标是最好的或唯一的选择？

Question

我最近有一个关于在 TSQL 中使用游标的争论......

首先，我不是辩论中的啦啦队长。但是每次有人说 cursor 时，总会有一些笨蛋(或 50 个)用强制性的“光标是邪恶的”咒语来猛扑。我知道 SQL-Server 已针对基于集合的操作进行了优化，也许游标确实是邪恶的化身，但如果我想在其背后放一些客观的想法......

这是我的想法:

1) 游标和集合操作之间的唯一区别是 性能 之一吗？

编辑 :有一个很好的例子，因为它不仅仅是一个性能问题——例如反复运行单个批处理来获取 id 列表，或者执行存储在表字段中的实际 SQL 文本逐行。

2) 跟进:游标 总是 表现更差吗？

编辑 :@Martin 展示了一个很好的案例，其中游标的性能相当显着地优于基于集合的操作。我怀疑这不会是你经常做的事情(在你诉诸某种 OLAP/数据仓库类型的解决方案之前)，但尽管如此，这似乎是一个你真的不能没有的情况一个游标。
- reference to TPC benchmarks 暗示游标可能比人们普遍认为的更具竞争力。
- reference to memory-usage optimizations 自 Sql-Server 2005 起用于游标

3) 有没有你能想到的问题，游标比基于集合的操作更适合解决？

编辑 :基于集合的操作实际上不能 Execute 存储过程等(请参阅上面第 1 项的编辑)。
编辑 :在聚合大型数据集时，基于集合的操作比逐行慢。

Article from MSDN 解释他们的观点
人们求助于游标的最常见问题(以及一些
更好地工作的基于集合的技术的解释。)

微软在 2008 Transact SQL Reference on MSDN 中(含糊地)说:“......有时结果最好一次处理一行”，但没有给出任何关于他们所指的情况的例子。

大多数情况下，如果/当我对各种应用程序进行任何重大升级时，我都会在我的旧代码中将游标转换为基于集合的操作，只要可以从中获得一些东西。 (很多时候我倾向于懒惰而不是纯粹——也就是说，如果它没有坏，就不要修理它。)

Answer 1

直接回答您的问题:

我还没有遇到过这样的情况，即设置操作无法完成其他情况下可以用游标完成的操作。但是，在某些情况下，使用游标将大型集合问题分解为更易于管理的块证明是出于代码可维护性、日志记录、事务控制等目的的更好解决方案。但我怀疑是否有任何硬性规定可以告诉您哪种类型的需求会导致一种解决方案或另一种解决方案——单个数据库和需求简直太多样化了。

也就是说，我完全同意你的“如果它没有坏，就不要修理它”的方法。通过重构过程代码来为运行良好的过程设置操作，几乎没有什么好处。但是，首先寻求基于集合的解决方案是一个很好的经验法则，只有在必须时才使用过程代码。直觉？如果您使用游标的时间超过 20%，那么您就做错了。

而我真正想说的是:

当我面试程序员时，我总是向他们抛出一些中等复杂的 SQL 问题，并要求他们解释他们将如何解决这些问题。我知道这些问题可以通过集合操作来解决，我特别在寻找能够在没有过程方法(即游标)的情况下解决这些问题的候选人。

这并不是因为我相信任何一种方法都有本质上好的或更高的性能——不同的情况会产生不同的结果。而是因为，根据我的经验，程序员要么获得基于集合的操作的概念，要么没有。如果他们不这样做，他们将花费太多时间为可以通过基于集合的操作更快更简单地解决的问题开发复杂的程序解决方案。

相反，获得基于集合的操作的程序员几乎不会在实现过程式解决方案时遇到问题，而这确实是绝对必要的。