什么时候应该创建一个视图的多个显示而不是多个视图？

创建视图的多个显示而不是多个视图只是为了方便起见，还是有性能优势？

某些显示器中是否包含以下任何一项，而其他显示器中没有，则会整体上影响视图吗？

• 上下文过滤器
• 内容类型过滤器
• 聚合

例如，我很好奇是否有一个显示器仅显示Article内容类型结果，另一个是否显示Forum结果，另一个显示自定义Photo内容类型会使每个显示器的运行速度变慢。或者，如果所有视图都共享相同的内容类型，但是不同之处仅在于视图具有针对nid的上下文过滤器，而其他视图则没有，它们都变慢了吗？

如果单个视图有30个Displays，我应该将其重构以提高性能，或者仅仅是因为UI并不打算显示那么多Displays。

在代码方面，视图和显示都由对象表示。处理View时，无论您在要查看的页面中仅呈现一个View，它都会将其所有子显示都加载到内存中。虽然仅针对活动显示执行数据库查询，但非活动显示的属性仍会加载到内存中。

这意味着，如果您在一个视图中有50个显示器，则无论您仅只显示其中一个显示器，都会将50个显示器加载到内存中。因此，您的问题的答案是肯定的，通常情况下，视图中显示的内容越多，视图在内存方面的效率就越高。

话虽如此，我个人认为在View中2-10个显示之间的任何位置在内存方面都可以忽略不计。毕竟，在View中保留少量显示确实可以达到其实际目的（否则，为什么它们会首先出现在其中？）。

关于第二个问题（其他过滤器的性能影响等），可以，向视图中添加某些参数会影响性能。如果您想确切知道多少，可以转到admin / structure / views / settings（如果您在D7中），然后选择“在实时预览期间显示有关视图的信息和统计信息”，“ 显示SQL查询 ”和“ 显示性能统计信息”。。这是性能屏幕的屏幕截图：

如果您对查询的行为（对多少行进行了分析，使用了哪些键）更感兴趣，则可以从“视图”界面复制查询（一旦选择了“显示SQL查询”），然后分析查询使用MySQL explain命令。有大量的文章像这样一个对explain在谷歌的使用。