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