数据库视图是否影响查询性能?

虽然在视图内运行的某个查询和在视图外运行的同一个查询的执行效率应该相等,但是当需要将两个视图连接在一起时,事情会变得更加复杂。您可以很容易地将不需要的表带到查询中,或者以冗余方式引入表。数据库的优化器可能在创建良好的查询执行计划时遇到更多困难。因此,尽管视图在允许更细粒度的安全性等方面非常好,但它们不一定适合模块化。

它依赖于RDBMS,但通常不会进行优化,这只是简化查询的一种方便方法。然而,有些数据库系统使用“物化视图”,它们确实使用缓存机制。

我一直认为视图就像一个只读存储过程。您可以预先给数据库提供尽可能多的信息,以便它可以尽可能预编译。

您还可以为视图编制索引,以便访问正在运行的查询类型所需数据的优化视图。

通常,视图只是一种创建常用速记的方法,用于定义您经常需要的结果集。

然而,也有一个缺点。诱惑是将您认为可能需要的每一列都添加到某个您可能希望使用视图的位置。所以雅格尼被侵犯了。不仅是列,而且有时附加的外部连接被附加在“以防万一”上。因此,覆盖索引可能不再覆盖,查询计划可能会增加复杂性(并降低效率)。

YAGNI是SQL设计中的一个关键概念。

一般来说,视图的执行应该与直接在底层表上编写的查询等效。

但是:可能会有一些边缘情况,因此有必要测试代码。所有现代RDBMS系统都有一些工具,可以让您查看queryplan并监视执行。别把我(或任何人)的话当回事,当你能在你的指尖上有确切的数据。

我知道这是一条老线索。讨论是好的,但我确实想再考虑一个问题。性能还取决于使用什么来提取数据。例如,如果您的前端是Microsoft Access之类的东西,那么您可以通过使用视图来获得一些复杂查询的性能。这是因为Access并不总是像我们所希望的那样从SQL server拉取数据——在某些情况下,它会拉取整个表,然后尝试从那里进行本地处理!如果你用视图的话就不会了。

是的,在所有现代RDBMS中(2005以后的MSSQL?etc)视图的查询计划被缓存,从而消除了规划查询的开销,并提高了与在同一行执行的SQL相比的性能。在此之前(它也适用于参数化的SQL/Prepared语句),人们正确地认为存储过程执行得更好。

今天很多人仍然坚持这一点,使其成为现代数据库的神话。自从Views/PS获得了SPs的缓存查询规划之后,它们就变得非常均匀。