以下最佳实践反映了由经验丰富的 Looker 组成的跨职能团队分享的建议。这些数据洞见是我们在与 Looker 客户合作多年的过程中积累的，涵盖从实施到长期成功的各个方面。这些做法适用于大多数用户和情况，但您在实施时应根据自己的判断。
优化查询性能
您可以通过以下前端和后端提示，确保以最佳方式构建和执行针对数据库的查询：
-
请尽可能使用
many_to_one联接构建探索。从最精细级别联接到最高详细级别 (many_to_one) 的视图通常可提供最佳查询性能。 -
尽可能最大限度地缓存，以便与 ETL 政策同步，从而减少数据库查询流量。默认情况下，Looker 会将查询缓存 1 小时。您可以使用
persist_with参数在探索中应用 datagroups，从而控制缓存政策并将 Looker 数据刷新与 ETL 流程同步。这样一来，Looker 便可与后端数据流水线更紧密地集成，从而最大限度地提高缓存使用率，而不会冒分析过时数据的风险。命名缓存政策可应用于整个模型和/或单个探索和永久派生表 (PDT)。 - 尽可能使用 Looker 的汇总感知功能创建汇总或摘要表，以便 Looker 用于查询，尤其是大型数据库的常见查询。您还可以利用汇总认知度来大幅提升整个信息中心的效果。如需了解详情，请参阅“汇总感知”教程。
- 使用 PDT 可加快查询速度。将包含许多复杂联接或性能不佳联接的探索，或包含子查询或子选择的维度转换为 PDT，以便在运行时之前预先联接并准备就绪。
- 如果您的数据库方言支持增量 PDT，请配置增量 PDT，以缩短 Looker 重建 PDT 表所需的时间。
- 避免根据 Looker 中定义的连接主键将视图联接到探索。而是应根据视图中构成串联主键的基础字段进行联接。或者，您也可以将视图重新创建为 PDT，并在表的 SQL 定义（而非视图的 LookML）中预定义串联主键。
- 利用 SQL Runner 中的“解释”工具进行基准测试。
EXPLAIN会生成给定 SQL 查询的数据库查询执行计划概览，以便您检测可优化的查询组件。如需了解详情，请参阅如何使用EXPLAIN优化 SQL 社区帖子。 -
声明索引。您可以通过 SQL Runner 直接在 Looker 中查看每个表的索引，只需点击表格中的齿轮图标，然后选择显示索引即可。
最常见的可以受益于索引的列是重要日期和外键。为这些列添加索引可提高几乎所有查询的性能。这也适用于 PDT。您可以适当地应用 LookML 参数，例如
indexes、sort keys和distribution。 - 如果数据库的硬件或必要的预配资源（例如 AWS）不足以处理大型数据集，请增加数据库的内存、核心和 I/O（输入/输出），以提高查询性能。
优化 Looker 服务器性能
您还可以采取措施来确保 Looker 服务器和应用的性能达到最佳：
- 限制单个信息中心内的元素数量。没有确定此数量的确切规则，因为每个元素的设计都会因各种因素而影响内存用量；不过，如果信息中心包含 25 个或更多功能块，其性能往往会出现问题。
- 有策略地使用信息中心自动刷新功能。如果信息中心使用自动刷新功能，请确保其刷新速度不快于后台运行的 ETL 流程。
- 有策略地使用数据透视，避免在信息中心功能块和主题中过度使用数据透视。包含枢轴维度的查询将会消耗更多内存。所切换的维度越多，加载内容（探索、数据分析或信息中心）时消耗的内存就越多。
- 请谨慎使用合并结果、自定义字段和表计算等功能。 这些功能旨在用作概念验证，以帮助您设计模型。 最佳实践是在 LookML 中对所有常用的计算和函数进行硬编码，这将生成要在数据库中处理的 SQL。 过多的计算可能会争用 Looker 实例上的 Java 内存，导致 Looker 实例响应速度变慢。
-
当存在大量视图文件时，限制模型中包含的视图数量。在单个模型中包含所有视图可能会降低性能。如果项目中存在大量视图，请考虑仅在每个模型中添加所需的视图文件。考虑为视图文件名使用战略性命名惯例，以便在模型中轻松包含一组视图。
includes参数文档中列出了示例。 -
默认情况下，避免在信息中心功能块和主题中返回大量数据点。返回数千个数据点的查询将会消耗更多内存。通过将前端
过滤条件应用于信息中心、数据分析和探索，以及在 LookML 级别使用
required filters、conditionally_filter和sql_always_where参数，尽可能限制数据。 - 请谨慎使用所有结果选项下载或传送查询，因为某些查询可能非常大，在处理时会使 Looker 服务器过载。
如需有关如何找出性能问题根源的更多帮助，请参阅性能概览最佳做法页面。