Search Marklogic通配符搜索误报问题（类似SQL的%something%等效）

我有一个关于MarkLogic中通配符搜索行为的问题

基本上，我要做的是复制SQL，比如%something%查询

以下是返回误报的代码：

xquery version "1.0-ml";
cts:search(/, 
  cts:element-query(fn:QName("","Document"),
  cts:element-word-query(fn:QName("","Information"),"*date*", ("wildcarded"),0), ()),
  'unfiltered')

请注意：

• 未过滤选项必须保留，因为性能是必需的
• 我正在使用Unicode排序规则，并已启用：
  • 三字符搜索
  • 尾随通配符搜索
  • 快速元素尾随通配符搜索
  • 双字符搜索
  • 单字符搜索
  • 快速元素字符搜索

我不明白的是为什么“*something”和“something*”返回正确的值，而“*something*”返回误报？我怎样才能解决这个问题

输入示例：

另一个更新的文档

在职证书

在职证书

日期为243年的某物344\u

另一个终止的文档

输出：

所有文档都是匹配的，但只应返回1和4

最终编辑：我想补充的唯一一件事是，在两个数据库上，似乎相同的设置不会产生相同的结果，一个数据库的文档负载更重。在包含大量文档的数据库中，我使用的最终设置以及给出正确结果的设置是：

• 单词搜索
• 单词位置
• 三重指数
• 快速元素词搜索
• 元素词位置
• 快速元素短语搜索
• 三字符搜索
• 三字词位置
• 快速元素字符搜索
• 尾随通配符搜索
• 尾随通配符字位置
• 快速元素尾随通配符搜索
• 单词词典：代码点整理

---

特定元素内的未筛选通配符查询（即，不仅仅是文档）可能返回没有位置索引的误报。我会尝试启用

单词位置

和

元素单词位置

中的一个或两个。如果启用

快速元素短语搜索

，您是否看到了额外的性能改进，这可能也值得测试

可能仅仅因为“*something and something*”包含更多的术语，它就过滤掉了误报，而不是因为它通过索引更准确地解析了该短语

更新：查看更新的测试用例后，如果未启用

尾随通配符单词位置，尾随通配符索引的准确性似乎不够好。解析这种类型的前导和尾随元素通配符查询时，必须使用和
三个字符的单词位置

我建议禁用
单字符搜索
和
双字符搜索
，如果它们不是严格必需的，因为它们将生成大型索引<代码>快速元素字符搜索
和
快速元素尾随通配符搜索
在您的情况下似乎不需要精确性，因此您可能需要测试没有它们的查询是否足够快。
特定元素内的未筛选通配符查询（即，不只是使用文档）可能返回没有位置索引的误报。我会尝试启用
单词位置
和
元素单词位置
中的一个或两个。如果启用
快速元素短语搜索
，您是否看到了额外的性能改进，这可能也值得测试

可能仅仅因为“*something and something*”包含更多的术语，它就过滤掉了误报，而不是因为它通过索引更准确地解析了该短语

更新：查看更新的测试用例后，如果未启用
尾随通配符单词位置，尾随通配符索引的准确性似乎不够好。解析这种类型的前导和尾随元素通配符查询时，必须使用和
三个字符的单词位置

我建议禁用
单字符搜索
和
双字符搜索
，如果它们不是严格必需的，因为它们将生成大型索引<代码>快速元素字符搜索
和
快速元素尾随通配符搜索
在您的情况下似乎不需要精确性，因此您可能需要测试没有它们的查询是否足够快。
在使用cts:element-value查询时，您是否尝试使用“精确”选项来获得精确的结果？
试着用一次，让我知道它的行为。我曾经遇到过类似的问题。
在使用cts:element-value查询时，您是否尝试使用“精确”选项来获得精确的结果？
试着用一次，让我知道它的行为。我曾经遇到过类似的问题。
对不起，我最初的措辞不准确。我编辑了这篇文章，解释我的意思是“某物”和“某物*”作为单独的输入。我不认为单词位置索引在这种情况下会有帮助，但我会尝试一下，谢谢@MB单词位置索引用于确定单词在文档中的具体位置，这就是为什么无论查询词是否包含短语（位置索引也有助于提高准确性），都可能需要这些索引来进行准确的未筛选元素查询。不幸的是，即使在启用“单词位置”和“元素单词位置”后，仍然会出现错误的结果。快速元素短语搜索也设置为true。还有什么我可以试试的吗？@MB您确定在测试之前重新索引已经完成了吗？同一个查询
过滤后
返回了不同/正确的结果？我不知道还有什么好建议