在SO / Google上阅读其他类似问题后，我获得数据库视图（虚拟/简单表视图而不是物化视图）主要用于方便和安全，而不是用于提高速度。有些人认为观点是可重复使用的，并且位于中心位置，但也可以在代码中保存在中心位置
根据我的理解来自Web服务器时，视图应该比查询稍微好一点。原因是当通过Web服务器中的代码执行查询时，查询文本需要在网络上传播，而视图中不是这种情况。我相信查询（预备语句）和视图都是预编译的？ 。在这个意义上也是如此。 我的理解是否正确？
此resource反对
性能 - 看起来像对视图的简单查询可能 对于数据库引擎来说，这是一项非常复杂的工作。那是 因为每次引用一个视图时，用于定义它的查询， 重新运行。
但对于查询也是如此。不是吗？
此问题适用于未实现/索引视图的简单视图
答案 0 :(得分：2)
（在这里谈到甲骨文，因为这是我的知识领域）
视图不是“预编译”的。它们只是存储文本，因此在概念上，当您运行
时select * from my_view
它在逻辑上等同于
select * from ( [query that defines view] )
关于
“原因是当通过Web服务器中的代码执行查询时，查询文本需要在网络上传播，而视图中不是这种情况”
这是事实，但很少有网络服务器和数据库被这样一个糟糕的网络分开，以至于针对视图的100字节查询与针对基表的500字节的查询将是显而易见的。
最后，关于性能，它取决于视图。在查询中引用视图时，有两种机制可能发挥作用。
一个是“视图合并”，我们可以将视图的文本集成到查询中，就像视图从未存在一样，例如
view: select * from t
query: select * from my_view where x=1
可以合并到：
select * from t where x=1
因此视图的文本永远不会被实际执行。
但另一种选择是“视图分辨率”，其中视图足够复杂或包含禁止合并的定义。例如，包含窗口函数的视图：
view: select t.*, row_number() over ( order by blah ) from t
query: select * from my_view where x=1
无法合并到：
select t.*, row_number() over ( order by blah ) from t
where x=1
因为窗口函数不再返回相同的结果。 （一个返回整个表中的排名，另一个返回仅x = 1的行的排名。）
因此，在视图分辨率的情况下，您可以看到性能影响，但仅仅因为我们需要保证结果的正确性，而不是通常限制视图。