为什么 CONTAINS 在 JCR-SQL2 中发现不相等的文本字符串？

Question

使用 JCR-SQL2 查询时，我注意到CONTAINS操作符找到的节点与条件中的字符串不完全相同。

例子

以下查询：

SELECT * FROM [nt:base] AS s WHERE CONTAINS(s.*, 'my/search-expression')

不仅会找到包含my/search-expression字符串的节点，还会找到带有像my/another/search/expression.

为什么查询不能只找到提供的确切字符串？如何更改以缩小结果范围？

这个问题旨在由我自己回答，用于知识共享 - 但可以随意添加您自己的答案或改进现有答案。

Answer 1

示例查询的执行计划揭示了问题的根本原因：

  [nt:base] as [s] /* lucene:lucene(/oak:index/lucene) +:fulltext:my +:fulltext:search +:fulltext:expression ft:("my/search-expression") where contains([s].[*], 'my/search-expression') */

该CONTAINS操作触发全文搜索。非单词字符，如“/”或“-”，用作单词分隔符。因此，查询会查找所有包含以下单词的节点：“my”、“search”和“expression”。

可以用它做什么？有几种选择。

1. 使用双引号

如果您想将结果限制为具有精确顺序的给定单词的短语，并且它们之间没有任何其他单词，请将搜索表达式放在双引号内：

SELECT * FROM [nt:base] AS s WHERE CONTAINS(s.*, '"my/search-expression"')

现在，执行计划不同了：

[nt:base] as [s] /* lucene:lucene(/oak:index/lucene) :fulltext:"my search expression" ft:("my/search-expression") where contains([s].[*], '"my/search-expression"') */

查询现在将查找整个短语，而不是单个单词。但是，它仍然会忽略非单词字符，因此也会找到这样的短语：“我的搜索表达式”或“我的搜索表达式”。

2.使用LIKE表达式（不推荐）

如果只想找到确切的短语，保留非单词字符，可以使用LIKE表达式：

SELECT * FROM [nt:base] AS s WHERE s.* LIKE '%my/search-expression%'

然而，这要慢得多。我需要添加另一个条件以避免在解释执行计划期间超时。对于此查询：

SELECT * FROM [nt:base] AS s WHERE s.* LIKE '%my/search-expression%'  AND ISDESCENDANTNODE([/content/my/content]) 

执行计划是：

[nt:base] as [s] /* traverse "/content/my/content//*" where ([s].[*] like '%my/search-expression%') and (isdescendantnode([s], [/content/my/content])) */

它只会找到带有以下短语的节点：“my/search-expression”。

3.使用双引号并细化结果

使用第一种方法（CONTAINS带双引号）并稍后优化结果可能会更好，例如，如果查询是从应用程序运行的，则在应用程序代码中。

4.混合包含和喜欢

另一种选择是将全文搜索和LIKE表达式与AND：

SELECT * FROM [nt:base] AS s WHERE CONTAINS(s.*, '"my/search-expression"') AND s.* LIKE '%my/search-expression%'

现在的执行计划是：

[nt:base] as [s] /* lucene:lucene(/oak:index/lucene) :fulltext:"my search expression" ft:("my/search-expression") where (contains([s].[*], '"my/search-expression"')) and ([s].[*] like '%my/search-expression%') */

现在，它应该同时快速和严格。