2012-06-16 61 views
3

假设我有一个并不真正“很好”的SQL查询。性能:查看或查询

SQL查询有很长的条件内部连接,最后是一个简单的“where”语句。

现在假设我创建了一个与该SQL查询相对应的视图,除了最后的“where”语句。因此,我不使用这个长查询,而是使用视图并简单地添加“where”语句。

我的问题是以下几点: 哪一个会有最好的表现?

我不确定“查看”选项是否符合两个sql语句,而不是第一个选项的一个sql语句。或者在执行查询之前,“查看”查询在更简单的查询中被“粘贴”并且是“相同的”。

+0

为什么downvote?这似乎是个好问题。 –

+0

我没有降低你的... ...意见有许多优点...但“表现”(至少在这种情况下)当然不是其中之一;) – paulsm4

回答

1

没有区别。该视图仅使用与查询相同的查询。

为了不同,它需要将其存储在视图表视图中,它们只是从外部看起来很容易的查询。

1

假设您正在使用的DBMS具有基于成本的查询优化器,那么当部分查询转换为视图时,您可能无法获得更好的性能。您可以通过比较两个版本的查询的估计成本来确认这与您的数据库的查询说明工具。

我推荐使用查询解释实用程序来确定查询的确切位置,因为查询的痛点通常是意料之外的位置。看起来,所有这些连接都会减慢速度,但它们可能会利用索引来最大限度地减少连接行所需的I/O和CPU周期。很多时候,由于在WHERE或ON子句中引用了无索引的列,所以查询陷入了沉寂。

+0

也许我解释了它错了,但我期待那使用视图会给我更糟糕的表现,因为我猜想这意味着两个查询,第一个得到视图表,第二个使用该表过滤“where”。感谢您的回复 – pritzo

+0

引用视图的语句仍将作为优化程序的一条语句处理。在内部,优化器只是抓取视图的SQL并将其放到引用视图的查询中。引用视图不太可能会影响优化器解析查询所需的时间,解决表引用并提出它认为是采用表的索引,基数和数据的最佳访问计划分配到帐户。 –

+0

优化程序的类型与视图的执行效果是否优于即席查询没有关系。 – Andomar