我有一个View，其结构与在表中生成记录的查询完全相同。 但是，如果与Table相比，使用View执行下面的select语句的时间会更长。
从XYZ_VIEW中选择count（*） - 这是一个使用 4min4sec 返回记录的视图，count = 5896
从XYZ中选择计数（*） - 这是一个返回记录小于1秒的表，计数= 5896
答案 0 :(得分：0)
您不会在视图后面显示查询，但我认为它涉及一些联接以公开规范化数据和/或其他处理。以下是您在这方面处理意见的方式。
视图不应该（如 never ）成为未过滤查询的目标。实际上，这应该不鼓励对表，但有时在测试期间是必要的。幸运的是，这些查询在生产代码中几乎从不合理甚至是必要的。
由于您在测试期间并不真正关心性能，而是在生产过程中表现出色，因此您没有说出任何暗示您可能遇到问题的信息。没错，对于你展示的查询，四分钟一秒钟就没有意义了。我的许多观点（如果不是大多数）会产生类似的结果。
相反，请使用更有可能在生产中使用的查询。使用具有毫秒精度的计时方法，请使用以下格式的查询：
select ...
from table/view
where <typical filtering criteria>;
这将为您提供更多有用的信息。根据您的具体应用和要求，可接受的范围为10-20％。也就是说，如果表在30毫秒内返回结果，那么如果在小于大约36毫秒内返回相同的结果，则视图是好的。
您正在使用视图可能是因为它以某种方式操纵数据以某种方式更有利地呈现数据。此处理是您直接查询表时不会有的开销。省略过滤时，可能会对基础表的每一行执行该处理，可能是不必要的。当你做一些像select count(*)这样特别愚蠢的事情时，你会执行所有额外的处理而不会有任何好处。
过滤查询时，仅对合格结果集执行额外处理。如果结果集只有一行，则处理将仅在单行上执行，从视图中呈现性能（当然，取决于处理的确切数量和类型）几乎与表格无法区分。
我总是建议使用视图 - 很多很多视图 - 向用户呈现最适合各种用途的数据。通过各种方式测试这些观点。但要使用有意义的测试。