CustTableListPage过滤太慢

Question

当我尝试过滤CustTableListPage上的CustAccount字段时，过滤时间过长。在其他领域没有延迟。我正在尝试过滤部分帐号，例如“* 123”。 我已经完成了重新索引的可用性和更新的静态，但没有明显的差异。 当我在视图中添加listpage的查询时，它通常像其他字段一样过滤custAccount字段。 有什么建议吗？ 编辑： 我们的版本是AX 2012 r2 cu8，不是每个用户都会遇到的基于用户的问题，交互类有一些custimizations但只是设置一些按钮启用/禁用道具。等...我试图查看查询执行我发现的不清楚。类似于FETCH_API_CURSOR_000000..x

Answer 1

记录此执行的痕迹并找出瓶颈。

Answer 2

请记住，必须小心使用通配符（例如*）。使用以通配符开头的过滤器字符串会导致所有性能下降，因为无法使用SQL 索引。

最后使用通配符

想象一下，你有一个词典，必须用＆＃39; Foo＆＃39;列出开始的所有单词。你可以在F＆＃39;之前跳过所有条目，然后在Fo＆＃39;之前删除所有条目，然后在Foo＆＃39;之前删除所有条目。并从那里开始你的结果列表。

同样，要求底层SQL引擎列出所有CustAccount条目以开头＆＃39; 123＆＃39; （=过滤字符串＆＃39; 123 *＆＃39;）允许使用CustAccount上的索引快速跳转到相关数据。

在开头使用通配符

想象一下，您仍然拥有该词典，并且必须列出结尾所有单词＆＃39;。除了浏览整个字典并检查每个单词的结尾（由于按字母排序），你别无选择。

这解释了为什么要求SQL引擎列出所有CustAccount条目结尾用＆＃39; 123＆＃39; （=过滤字符串＆＃39; * 123＆＃39;）表示必须调查所有 CustAccount值。因此，AOS遍历所有条目并使用SQL游标执行此操作。这是您在SQL级别上看到的FETCH_API_CURSOR语句。

可能的解决方案

1. 告知您的最终用户，在过滤字符串的开头使用通配符在大型表格上总是很慢。
2. 加强SQL服务器硬件/分配的资源（更快的CPU，更多的RAM，更快的磁盘......）。
3. 在CustAccount上创建一个全文索引（不这个的粉丝，应该彻底调查性能影响。）

Answer 3

我已经解决了这个问题。 CustTableListPage查询对DirPartyTable.Name字段进行了排序。当我删除这个排序时，使用通配符过滤就像魅力一样。