如需让用户能够探索数据，最好的方法之一就是构建有效的 Looker 信息中心，为用户提供精心策划的视图。如果您想为用户打造出色的性能体验，请在设计信息中心时考虑本页上的提示。
Looker 信息中心会在浏览器中加载。如需构建出最佳性能，请牢记以下事实。
信息中心性能最重要的元素是底层 SQL 查询性能。每个信息中心元素在未从缓存返回时，都会运行一个 SQL 查询，该查询需要时间在底层数据库上执行。如需详细了解如何构建高性能查询，请参阅优化 Looker 性能最佳实践页面中的优化查询性能部分。
某些组件对内存的消耗比对 SQL 的消耗更大，这些组件可能会导致信息中心性能缓慢：
-
数据量对性能的影响最大。单个元素中返回的数据越多 ，消耗的内存资源就越多。返回数千个数据点的 Look 和信息中心元素将使用更多内存。
-
限制信息中心元素的数量。对于数量没有硬性规定，因为单个元素的设计会根据一些因素（本页稍后会介绍）影响其内存消耗。不过，请避免创建包含 25 个或更多查询的信息中心。通过在信息中心之间创建导航链接 或创建指向自定义网址的链接，以 创建从一个信息中心到另一个信息中心的精心策划的导航，从而保持信息中心性能的流畅。您还可以尝试将类似的衡量指标串联到同一个单值可视化图表中，以避免出现许多单图块可视化图表。
-
策略性地使用信息中心设置。如果 您的信息中心使用自动刷新，请确保其刷新速度不快于您的 ETL 流程。一般来说，您应避免将自动刷新设置为快于 15 分钟。如果信息中心旨在进行过滤，请勿使用在加载时运行。使用必需的过滤条件，以防止用户在没有 必要过滤条件 的情况下运行信息中心。
-
利用缓存。最佳实践是使用 datagroups 将所有 Looker 内容（信息中心、Look、时间表）与您的 ETL 流程同步。这有助于避免在数据不是最新时进行不必要的查询。
-
查询后处理功能（例如 合并结果、自定义字段和 表计算）会消耗内存。使用的查询后处理功能越多，消耗的内存就越多。如果您在多个 Look 和信息中心中使用相同的 表计算、合并结果或自定义字段，请考虑尽可能将它们硬编码到 LookML 模型中。一般来说，请勿向信息中心添加超过四个合并结果图块。
-
透视维度会消耗内存。Look 或信息中心图块中 透视的维度越多，加载信息中心时消耗的内存就越多 。如第一个要点中所述，这是因为返回的数据越多，使用的数据就越多。如果您要透视的维度具有高基数（许多唯一值），则每个值都会有一个列。在信息中心或 Look 级别进行过滤，让用户能够选择他们最感兴趣比较的维度值，而不是一次显示所有内容。
-
拥有许多列和行会消耗更多内存。为了获得更好的浏览器性能，建议使用 50 列或更少的列。同样，如第一个要点中所述，返回大量行和许多列的 Look 可能会降低性能。在信息中心或 Look 级别进行过滤，以减少元素中的结果数量。
-
利用 共享过滤条件和单个查询 以 在多个图块中呈现单个查询结果。这应通过利用一个 查询为多个信息中心元素提供支持，从而减少从信息中心运行的查询总数。
-
AND/OR 过滤条件。可以创建的群组数量没有限制；不过，过多的过滤条件群组可能会影响浏览器性能。
添加元素后，请务必测试信息中心性能。在构建过程中，请继续前往信息中心并刷新页面，以确定添加更多 Look 后性能会受到怎样的影响。
对新的 Looker 信息中心感到满意后，请务必利用 文件夹权限，以 确保信息中心不会被意外更改。利用用户群组批量管理内容访问权限，而不是逐个用户管理。
如果您遇到性能问题，请直接与 Looker 支持团队 联系，我们的团队随时准备调查并提供帮助！