数据库视图只是一种简化数据访问的方法,还是在访问视图时提供性能优势,而不是仅仅运行视图所基于的查询?我怀疑视图在功能上等同于将存储的视图查询添加到视图数据的每个查询中,这是正确的还是发生了其他细节和/或优化?
7 回答
尽管在视图内运行的特定查询和在视图外运行的相同查询应该执行相同的操作,但是当您需要将两个视图连接在一起时,事情会变得更加复杂。您可以轻松地将不需要的表带入查询中,或者冗余地引入表。数据库的优化器在创建良好的查询执行计划时可能会遇到更多麻烦。因此,虽然视图在允许更细粒度的安全性等方面可能非常好,但它们不一定有利于模块化。
我一直认为视图就像一个只读的存储过程。您可以提前为数据库提供尽可能多的信息,以便它可以尽可能地进行预编译。
您还可以索引视图,从而允许您访问针对您正在运行的查询类型所追求的数据的优化视图。
它取决于 RDBMS,但通常不会进行优化,这只是简化查询的一种便捷方式。然而,一些数据库系统使用“物化视图”,它们确实使用了缓存机制。
通常,视图只是为定义您经常需要的结果集创建通用速记的一种方式。
但是,有一个缺点。诱惑是添加您认为可能需要的每一列,有时您可能希望使用该视图。所以 YAGNI 被违反了。不仅是列,有时还会在“以防万一”上添加额外的外部连接。因此覆盖索引可能不再覆盖,并且查询计划可能会增加复杂性(并降低效率)。
YAGNI 是 SQL 设计中的一个关键概念。
一般来说,视图应该与直接在基础表上编写的查询等效。
但是:可能存在边缘情况,您应该测试您的代码。所有现代 RDBMS 系统都有可以让您查看查询计划和监控执行的工具。不要相信我(或任何其他人)的话,因为您可以随时获得明确的数据。
我知道这是一个旧线程。讨论很好,但我确实想再考虑一下。性能还取决于您使用什么来提取数据。例如,如果您使用 Microsoft Access 之类的东西进行前端处理,那么您肯定可以通过使用视图来获得一些复杂查询的性能。这是因为 Access 并不总是像我们希望的那样从 SQL 服务器中拉取——在某些情况下,它会拉取整个表,然后尝试从那里进行本地处理!如果您使用视图,则不是这样。
是的,在所有现代 RDBMS(2005 年之后的 MSSQL?等)中,视图的查询计划都被缓存,从而消除了规划查询的开销并提高了在线执行相同 SQL 的性能。在此之前(它也适用于参数化 SQL/Prepared 语句)人们正确地认为存储过程执行得更好。
许多人今天仍然坚持这一点,使其成为现代 DB 神话。自从 Views/PS 获得了 SP 的缓存查询计划以来,它们几乎是平衡的。