数据库视图会影响查询性能吗？

数据库视图是仅用于简化数据访问的一种方法，还是在访问视图时提供性能优势，而不是仅运行基于视图的查询？ 我怀疑视图在功能上等同于将存储的视图查询添加到视图数据的每个查询中，这是否正确，或者是否正在发生其他详细信息和/或优化？

尽管在视图内运行的某个查询和在视图外运行的同一查询应等效执行mssql 使用视图，但是当您需要将两个视图连接在一起时，事情会变得复杂得多。您可以轻松地将不需要的表带入查询中，或者将表冗余地带入。数据库的优化器在创建良好的查询执行计划时可能会遇到更多麻烦。因此，尽管在允许更多细粒度的安全性等方面，视图可能非常好，但它们不一定对模块化有利。

我一直认为视图就像只读的存储过程。您需要事先为数据库提供尽可能多的信息，以便可以对其进行最佳的预编译。

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

它取决于RDBMS，但通常不会进行优化，这只是简化查询的一种便捷方法。但是，某些数据库系统使用"物化视图"，但确实使用缓存机制。

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

但是，有一个缺点。诱惑是在您想使用该视图的某个时候，在您认为需要的每个列中添加一个。因此，YAGNI被违反。不仅是列，而且有时还会添加其他外部联接，以防万一。因此覆盖索引可能不再覆盖，查询计划可能会增加复杂性(并降低效率)。

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

我知道这是一个旧线程。讨论是好的，但我确实想再想一想。性能还取决于您用来提取数据的方式。例如，如果您使用Microsoft Access之类的产品进行前端开发，则可以使用视图来一定程度上提高某些复杂查询的性能。这是因为Access并不总是像我们想要的那样总是从SQL Server中拉出-在某些情况下，它将拉出整个表，然后尝试从那里进行本地处理！如果使用视图则不是这样。

一般而言，视图应等效于直接写在基础表上的查询。

但是：可能会有一些极端的情况，因此您应该测试代码。所有现代RDBMS系统都具有可让您查看查询计划并监视执行的工具。当您可以轻松获得确定的数据时，请不要相信我(或其他人)的话。

是的，在所有现代RDBMS(2005年之后的MSSQL等)视图中，都缓存了查询计划，从而消除了计划查询和通过内联执行的相同SQL加快性能的开销。在此之前(它也适用于参数化的SQL / Prepared Statements)，人们正确地认为存储过程的性能更好。

今天，许多人仍然坚持使用它，使其成为现代数据库的神话。自从Views / PS获得SP的缓存查询计划以来，他们甚至都差不多。

（编辑：应用网_镇江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!