为什么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"') */

查询现在将查找整个短语，而不是单个单词。但是，它仍然会忽略非单词字符，因此也会找到这样的短语：“my search expression”或“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.混合CONTAINS和LIKE

另一种选择是将全文搜索和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%') */

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