我正试图为一个大型查询找出我的选项，考虑到它的作用，这个查询需要花费相当长但合理的时间。它有许多联接，并且必须针对多达预定义数量的参数进行搜索。其中一些参数值是预定义的(选择框)，而另一些是自由格式的文本框(不幸的是，LIKE带有前缀和后缀通配符)。返回的数据集很大，过滤器选项很可能会频繁更改。结果集的顺序也由用户控制。此外，用户访问权限必须仅限于用户有权访问的结果。此授权作为基线WHERE子句的一部分进行处理，无论选择何种筛选器，都将应用该子句。
我并不是真的在寻找查询优化建议，因为我已经审查了查询，并根据我的需求尽可能多地检查/优化了查询计划。我更感兴趣的是用于优化查询之后的替代解决方案。除了尝试将查询分解为单独的较小的位(不幸的是，这不是一个可接受的解决方案)之外，我只能想到两个选项。但是，我认为他们不适合这种情况。
- 缓存首先出现在我的脑海中，但我认为基于过滤器变化的可能性以及返回的大型数据集
- 根据我的研究，像ElasticSearch和Solr这样的选项不会是合适，因为数据集可以被我的多个程序操纵，这些数据存储很快就会过时
是否有其他选项可以根据这些要求提高搜索功能的感知性能？
您没有为具体的解决方案提供足够的关于表和查询的信息。
正如@jmarkmurphy在评论中提到的，DB2和IBMi自己做"缓存"。我同意，在处理大量不同的结果集时，你不太可能改进它。但您需要确保您使用的是IBM提供的产品。例如，如果使用RPGLE中嵌入的SQL，请确保没有set option CLOSQLCSR=*ENDMOD。还要检查您正在使用的QAQQINI中的设置。
您已经提到使用Visual Explain并构建一些请求的索引。这是一个良好的开端。但是，当查询在生产中运行时，请密切关注计划缓存、索引使用情况和建议的索引。
最后，您提到，您看到了对LIKE '%SOMETHING%'的使用进行的全表扫描。同样，在没有涉及列和数据的详细信息的情况下，这只是猜测什么可能有用。正如我在评论中所建议的，Omnifind for IBMi可能是一个改进。
然而，Omnifind是NOT并改进了LIKE。Omnifind旨在处理语言搜索。从文章i Can…Find a Needle in a Haystack使用DB2 for i:的OmniFind Text Search Server
SELECT story_id FROM story_library.story_table
WHERE CONTAINS(story_doc, 'blind mouse') = 1;
此查询结果将包括我们期望从典型搜索引擎中得到的匹配项。该搜索不区分大小写，并且将匹配搜索词的语言变体。换句话说，前面的查询将指示与包含"盲鼠"的文档匹配。以类似的方式，搜索"坏狼"将返回包含"大坏狼"的文档。