Question

我的问题是我有一个视图，该视图在某天返回20.000行数据

select * from view
where date = X

但是然后当我为周边添加一个where子句

select * from view 
where date = X and perimeter in ( 'A' , 'B' , 'C', 'D' )

结果大约是10.000行，但最多需要30分钟才能得到结果。

视图非常复杂，包含数十个连接和聚合等

我该如何解决？

感谢您的帮助，而且我有任何问题，问我：）

**更新：感谢您的回答。真正的查询非常复杂。这只是一个解释我的问题的例子。执行计划非常长且无用，因为我有完全相同的（100％）相同的执行计划（估计的和实际的）我是否在周长列上使用过滤器。但是后面的时间从我只过滤日期的30秒变为我添加perimter过滤器的30分钟。因此，这必须意味着执行计划仍然是错误的。统计信息通常会在该表上更新。在我要查找的表的此列上没有索引。为视图添加一个必需项吗？由于视图中的左连接，因此检索了我们过滤的列 **

Answer 1

首先问自己：

这样的时间正常吗？

在某些情况下，当数据量大且语句复杂时，某些查询要花更多时间是正常的。

如果这不是您的情况，那么：

我需要所有列吗？ -为什么SELECT *仅选择所需的列有时可以优化视图执行
我需要视图中使用的所有逻辑吗？ -如果视图是如此复杂，请考虑是否有可能仅获得所需的语句（例如，使用更少的逻辑，更少的数据源，更少的列创建单独的视图）
查询使用的索引最佳吗？这是huge topic，但是您执行的是filtering，因此可以使用适当的索引甚至filtered index?来优化查询
我可以预先过滤数据吗？ -有时您可以创建inline table-valued function以便预先执行过滤（该函数基本上是带有参数的视图-想象将参数'X'传递给此函数，该参数将传递给该视图中引用的其他函数，现在返回以前生成的行中只有5％-因此，可能是WHERE子句中的某些值可以作为参数传递）；
我需要实现这个观点吗？ -这是不得已的方法，但是您可以create index on the view使其像普通表一样物化并优化性能，进一步（请注意，并非每个视图都可以索引）

据我所见，许多开发人员都在使用遗留视图，这些视图是为解决过去的特定问题而创建的，而不是创建新的视图。而且很多时候，这些视图所要做的远远超出实际需要。

筛选2万行的视图需要30分钟

1 个答案: