Marklogic 通配符搜索误报问题（SQL 相当于 %something%）

Question

我对 MarkLogic 中通配符搜索的行为有疑问。

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

这是 return 误报的代码：

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*" return 正确值，但“*something*” return 误报？我该如何解决这个问题？

输入示例：

<Document><Information>another updated document</Information></Document>
<Document><Information>INCUMBENCY CERTIFICATE</Information></Document>
<Document><Information>Certificate of Incumbency</Information></Document>
<Document><Information>something 344_dated 243</Information></Document>
<Document><Information>another terminated document</Information></Document>

输出：

所有文件都是匹配的，尽管只有 1 和 4 应该 returned。

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

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

Answer 1

特定元素中未过滤的通配符查询（即不仅仅是文档）可能 return 没有位置索引的误报。我会尝试启用 word positions 和 element word positions 中的一个或两个。还可能值得测试您是否看到启用 fast element phrase searches.

带来的额外性能改进

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

更新： 查看更新后的测试用例后，如果未启用 trailing wildcard word positions，尾随通配符索引的准确性似乎不够好。那和 three character word positions 似乎是解决这种类型的前导和尾随元素通配符查询所必需的。

如果不是绝对必要，我建议禁用 one character searches 和 two character searches，因为它们会生成大型索引。 fast element character searches 和 fast element trailing wildcard searches 在您的情况下似乎也不需要准确性，因此您可能想测试没有它们时您的查询是否足够快。

Answer 2

在使用 cts:element-value-query 时，您是否尝试过使用 "exact" 选项来获得准确的结果？尝试使用一次，让我知道它的行为方式。我遇到过一次类似的问题。

Marklogic 通配符搜索误报问题（SQL 相当于 %something%）

Marklogic wildcarded search false positives issue ( SQL like %something% equivalent )

search

xquery

wildcard

marklogic