自从 MySQL 开始支持存储过程以来，我从未真正使用过它们。部分原因是我不是一个出色的查询编写者，部分原因是我经常与为我做出这些选择的 DBA 一起工作，部分原因是我只是对我所知道的感到满意。
在进行数据选择方面，特别是在考虑本质上是数据的非规范化（连接）和聚合（平均或最大值，子查询/计数等）选择时，MySQL 5.x 中的正确选择是什么? 一个看法？还是存储过程？
我很满意的视图 - 你知道你的 SELECT 查询应该是什么样子，所以你只需创建它，确保它被索引等等，然后只需执行CREATE VIEW [View] AS SELECT [...]. 然后，在我的应用程序中，我将视图视为只读表 - 它表示我的规范化数据的非规范化版本。
这里有什么缺点 - 如果有的话？如果我将完全相同的 SELECT 语句移动到存储过程中会发生什么变化（收益或损失）？
我希望找到一些在谷歌搜索该主题时很难找到的“幕后”信息，但我真的欢迎所有评论和答案。
在我看来，当需要在多个不同的应用程序之间使用相同的例程或用于数据库或表之间的 ETL 时，存储过程应该仅用于数据操作，仅此而已。基本上，在您遇到 DRY 原则或您所做的只是将数据从数据库中的一个地方移动到另一个地方之前，尽可能多地使用代码。
视图可用于为数据提供替代或简化的“视图”。因此，我会选择一种观点，因为您并没有真正操纵数据，而是找到了一种不同的显示方法。
不确定这是否是非此即彼的选择。存储过程可以做很多视图难以完成的事情（想想在临时表中填充数据，然后在其上运行游标，然后进行聚合并返回结果集）。
另一方面，视图可以隐藏复杂的 sql / 访问权限并呈现模式的修改视图。
我认为两者都在事物方案中占有一席之地，并且对于成功的模式实现都很有用。
我使用视图进行反规范化或输出格式化，并使用存储过程进行过滤和数据操作（需要参数输入的事物）或迭代（光标）。
当需要反规范化和过滤时，我经常访问存储过程中的视图。
需要注意的一点是，至少 mysql 视图结果存储在一个临时表中，并且与大多数体面的数据库引擎不同，该表没有索引，因此如果仅用于简化查询，当您的程序要获取所有数据时，视图非常好结果来自视图，但是，如果您随后根据参数搜索该视图的结果，则速度非常慢，尤其是在要筛选数百万条记录的情况下，如果视图建立在其他视图之上，则更糟，依此类推。
一个存储过程，但是您可以将这些搜索参数传入并直接针对下划线（索引）表运行查询。缺点是每次运行过程时都需要获取结果，这也可能发生在视图中，具体取决于服务器配置。
所以基本上如果您使用视图尝试最小化结果数量（如果您需要搜索它），则使用存储过程。