过滤条件建议是 Looker 中一款功能强大的工具。请务必了解这些建议的来源和运作方式，以便在过滤条件建议未按预期运行时，能够有效排查问题。本页介绍了过滤条件建议的运作方式、建议可能有误的原因以及建议无法填充的原因。
过滤器建议的运作方式
当用户在过滤条件中输入值时，过滤条件建议可以节省时间，并确保用户选择数据中存在的选项。当用户选择过滤条件框时，该字段下方会显示一个建议列表。在此示例中，从 Orders 探索中选中 Status（状态）字段对应的过滤条件框，即会显示一个下拉列表，其中包含值“cancelled”（已取消）、“complete”（完成）和“pending”（待处理）作为选项
这些建议从何而来？
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 中，检查第 1 步中所述的条件是否满足，并且建议功能未在 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/后列出的“探索”是否存在。在此示例中，Explore 名为order_items。 - 检查
/fields/后面列出的字段是否存在。在此示例中，该字段为users.state。
此 API 请求的响应将显示确切的错误消息。例如，建议的状态代码为 404 未找到：
如需了解详情，请选择此请求的响应。
在本例中，您可以看到，建议失败是因为系统根据对请求的响应找不到该字段：
{"class":"FieldNotFound","text":"Field not found."}
如果没有错误，但按预期时也没有任何建议，请检查建议查询是否从缓存中提取（网络控制台中的 cache: true）- 这可能表明需要清除缓存，对提供建议的维度使用 suggest_persist_for 参数。
查找 Looker 尝试运行的建议查询的证据
您可以查看 Looker 管理面板中的查询页面，确保生成过滤条件的查询（查询页面上的来源字段将显示为过滤条件建议）未生成错误。选择查询的详细信息按钮，然后选择在 SQL Runner 中打开选项。验证 SQL 的语法是否正确。如果您发现异常情况（例如缺少字段名称或特殊字符有错误），请检查以确保您未使用流动参数或模板化过滤条件。
- 如果查询需要模板过滤条件输入才能运行，则系统不会填充任何过滤条件建议。
- 如果查询使用带有
default_value的参数，该值将插入过滤条件建议查询。在这种情况下，过滤条件建议查询不会根据用户输入的内容动态更新。根据默认值，这可能会导致系统不提供过滤建议，也可能会提供错误的过滤建议。请考虑改为在信息中心内使用关联的过滤条件。