mysql 视图与存储过程答案

【问题标题】：mysql Views vs Stored Proceduremysql 视图与存储过程
【发布时间】：2014-09-23 01:49:17
【问题描述】：

我目前正在为我正在开发的应用程序设计我的 mysql 数据库。

我喜欢Stored Procedures 简短易读，并且由于我的数据库涉及一些join 语句，我想也许我应该用所有joins 创建Views 并从我的@ 查询这些Views 987654327@.

起初听起来不错，但当我想到性能时，我意识到每当调用 Stored Procedure 时，它都会运行至少 2 个查询：

View 查询
Stored Procedure 查询 View

在Stored Procedure 中使用join 语句时，我将仅在查询中执行连接和从连接中选择。

我说的对吗？

如果是这样 - 就优雅的代码编写而言，保持良好的开发性能的良好做法是什么？

【问题讨论】：

认为有many good reasons not to use stored procedures。
我已阅读您的回答。老实说——其中大部分与我的情况无关——主要是因为我擅长 sql。性能问题 - 我会测试它

标签： mysql stored-procedures join database-design

【解决方案1】：

“出色的开发性能”和“优雅的代码”是两个天壤之别。您不应该将它们配对得如此紧密。

你说得对，事先创建视图会增加一层低效率。如果您更担心性能，那么我会将您的连接查询直接放在您的存储过程中。从视图查询将强制视图重新填充，这是您不需要的另一个查询。

话虽如此，一个额外的查询可能不会影响您的数据库性能。

如果您真的担心代码的整洁性，我建议您考虑一下您在连接语句中实际使用的数据，看看您是否可以缩短或分解它们。例如，您是否使用多列或多行数据？还是您只是查询单个值？如果是后者，请考虑创建一个返回此值的函数。这也将有助于将您的代码从存储过程中分离出来。

【讨论】：

【解决方案2】：

DBMS 通常不会在您描述的情况下执行单独的查询。它以文本方式扩展查询中使用的视图名称的外观，并评估整个生成的新表达式。它不会评估视图的单独查询。使用存储过程对视图提供的操作以外的操作进行分组和/或参数化（即仅通过基数/视图进行参数化，仅通过一个选择进行）。

话虽如此，与通过扩展视图定义和重新排列获得的查询相比，您可能无法充分优化包含视图名称的查询。但无论查询是否在存储过程中都是如此。

见MySQL documentation。（请注意用户评论说某些视图子句仅在它们位于最外层的选择表达式中时才阻止内联/合并。）或this dba.stackexchange.com google 'mysql view optimization' hit。

【讨论】：

所以，如果我理解正确的话——使用存储过程创建一个通用视图和分组/“选择位置”——效率不会低于嵌入组/“选择位置”的选择查询在查询中？
我不确定你在说什么。例如，您是指在存储过程中调用的视图（如您的问题）还是在查询/视图中调用的存储过程。存储过程调用将具有its own costs and benefits。但是在另一个查询中（在存储过程中或不在存储过程中）使用视图作为表名不一定涉及单独的查询或临时表。我添加了指向我的答案的链接。
我的意思是，创建一个包含表连接在内的所有数据的视图，然后使用 SP 查询这些数据，无疑更加优雅，但它的填充就像 DBMS 流程一样：创建一个使用连接查看数据库中的所有数据 -> 查询此数据。在同一个存储过程中使用它就像：使用连接选择数据库中的所有数据 - 但连接和选择只会发生在相关数据上..
对不起，我听不懂你的意思。请编辑您的问题：举个例子。使用更多的单词和更多的句子。不要提及你的感受；它没有帮助，并且会导致写作不清晰。另外，我不明白您为什么在 cmets 中提到“通用视图”和“数据库中所有数据的视图”，而在问题中提到“视图”。另外，我不知道您是否理解 DBMS 有时可以内联/合并视图的定义，其中视图的名称出现在查询中。
对不起，我会尝试重写它。正如我所看到的，有两个选项：第一个是创建一个包含来自某些表的连接的视图。我也使用 SP 来查询这个视图。这对于编写 SP 的 DBA 来说显然要优雅得多，因为这些 SP 会更干净。但它看起来像 2 个查询。第二种选择是跳过视图部分，只写一个带有连接句子的SP。这会导致 SP 代码不那么优雅，但可能更有效。我更喜欢第一个选项，但我不确定它是否适合选择性能。