过滤条件建议是 Looker 中一款功能强大的工具。请务必了解这些建议的来源和运作方式，以便在过滤条件建议未按预期运行时，能够有效排查问题。本页介绍了过滤条件建议的运作方式、可能出错的原因，以及可能无法填充的原因。
过滤器建议的运作方式
过滤条件建议可让用户在过滤条件中输入值时节省时间，并确保用户选择的数据中存在的选项。当用户选择过滤条件框时，该字段下方会显示一个建议列表。在此示例中，在订单“探索”部分中，选择状态字段的过滤条件框后，系统会显示一个下拉列表，其中包含“已取消”“已完成”和“待处理”等值。
这些建议列表的来源是什么？
Looker 会对数据库运行 SELECT distinct <field> 查询，以检索该字段的所有可能选项。该查询类似于以下 SQL：
SELECT DISTINCT <field_name> FROM <table> WHERE (<field_name> LIKE '%' OR <field_name> LIKE '% %') GROUP BY 1 ORDER BY 1 LIMIT 1000
当用户在过滤框中输入字符时，Looker 会在 WHERE 子句中替换相应的条件，以过滤结果。然后，Looker 会在过滤条件建议中显示前 100 个结果。
我可以更改系统填充的建议内容吗？
开发者可以使用各种 LookML 参数来更改和自定义显示的建议。如需了解详情，请参阅更改过滤器建议文档页面。
系统是否会缓存建议？
默认情况下，Looker 会将查询结果缓存一小时。您可以使用 suggest_persist_for LookML 参数来自定义过滤条件建议的缓存长度。suggest_persist_for 参数的默认值为“6 小时”。建议有自己的缓存，无法从“探索”页面手动清除。如果您需要清除建议缓存，可以采用以下方法：
- 如果“探索”是使用包含
sql_trigger的数据集群缓存的，您可以在 Looker 管理面板的数据集群页面中手动重置整个数据集群的缓存，但这会刷新使用该数据集群保留的所有查询的缓存。 - 您可以在字段级别使用
suggest_persist_for参数，并将其设置为“0 秒”，以清除该字段的过滤建议缓存。缓存对所有用户都是全局的。当某个用户刷新缓存以获取建议时，其他用户看到的结果也会受到影响。
为什么过滤条件建议有误？
现在，您已经了解了过滤条件建议的填充方式，接下来可以确定过滤条件建议可能出错的原因。最常见的原因是，在缓存过滤条件建议与发现错误结果之间，数据发生了更改或更新。
例如，假设用户 A 在早上第一时间运行了“探索”。用户 A 从建议下拉列表中选择一些过滤条件值。大约半小时后，数据库的 ETL 流程会完成。然后，用户 B 查看了用户 A 之前运行的相同探索。用户 B 想知道过滤条件建议为何不正确。出现差异的原因是，缓存的建议查询未根据数据库新完成的 ETL 流程进行更新，因此显示了意外结果。
如果是这种情况，您可以使用本页上文是否缓存了建议？部分中所述的方法刷新建议缓存。
为什么没有显示过滤条件建议？
导致过滤条件建议未填充的原因有多种。以下问题排查步骤突出显示了可能的原因：
- 检查过滤器类型。
- 检查是否存在限制建议的
access_filter或sql_always_where。 - 检查是否有
suggest_dimension parameter。 - 检查当用户在过滤条件中选择或输入文本时，系统是否尝试加载建议。
- 查看 Chrome 网络控制台。
- 查找 Looker 尝试运行的建议查询的证据。
检查过滤器类型
如果这是 LookML 信息中心过滤条件，请确保过滤条件类型为字段。其他过滤条件类型不会填充建议。
-
确保过滤条件字段在其 LookML 定义中为
type: string。对number类型字段应用的过滤条件不会填充建议。 - 是匹配（高级）过滤条件吗？“匹配（高级）”过滤条件需要使用 Looker 表达式，因此系统不会填充建议。
检查是否存在限制建议的 access_filter 或 sql_always_where
通常，使用 sql_always_where 或 access_filter 时，系统会限制相应探索的过滤条件建议。这样可以防止用户看到无法访问的过滤条件建议。如果您确定特定维度或过滤条件字段中没有任何可能的值会泄露敏感信息，则可以使用 bypass_suggest_restrictions 重新启用过滤条件建议。
检查是否有 suggest_dimension parameter
使用 suggest_dimension 参数时，系统不会填充过滤条件建议，除非“探索”中引用了建议的维度，并且该维度的视图被定义为“探索”的基础视图。
对于建议维度的视图不是基本视图的探索，请添加 suggest_explore 参数，引用将该视图用作基本视图的探索。
检查在过滤条件中选择或输入文本时是否尝试加载建议
检查在您选择或输入过滤条件框中的文本时，Looker 是否会尝试加载建议。Looker 应在过滤条件框的右侧显示旋转的加载圈。
如果没有，则 Looker 不会尝试填充建议。检查是否满足第一步中所述的条件，以及在 LookML 中是否未在 field、view 或“探索”级别（使用 sql_always_where 或 access_filter）关闭建议。请注意，Hadoop 方言默认会在所有视图文件中添加 suggestions: no。
如果系统尝试加载建议，请按照检查 Chrome 网络控制台中的说明操作。
查看 Chrome 网络控制台
Chrome 网络控制台可能会突出显示查询本身的错误，或显示是否有缓存返回的结果。
- 在浏览器中，按快捷键 Ctrl + Shift + J（在 Windows 上）或 ⌘ + Option + J（在 Mac 上）打开“Network”标签页，或者从浏览器顶部的 Chrome 选项栏中依次选择 View > Develop > Developer tools。
- 在“探索”或信息中心的过滤条件框中进行选择。
- 开发者工具面板应会显示过滤建议请求，您可以选择该请求以了解详情。
- 标头将显示 Looker 发出以检索建议值的内部 API 请求。在此示例中，假设 Looker 正在发出以下 API 请求，其中
<yourinstance>代表您的实例的网址：
<yourinstance>/api/internal/models/the_look/views/order_items/fields/users.state/suggestions?term=
- 在 API 请求中，检查
/models/后面列出的模型是否存在。在此示例中，模型名为the_look。 - 虽然网址显示为
/views/，但这指的是字段的来源“探索”。检查/views/后面列出的“探索”是否存在。在此示例中，探索功能名为order_items。 - 检查
/fields/后面列出的字段是否存在。在此示例中，该字段为users.state。
此 API 请求的响应将显示确切的错误消息。例如，建议的状态代码为 404 未找到：
选择此请求的回复即可了解详情。
在本例中，您可以看到，建议失败是因为系统根据对请求的响应找不到该字段：
{"class":"FieldNotFound","text":"Field not found."}
如果没有错误，但在预期时间内也没有显示任何建议，请检查建议查询是否从缓存（在网络控制台中为 cache: true）中提取数据。这可能意味着需要对提供建议的维度使用 suggest_persist_for 参数来清除缓存。
查找 Looker 尝试运行的建议查询的证据
您可以查看 Looker 管理面板中的查询页面，确保生成过滤条件的查询（查询页面上的来源字段将显示为过滤条件建议）未生成错误。选择相应查询的详细信息按钮，然后选择在 SQL Runner 中打开选项。验证 SQL 的语法是否正确。如果您发现异常情况（例如字段名称缺失或特殊字符有误），请检查并确保您未使用 Liquid 参数或模板过滤条件。
- 如果查询需要模板过滤条件输入才能运行，则系统不会填充任何过滤条件建议。
- 如果查询使用带有
default_value的参数，则该值将插入到过滤条件建议查询中。在这种情况下，过滤条件建议查询不会根据用户输入的内容动态更新。根据默认值，这可能会导致系统不提供过滤建议，也可能会提供错误的过滤建议。不过，您可以考虑在信息中心内使用关联的过滤条件。