我听说使用游标不好，因为它们对 DBMS 来说“不自然”，而且它们的性能很差。
但是想象一下以下情况：我有一个存储过程，我需要为来自法国的每个客户调用这个存储过程（例如）。我有几个选项，例如使用游标，在一个查询中编写所有内容，并从客户端应用程序为每个客户调用存储过程。
如果我在一个查询中编写所有内容 - 它很可能会从已经存在的存储过程中复制代码/逻辑/整个查询。对我来说，这看起来像是一种“臭名昭著的方法”（如果您阅读了“重构”一书）。逻辑不再封装在一个地方。
你怎么看？
PS。欢迎提供任何描述游标为何不好或不坏的文档的链接。
还要记住，游标性能会因 RDBMS 而异。
但是，我认为可以证明游标对于 SQL 数据库是不自然的（并且有一些关于该主题的专家会对此提出异议）。如果你考虑一下，游标可以被认为是一个迭代器（如果你真的很讨厌，甚至是一个指针）。虽然迭代器在过程语言中工作得很好，但它们不适合像 SQL 这样的声明性语言。
现在，我还没有真正使用足够多的光标来同意或不同意这种思路。但是我会说，当我想到它时，我真的想不出我写过的任何使用游标简化的查询（并不是说它们不存在）。
有时光标是正确的工具。在其他时候，最好检索整个查询，并将其作为一个集合进行操作。
SQL 内置了许多面向集合的操作。例如，UPDATE 可以对表中的一整组行进行操作。如果有 WHERE 子句，则这些行将被更新。更新可以使用上下文敏感的子查询和 CASE 构造来提供很大的灵活性，以便以看似不同的方式更新不同的行。
将一个巨大的数据转换表达为一个单一的 UPDATE 对于一个刚刚开始学习 SQL 的程序员来说似乎是一项艰巨的任务。声明游标、遍历返回的行、将每一行视为一条记录并在处理时恢复为一条记录要容易得多。只要您对数据库的参与保持“精简”，这对您来说可能就足够了。
但是，如果您希望构建工业级数据库，那么您应该学习如何根据行集来操作数据，而不仅仅是一次一行。你会得到更好的表现。也许更重要的是，您将更清楚地了解底层业务规则和您编写的代码之间的关系。
在设计良好的数据库中操作数据集比在设计不佳的数据库中操作要容易得多。如果您刚开始加快数据库设计的速度，同时又开始加快 SQL 查询的速度，那么您可能需要一位导师来为您的数据库设计提供建议。如果您不这样做，您可能很难学习面向集合的操作的强大功能和简单性。
而且，有时您仍会使用游标。
如果您致力于在数据库上以存储过程的形式拥有业务逻辑，那么游标就不错了。
假设您有一个非常标准的客户端-服务器-数据库架构，将逻辑移出数据库并移入应用服务器可能是一个更好的主意。这有几个好处：
根据您的存储过程的编写方式，如果您使用的是 SQL Server，则可以将其转换为函数。使用函数，您可以单独执行以下操作：
SELECT uf_MyFunction(customer_id, customer_name, customer_address) FROM Customer
将其应用于每一个客户记录
游标不一定是坏事，只是在大多数情况下，当你的直觉告诉你使用它们时，有一种更高效的方式来使用声明性或基于集合的方法来做同样的事情。如果您发布 proc 的详细信息，我敢打赌，您会得到一些很好的建议，说明如何使用单个存储的 proc 调用和无游标来执行您需要的操作。