MySQL：视图与存储过程

Question

由于MySQL开始支持存储过程，我从未真正使用它们。部分是因为我不是一个伟大的查询作家，部分是因为我经常与为我做出这些选择的DBA合作，部分原因是因为我对我所知道的内容很满意。

在进行数据选择方面，特别是在考虑一个基本上是非规范化（连接）和聚合（avg或max，子查询和计数等）数据选择的选择时，MySQL的正确选择是什么5.x的？一个看法？还是存储过程？

我很满意的视图 - 你知道你的SELECT查询应该是什么样的，所以你只需创建它，确保它被编入索引，然后只做一个CREATE VIEW [View] AS SELECT [...]。然后，在我的应用程序中，我将视图视为只读表 - 它表示我的规范化数据的非规范化版本。

这里有什么缺点 - 如果有的话？如果我将完全相同的SELECT语句移动到存储过程中会有什么变化（收益或损失）？

我希望找到一些在搜索这个主题时很难找到的“引擎盖”信息，但我真的欢迎所有的评论和答案。

Answer 1

在我看来，当需要在几个不同的应用程序中使用相同的例程或数据库或表之间的ETL时，存储过程应该仅用于数据操作，仅此而已。基本上，尽可能多地使用代码，直到您遇到DRY原则，或者您正在做的只是将数据从一个地方移动到另一个地方。

视图可用于为数据提供备用或简化的“视图”。因此，我会选择一个视图，因为你并没有真正操纵数据，就像找到一种不同的显示方法一样。

Answer 2

我使用视图进行反规范化或输出格式化和存储过程以进行过滤和数据操作（需要参数输入的东西）或迭代（游标）。

当需要进行反规范化和过滤时，我经常访问存储过程中的视图。

Answer 3

不确定这是否是/或选择。存储过程可以执行各种视图会遇到困难的事情（想想在临时表中填充数据然后在其上运行游标然后进行聚合并返回结果集）。

另一方面，

视图可以隐藏复杂的sql /访问权限并显示模式的修改视图。

我认为两者都在事物方案中占有一席之地，两者都对成功的模式实现很有用。

Answer 4

有一点需要注意，至少mysql视图结果存储在一个临时表中，与大多数不太合适的数据库引擎不同，这个表没有索引，所以如果用来简化查询，那么当你的程序要抓取时，查看很棒视图中的所有结果，但是如果你那时搜索该视图的结果，基于参数它是非常慢的，特别是如果有数百万条记录需要筛选，更糟糕的是如果视图建立在其他视图之上并且等等。

存储过程但是您可以传递这些搜索参数并直接针对下划线（索引）表运行查询。缺点是每次运行程序时都需要获取结果，这也可能会在视图中发生，这取决于服务器配置。

所以基本上如果您使用视图尝试最小化结果数（如果您需要搜索它），否则使用存储过程。