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