过滤条件建议是 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 hours”。建议有自己的缓存，您无法从“探索”页面手动清除这些缓存。如果您需要清除缓存以获取建议，可以采用以下方法：
- 如果使用具有
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 应该会在过滤框的右侧显示一个旋转的加载圆圈。
<ph type="x-smartling-placeholder">
否则，Looker 就不会尝试填充建议。在 LookML 中，检查第 1 步中所述的条件是否满足，并且建议功能未在 field、view 或“探索”级别（使用 sql_always_where 或 access_filter）关闭。请注意，默认情况下，Hadoop 方言会在所有视图文件上添加 suggestions: no。
如果系统尝试加载建议，请按照查看 Chrome 网络控制台的说明操作。
查看 Chrome 网络控制台
Chrome 网络控制台可能会突出显示查询本身存在的错误，或显示是否有返回结果 。
- 使用快捷键 Ctrl + Shift +J（在 Windows 上）或 Command + option + J（在 Mac 上），或选择查看 >，在浏览器中打开“网络”标签页。开发 >开发者工具。
- 在 Look、探索或信息中心的过滤框中选择。
- “开发者工具”面板应显示过滤条件建议请求，您可以选择该请求以获取更多信息。
- 标头将显示 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 Not Found：
如需了解详情，请选择此请求的响应。
在这种情况下，您可以看到建议失败的原因是，根据请求的响应找不到该字段：
{"class":"FieldNotFound","text":"Field not found."}
如果没有错误，但按预期时也没有任何建议，请检查建议查询是否从缓存中提取（网络控制台中的 cache: true）- 这可能表明需要清除缓存，对提供建议的维度使用 suggest_persist_for 参数。
查找 Looker 尝试运行的建议查询的证据
您可以查看 Looker 管理面板中的查询页面，确保生成过滤条件的查询（查询页面上的来源字段会显示过滤条件建议）不会生成错误。选择查询的详细信息按钮，然后选择在 SQL Runner 中打开选项。验证 SQL 的语法是否正确。如果您发现异常情况（例如缺少字段名称或特殊字符不正确），请进行检查以确保您未使用流动参数或模板化过滤条件。
- 如果查询需要模板化过滤条件输入才能运行，系统不会填充任何过滤条件建议。
- 如果查询使用带有
default_value的参数，该值将插入过滤条件建议查询。在这种情况下，过滤器建议查询不会根据用户输入动态更新。根据默认值，这可能会导致没有过滤器建议或过滤器建议错误。请考虑改为在信息中心内使用关联的过滤条件。