axapta - CustTableListPage 过滤太慢

Question

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

Answer 1

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

Answer 2

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

最后使用通配符

想象一下，您有一个字典，并且必须列出所有以 'Foo'开头的单词。您可以跳过“F”之前的所有条目，然后是“Fo”之前的所有条目，然后是“Foo”之前的所有条目，然后从那里开始您的结果列表。

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

在开始时使用通配符

想象一下，你仍然有那个字典，并且必须列出所有以“ing”结尾的单词。除了浏览整个字典并检查每个单词的结尾（由于字母排序）之外，您别无选择。

这解释了为什么要求 SQL 引擎列出所有以“123”（= 过滤字符串“*123”）结尾的 CustAccount 条目意味着必须调查所有CustAccount 值。因此 AOS 循环遍历所有条目并使用 SQL 游标来执行此操作。那就是您在 SQL 级别看到的 FETCH_API_CURSOR 语句。

可能的解决方案

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

Answer 3

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