有人告诉我使用存储过程可能对数据库性能不利，最好将查询放在代码中并调用数据库。
对我来说最好有一个存储过程，因为如果我必须在数据库中进行更改，我不必重新编译整个 Web 应用程序来更改 SELECT 语句......
你怎么看？
【问题讨论】：
标签： asp.net mysql stored-procedures
告诉你这件事的人有理由支持他们的说法吗？如果他们无法解释，那么很可能他们实际上并不知道自己在说什么，他们可能只是在重复他们在某处听到或误听的内容。
一般认为存储过程性能更好，但并非出于您建议的原因。数据库引擎在内部解析发送给它们的查询以制定执行计划。 （把它想象成编译查询代码。）使用存储过程，数据库会保存这个执行计划，因此以后不必编译它。所以在使用存储过程时会跳过这一步。
同样的事情也可以应用于参数化查询等。现代数据库引擎非常擅长优化事物。这就是为什么我在上面说“一般”。关于代码-数据库交互的优化有很多细节。但在大多数情况下，这种说法是正确的。
至于重新编译您的应用程序，这完全是另一回事。如果您更改存储过程返回的数据的形状，那么您是否不必更新应用程序？如果应用程序不需要知道表格的形状，那么更改表格的形状不应影响应用程序。 （除非您使用 SELECT *，这主要是因为这个原因不是好的做法。）另一方面，如果您正在谈论使用存储过程作为一种数据库 API 供应用程序使用，它隐藏了实际表模式，那么这当然可以工作。只要应用程序不绑定到特定的架构实现，我就会认为这是一个很好的设计决策。在这种情况下，我猜存储过程将充当数据访问层本身的一部分。
【讨论】：
这场辩论已经持续了很长时间。
一般来说，存储过程和嵌入式 SQL 之间的性能差异几乎不再是问题 - 正如 David 所说，数据库引擎非常擅长优化查询。然而，在存储过程中，众所周知，缺乏经验的开发人员会编写性能不佳的代码——经典的反模式是程序性的，而不是基于集合的思维——逐条循环遍历表记录并更新该记录，而不是使用更新语句where 子句。
另一方面，“可管理性”仍然很重要。然后这一切都取决于您已经拥有的人员和流程。
如果您的开发人员不熟悉存储过程，我会避免使用它们 - 您最终可能会得到没人愿意接触的不可维护的过程。
如果您的客户端代码与数据库代码紧密耦合（几乎总是如此），您需要有一个发布过程以使它们保持同步 - 并且架构对象（包括存储过程）的源代码控制是并不总是直截了当。
您最终可能会得到大量不增加价值的存储过程 - 简单的 CRUD 操作。您可能会创建大量代码（需要对其进行版本控制、部署和维护），而不会增加任何额外的价值。
从哲学上讲，大多数当前的软件架构都以某种方式基于面向对象 - 存储过程将过程代码注入到该范例中（尽管您可以通过创建数据库 API 来解决这个问题，正如 David 所建议的 - 数据即服务）。
因此，除非您的应用程序主要关注数据库，否则我通常建议不要使用存储过程——它们不会为可维护性付出代价。例外是批处理例程——归档、数据清理等——它们通常更容易作为存储过程进行管理，但几乎没有外部依赖项。
【讨论】：