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