-1

大家好，提前感谢。我的观点是，在没有 where 子句的情况下进行查询时，只需要 0 秒多的时间就可以返回约 8600 行。但是，当我使用 where 子句进行查询时，例如：

SELECT * FROM myView WHERE myID = 123

根据我代替 123 的常量，查询执行时间会发生很大变化。

现在，在这种情况下，“相当大”是指略高于 0 秒和 3 到 4 秒之间的差异。但是对于某些任务，视图被频繁且重复地调用，这使得 3 秒变成了 30 秒或更多秒。

虽然我无法提供视图本身的代码，但我可以确认的是：

  1. 该视图由 6 个标准表（无特殊特性）的连接组成。

  2. 虽然表 A 中可能并不总是有与表 B 链接的记录，从而在结果中创建空列，但我已经确认此类实例不会始终导致查询时间更长或更短。

  3. 视图本身没有超出标准Select、、From和子句的Left Outer Join子句。

  4. 某些 ID 总是导致查询时间长，而其他 ID 总是导致查询时间短

  5. 我已经在查询之间删除并创建了视图，以防有一个次优的缓存执行计划。

如果这些已知变量不足以将可能性降低到 2 或 3 个可能的原因，我仍然想知道什么理论问题可能导致这个问题，只是为了扩大我的理解。

再次感谢，

原型菜鸟

4

1 回答 1

0

我会假设表格的统计信息已经过时并且与表格的实际内容不匹配。这意味着优化器依赖于统计数据，例如假设您在 WHERE 子句中使用的值根本不会出现在数据中，因此结果集相当小，而实际上它包含许多行。或者反过来：依靠统计数据，优化器可以假设 - 比如说 - 表的 20% 的行具有这个值，因此最好进行全表扫描而不是首先访问索引页进行评估where 条件，然后跳转到几乎每个索引条目的数据页以读取数据，最后无论如何都必须读取几乎所有页。或者它会以错误的顺序访问表，或者......但实际上，该值根本不包含在表中，

指向过时统计数据的一个提示是，如果查询计划显示估计的行数和实际行数之间存在巨大差异。

您使用的是哪个 DBMS？如果是 SQL Server，那么您可以使用该语句查看当前使用 DBCC SHOW_STATISTICS的统计信息并刷新所选列和表的统计信息。UPDATE STATISTICS关于这个主题还有更多的观点和程序，其中大部分是从这两篇文章中的一篇链接而来的。

于 2013-07-31T17:11:03.583 回答