在 MySQL 中使用视图的优势答案

【问题标题】：Advantage of using Views in MySQL在 MySQL 中使用视图的优势
【发布时间】：2011-01-04 12:40:06
【问题描述】：

我了解到视图可用于创建自定义“表视图”（可以这么说），聚合来自多个表的相关数据。

我的问题是：视图的优点是什么？具体来说，假设我有两个表：

event | eid, typeid, name
eventtype | typeid, max_team_members

现在我创建一个视图：

eventdetails | event.eid, event.name, eventtype.max_team_members 
             | where event.typeid=eventtype.typeid

现在，如果我想为某些 event 设置团队中允许的最大成员数，我可以：

每种方法的优点/缺点是什么？

另一个查询：如果表事件和事件类型中的数据得到更新，更新视图中的数据是否有任何开销（考虑到它缓存结果数据）？

【问题讨论】：

【解决方案1】：

视图不是单独存储的：当您查询视图时，该视图将替换为该视图的定义。因此，对表中数据的更改将立即通过视图显示出来。

除了前面指出的安全功能：

如果您要编写大量执行该联接的查询，它会排除该 SQL 代码。就像在多个地方使用的函数中做一些操作一样，它可以让你的代码更容易读/写/调试。

它还允许您在一个地方更改将来执行联接的方式。也许一对多关系可以变成多对多关系，在连接中引入一个额外的表。或者您可能决定将所有事件类型字段非规范化并包含在每个事件记录中，这样您就不必每次都加入（交易空间换取查询执行时间）。

您可以稍后进一步拆分表，将其更改为 3 路连接，并且不必重写使用该视图的其他查询。

您可以向表中添加新列并更改视图以忽略新列，这样在更改表定义时一些使用“select *”的旧查询不会中断。

【讨论】：

“视图不是单独存储的”——所以 mysql 不执行视图内容的缓存？
其他一些数据库引擎支持“物化视图”，其中从视图中选择的结果被缓存，但 MySQL 不支持。在此处查看对物化视图的评论：dev.mysql.com/doc/refman/5.5/en/create-view.html
MySQL 确实有查询缓存，所以如果您的查询完全相同（例如，“select * from myview;”），您很可能会得到缓存结果。
事实上，它们有时更慢。这样做的原因是，当您使用某些类型的视图时，中间表是在没有索引的情况下构建的，这会导致外部 SELECT 语句运行速度较慢。阅读TEMPTABLE algorithm

【解决方案2】：

您可以将用户限制在视图而不是基础表中，从而增强安全性。

【讨论】：