篩選建議是 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 會在篩選器建議中顯示前 1,000 筆結果。
我可以變更系統顯示的建議嗎？
開發人員可以使用各種 LookML 參數，變更及自訂顯示的建議。詳情請參閱「變更篩選器建議」說明文件頁面。
建議會快取嗎？
根據預設，Looker 會將查詢結果快取一小時。您可以使用 suggest_persist_for LookML 參數，自訂篩選器建議的快取長度。suggest_persist_for 參數的預設值為「6 小時」。建議有自己的快取，無法從「探索」頁面手動清除。如要清除建議的快取，可以採取以下做法：
- 如果使用含有
sql_trigger的 datagroup 快取「探索」，您可以在 Looker 管理面板的「Datagroups」(資料群組) 頁面中，手動重設整個 datagroup 的快取，但這樣會重新整理使用該 datagroup 持續執行的所有查詢快取。 - 您可以在欄位層級使用
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) 或 command + option + J (Mac)，在瀏覽器中開啟「Network」分頁標籤，或依序選取瀏覽器頂端 Chrome 選項列中的「View」 >「Develop」 >「Developer tools」。
- 在 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/後方是否列出「探索」。在本例中，探索的名稱為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 語法正確無誤。如果發現異常情況 (例如缺少欄位名稱或出現錯誤的特殊字元)，請檢查是否未使用 Liquid 參數或範本篩選器。
- 如果查詢需要範本篩選器輸入內容才能執行，系統就不會顯示篩選器建議。
- 如果查詢使用含有
default_value的參數，該值會插入篩選器建議查詢中。在這種情況下，篩選器建議查詢不會根據使用者輸入的內容動態更新。視預設值而定，這可能會導致系統未提供篩選建議，或提供錯誤的篩選建議。建議改用資訊主頁中的連結篩選器。