CustTableListPage篩選太慢

Question

當我嘗試過濾CustTableListPage上的CustAccount字段時，過濾時間太長。 在其他字段上沒有延遲。 我正在嘗試僅過濾部分帳號，例如“ * 123”。 我已經為可托管的對象進行了重新索引編制，還更新了靜態變量，但根本沒有明顯的區別。 當我在視圖中添加列表頁的查詢時，它通常像其他字段一樣過濾custAccount字段。 有什么建議嗎？ 編輯：我們的版本是AX 2012 r2 cu8，不是每個用戶都會遇到的基於用戶的問題，Interaction類具有一些自定義功能，但僅用於設置一些按鈕啟用/禁用道具。 等等...我試圖看查詢執行我發現不清楚。 像FETCH_API_CURSOR_000000..x

Answer 1

記錄此執行的痕跡並找到瓶頸。

Answer 2

請記住，必須謹慎使用通配符（例如* ）。 因為不能使用 SQL 索引，所以使用以通配符開頭的過濾器字符串會降低所有性能。

最后使用通配符

假設您有一個字典，並且必須列出所有以“ Foo” 開頭的單詞。 您可以跳過“ F”之前的所有條目，然后跳過“ Fo”之前的所有條目，然后跳過“ Foo”之前的所有條目，然后從此處開始結果列表。

同樣，要求基礎SQL引擎列出所有以'123'（=過濾字符串'123 *'） 開頭的 CustAccount條目，從而可以在CustAccount上使用索引來快速跳至相關數據。

一開始使用通配符

想象一下，您仍然擁有該詞典，並且必須列出所有以“ ing” 結尾的單詞。 除了遍歷整個詞典並檢查每個單詞的結尾（由於字母排序），您別無選擇。

這解釋了為什么要求SQL引擎列出所有以'123' 結尾的 CustAccount條目（=過濾字符串'* 123'）意味着必須調查所有 CustAccount值。 因此，AOS遍歷所有條目，並使用SQL游標執行此操作。 那就是您在SQL級別上看到的FETCH_API_CURSOR語句。

可能的解決方案

1. 告知最終用戶，在大型表上使用通配符在過濾字符串的開頭總是很慢。
2. 加強SQL Server硬件/分配的資源（更快的CPU，更多的RAM，更快的磁盤等）。
3. 在CustAccount上創建全文索引（ 不建議這樣做，請仔細研究性能影響）。

Answer 3

我已經解決了問題。 CustTableListPage查詢對DirPartyTable.Name字段進行了排序。 當我刪除此排序時，使用通配符進行過濾就像是一種魅力。