【www.shanpow.com--手抄报内容】
一：[solr查询语法]SOLR 查询
http://haiziwoainixx.iteye.com/blog/2095599
一.基本查询
q – 查询字符串，必须的。fl – 指定返回那些字段内容，用逗号或空格分隔多个。start – 返回第一条记录在完整找到结果中的偏移位置，0开始，一般分页用。rows – 指定返回结果最多有多少条记录，配合start来实现分页。sort – 排序，格式：sort=<field name>+<desc|asc>[,<field name>+<desc|asc>]… 。示例：（inStock desc, price asc）表示先 “inStock” 降序, 再 “price” 升序，默认是相关性降序。wt – (writer type)指定输出格式，可以有 xml, json, php, phps, 后面 solr 1.3增加的，要用通知我们，因为默认没有打开。fq – （filter query）过虑查询，作用：在q查询符合结果中同时是fq查询符合的，例如：q=mm&fq=date_time:[20081001 TO 20091031]，找关键字mm，并且date_time是20081001到20091031之间的。
q.op – 覆盖schema.xml的defaultOperator（有空格时用”AND”还是用”OR”操作逻辑），一般默认指定df – 默认的查询字段，一般默认指定qt – （query type）指定那个类型来处理查询请求，一般不用指定，默认是standard。
- 排除在要排除的词前加上 “-” (不包含”号) 号其它indent – 返回的结果是否缩进，默认关闭，用 indent=true|on 开启，一般调试json,php,phps,ruby输出才有必要用这个参数。version – 查询语法的版本，建议不使用它，由服务器指定默认值。[Solr的检索运算符]“:” 指定字段查指定值，如返回所有值*:*2“?”2表示单个任意字符的通配“*” 表示多个任意字符的通配（不能在检索的项开始使用*或者?符号）2“~”2表示模糊检索，如检索拼写类似于”roam”的项这样写：roam~将找到形如foam和roams的单词；roam~0.8，检索返回相似度在0.8以上的记录。2邻近检索，如检索相隔10个单词的”apache”和”jakarta”，”jakarta apache”~10“^”2控制相关度检索，如检索jakarta apache，同时希望去让”jakarta”的相关度更加好，那么在其后加上”^”符号和增量值，即jakarta^4 apache布尔操作符AND、||2布尔操作符OR、2&&布尔操作符NOT、!、-2（排除操作符不能单独与项使用构成查询）“+” 存在操作符，要求符号”+”后的项必须在文档相应的域中存在2( ) 用于构成子查询22 [] 包含范围检索，如检索某时间段记录，包含头尾，date:[200707 TO 200710]{}2不包含范围检索，如检索某时间段记录，不包含头尾date:{200707 TO 200710}” 转义操作符，特殊字符包括+ – & | ! ( ) { } [ ] ^ ” ~ * ? : “
二.高亮
hl-highlight，h1=true，表示采用高亮。可以用h1.fl=field1,field2 来设定高亮显示的字段。
hl.fl: 用空格或逗号隔开的字段列表。要启用某个字段的highlight功能，就得保证该字段在schema中是stored。如果该参数未被给出，那么就会高 亮默认字段 standard handler会用df参数，dismax字段用qf参数。你可以使用星号去方便的高亮所有字段。如果你使用了通配符，那么要考虑启用 hl.requiredFieldMatch选项。
hl.requireFieldMatch:如果置为true，除非该字段的查询结果不为空才会被高亮。它的默认值是false，意味 着它可能匹配某个字段却高亮一个不同的字段。如果hl.fl使用了通配符，那么就要启用该参数。尽管如此，如果你的查询是all字段（可能是使用 copy-field 指令），那么还是把它设为false，这样搜索结果能表明哪个字段的查询文本未被找到
hl.usePhraseHighlighter:如果一个查询中含有短语（引号框起来的）那么会保证一定要完全匹配短语的才会被高亮。
hl.highlightMultiTerm如果使用通配符和模糊搜索，那么会确保与通配符匹配的term会高亮。默认为false，同时hl.usePhraseHighlighter要为true。
hl.snippets：这是highlighted片段的最大数。默认值为1，也几乎不会修改。如果某个特定的字段的该值被置为0（如f.allText.hl.snippets=0），这就表明该字段被禁用高亮了。你可能在hl.fl=*时会这么用。
hl.fragsize:每个snippet返回的最大字符数。默认是100.如果为0，那么该字段不会被fragmented且整个字段的值会被返回。大字段时不会这么做。
hl.mergeContiguous:如果被置为true，当snippet重叠时会merge起来。
hl.maxAnalyzedChars:会搜索高亮的最大字符，默认值为51200，如果你想禁用，设为-1
hl.alternateField:如果没有生成snippet（没有terms 匹配），那么使用另一个字段值作为返回。
hl.maxAlternateFieldLength:如果hl.alternateField启用，则有时需要制定alternateField的最大字符长度，默认0是即没有限制。所以合理的值是应该为
hl.snippets * hl.fragsize这样返回结果的大小就能保持一致。
hl.formatter:一个提供可替换的formatting算法的扩展点。默认值是simple，这是目前仅有的选项。
显然这不够用，你可以看看org.apache.solr.highlight.HtmlFormatter.java 和 solrconfig.xml中highlighting元素是如何配置的。注意在不论原文中被高亮了什么值的情况下，如预先已存在的em tags，也不会被转义，所以在有时会导致假的高亮。
hl.fragmenter:这个是solr制 定fragment算法的扩展点。gap是默认值。regex是另一种选项，这种选项指明highlight的边界由一个正则表达式确定。这是一种非典型 的高级选项。为了知道默认设置和fragmenters (and formatters)是如何配置的，可以看看solrconfig.xml中的highlight段。regex 的fragmenter有如下选项：
hl.regex.pattern:正则表达式的pattern
hl.regex.slop:这是hl.fragsize能变化以适应正则表达式的因子。默认值是0.6，意思是如果hl.fragsize=100那么fragment的大小会从40-160.
三.分组查询：
1. Field Facet
Facet 字段通过在请求中加入 ”facet.field” 参数加以声明 , 如果需要对多个字段进行 Facet查询 , 那么将该参数声明多次 . 比如
/select?q=联想
&facet=on
&facet.field=cpu
&facet.field=videoCard
各个 Facet 字段互不影响 , 且可以针对每个 Facet 字段设置查询参数 . 以下介绍的参数既可以应用于所有的 Facet 字段 , 也可以应用于每个单独的 Facet 字段 . 应用于单独的字段时通过
f.字段名.参数名=参数值
这种方式调用 . 比如 facet.prefix 参数应用于 cpu 字段 , 可以采用如下形式
f.cpu.facet.prefix=Intel
1.1 facet.prefix
表示 Facet 字段值的前缀 . 比如 ”facet.field=cpu&facet.prefix=Intel”, 那么对 cpu字段进行 Facet 查询 , 返回的 cpu 都是以 ”Intel” 开头的 ,”AMD” 开头的 cpu 型号将不会被统计在内 .
1.2 facet.sort
表示 Facet 字段值以哪种顺序返回 . 可接受的值为 true(count)|false(index,lex). true(count) 表示按照 count 值从大到小排列 . false(index,lex) 表示按照字段值的自然顺序 (字母 , 数字的顺序 ) 排列 . 默认情况下为 true(count). 当 facet.limit 值为负数时 ,默认 facet.sort= false(index,lex).
1.3 facet.limit
限制 Facet 字段返回的结果条数 . 默认值为 100. 如果此值为负数 , 表示不限制 .
1.4 facet.offset
返回结果集的偏移量 , 默认为 0. 它与 facet.limit 配合使用可以达到分页的效果 .
1.5 facet.mincount
限制了 Facet 字段值的最小 count, 默认为 0. 合理设置该参数可以将用户的关注点集中在少数比较热门的领域 .
1.6 facet.missing
默认为 ””, 如果设置为 true 或者 on, 那么将统计那些该 Facet 字段值为 null 的记录.
1.7 facet.method
取值为 enum 或 fc, 默认为 fc. 该字段表示了两种 Facet 的算法 , 与执行效率相关 .
enum 适用于字段值比较少的情况 , 比如字段类型为布尔型 , 或者字段表示中国的所有省份.Solr 会遍历该字段的所有取值 , 并从 filterCache 里为每个值分配一个 filter( 这里要求 solrconfig.xml 里对 filterCache 的设置足够大 ). 然后计算每个 filter 与主查询的交集 .
fc( 表示 Field Cache) 适用于字段取值比较多 , 但在每个文档里出现次数比较少的情况 .Solr 会遍历所有的文档 , 在每个文档内搜索 Cache 内的值 , 如果找到就将 Cache 内该值的count 加 1.
1.8 facet.enum.cache.minDf
当 facet.method=enum 时 , 此参数其作用 ,minDf 表示 minimum document frequency. 也就是文档内出现某个关键字的最少次数 . 该参数默认值为 0. 设置该参数可以减少 filterCache 的内存消耗 , 但会增加总的查询时间 ( 计算交集的时间增加了 ). 如果设置该值的话 ,官方文档建议优先尝试 25-50 内的值 .
2. Date Facet
日期类型的字段在文档中很常见 , 如商品上市时间 , 货物出仓时间 , 书籍上架时间等等 . 某些情况下需要针对这些字段进行 Facet. 不过时间字段的取值有无限性 , 用户往往关心的不是某个时间点而是某个时间段内的查询统计结果 . Solr 为日期字段提供了更为方便的查询统计方式 .当然 , 字段的类型必须是 DateField( 或其子类型 ).
需要注意的是 , 使用 Date Facet 时 , 字段名 , 起始时间 , 结束时间 , 时间间隔这 4 个参数都必须提供 .
与 Field Facet 类似 ,Date Facet 也可以对多个字段进行 Facet. 并且针对每个字段都可以单独设置参数 .
2.1 facet.date
该参数表示需要进行 Date Facet 的字段名 , 与 facet.field 一样 , 该参数可以被设置多次 , 表示对多个字段进行 Date Facet.
2.2 facet.date.start
起始时间 , 时间的一般格式为 ” 1995-12-31T23:59:59Z”, 另外可以使用 ”NOW”,”YEAR”,”MONTH” 等等 , 具体格式可以参考 org.apache.solr.schema. DateField 的 java doc.
2.3 facet.date.end
结束时间 .
2.4 facet.date.gap
时间间隔 . 如果 start 为 2009-1-1,end 为 2010-1-1.gap 设置为 ”+1MONTH” 表示间隔1 个月 , 那么将会把这段时间划分为 12 个间隔段 . 注意 ”+” 因为是特殊字符所以应该用 ”%2B” 代替 .
2.5 facet.date.hardend
取值可以为 true|false, 默认为 false. 它表示 gap 迭代到 end 处采用何种处理 . 举例说明 start 为 2009-1-1,end 为 2009-12-25,gap 为 ”+1MONTH”,hardend 为 false 的话最后一个时间段为 2009-12-1 至 2010-1-1;hardend 为 true 的话最后一个时间段为 2009-12-1 至 2009-12-25.
2.6 facet.date.other
取值范围为 before|after|between|none|all, 默认为 none.
before 会对 start 之前的值做统计 .
after 会对 end 之后的值做统计 .
between 会对 start 至 end 之间所有值做统计 . 如果 hardend 为 true 的话 , 那么该值就是各个时间段统计值的和 .
none 表示该项禁用 .
all 表示 before,after,all 都会统计 .
举例 :
&facet=on
&facet.date=date
&facet.date.start=2009-1-1T0:0:0Z
&facet.date.end=2010-1-1T0:0:0Z
&facet.date.gap=%2B1MONTH
&facet.date.other=all
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields"/>
<lst name="facet_dates">
<int name="2009-01-01T00:00:00Z">5</int>
<int name="2009-11-01T00:00:00Z">1</int>
<int name="2009-12-01T00:00:00Z">5</int>
<str name="gap">+1MONTH</str>
<date name="end">2010-01-01T00:00:00Z</date>
<int name="before">180</int>
<int name="after">5</int>
<int name="between">54</int>
</lst>
</lst>
3. Facet Query
Facet Query 利用类似于 filter query 的语法提供了更为灵活的 Facet. 通过 facet.query 参数 , 可以对任意字段进行筛选 .
例 1:
&facet=on
&facet.query=date:[2009-1-1T0:0:0Z TO 2009-2-1T0:0:0Z]
&facet.query=date:[2009-4-1T0:0:0Z TO 2009-5-1T0:0:0Z]
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries">
<int name="date:[2009-1-1T0:0:0Z TO 2009-2-1T0:0:0Z]">5</int>
<int name="date:[2009-4-1T0:0:0Z TO 2009-5-1T0:0:0Z]">3</int>
</lst>
<lst name="facet_fields"/>
<lst name="facet_dates"/>
</lst>
例 2:
&facet=on
&facet.query=date:[2009-1-1T0:0:0Z TO 2009-2-1T0:0:0Z]
&facet.query=price:[* TO 5000]
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries">
<int name="date:[2009-1-1T0:0:0Z TO 2009-2-1T0:0:0Z]">5</int>
<int name="price:[* TO 5000]">116</int>
</lst>
<lst name="facet_fields"/>
<lst name="facet_dates"/>
</lst>
例 3:
&facet=on
&facet.query=cpu:[A TO G]
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries">
<int name="cpu:[A TO G]">11</int>
</lst>
<lst name="facet_fields"/>
<lst name="facet_dates"/>
</lst>
4. key 操作符
可以用 key 操作符为 Facet 字段取一个别名 .
例 :
&facet=on
&facet.field={!key=中央处理器}cpu
&facet.field={!key=显卡}videoCard
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields">
<lst name="中央处理器">
<int name="Intel 酷睿2双核 T6600">48</int>
<int name="Intel 奔腾双核 T4300">28</int>
</lst>
<lst name="显卡">
<int name="ATI Mobility Radeon HD 4">63</int>
<int name="NVIDIA GeForce G 105M">24</int>
<int name="NVIDIA GeForce GT 240M">21</int>
<int name="NVIDIA GeForce G 103M">8</int>
<int name="NVIDIA GeForce GT 220M">8</int>
<int name="NVIDIA GeForce 9400M G">7</int>
<int name="NVIDIA GeForce G 210M">6</int>
</lst>
</lst>
<lst name="facet_dates"/>
</lst>
5. tag 操作符和 ex 操作符
当查询使用 filter query 的时候 , 如果 filter query 的字段正好是 Facet 字段 , 那么查询结果往往被限制在某一个值内 .
例 :
&fq=screenSize:14
&facet=on
&facet.field=screenSize
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields">
<lst name=" screenSize">
<int name="14.0">107</int>
<int name="10.2">0</int>
<int name="11.1">0</int>
</lst>
</lst>
<lst name="facet_dates"/>
</lst>
可以看到 , 屏幕尺寸 (screenSize) 为 14 寸的产品共有 107 件 , 其它尺寸的产品的数目都是0, 这是因为在 filter 里已经限制了 screenSize:14. 这样 , 查询结果中 , 除了 screenSize=14 的这一项之外 , 其它项目没有实际的意义 .
有些时候 , 用户希望把结果限制在某一范围内 , 又希望查看该范围外的概况 . 比如上述情况 ,既要把查询结果限制在 14 寸屏的笔记本 , 又想查看一下其它屏幕尺寸的笔记本有多少产品 . 这个时候需要用到 tag 和 ex 操作符 .
tag 就是把一个 filter 标记起来 ,ex(exclude) 是在 Facet 的时候把标记过的 filter 排除在外 .
例 :
&fq={!tag=aa}screenSize:14
&facet=on
&facet.field={!ex=aa}screenSize
返回结果 :
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields">
<lst name=" screenSize">
<int name="14.0">107</int>
<int name="14.1">40</int>
<int name="13.3">34</int>
</lst>
</lst>
<lst name="facet_dates"/>
</lst>
二：[solr查询语法]solr查询参数使用说明
q – 查询字符串，必须的。Solr 中用来搜索的查询。有关该语法的完整描述，请参阅 参考资料 中的 “Lucene QueryParser Syntax”。可以通过追加一个分号和已索引且未进行断词的字段的名称来包含排序信息。默认的排序是 score desc，指按记分降序排序。 q=myField:Java AND otherField:developerWorks; date asc此查询搜索指定的两个字段并根据一个日期字段对结果进行排序。
start – 返回第一条记录在完整找到结果中的偏移位置，0开始，一般分页用。
rows – 指定返回结果最多有多少条记录，配合start来实现分页。
sort – 排序，格式：sort=<field name>+<desc|asc>[,<field name>+<desc|asc>]… 。示例：（inStock desc, price asc）表示先 “inStock” 降序, 再 “price” 升序，默认是相关性降序。
wt – (writer type)指定输出格式，可以有 xml, json, php, phps, 后面 solr 1.3增加的，要用通知我们，因为默认没有打开。
fq – （filter query）过虑查询，作用：在q查询符合结果中同时是fq查询符合的，
fl- field作为逗号分隔的列表指定文档结果中应返回的 Field 集。默认为 “*”，指所有的字段。“score” 指还应返回记分。例如 *,score将返回所有字段及得分。用solrj的bean时，得在query中指定 query.set("fl", "*,score");
q.op – 覆盖schema.xml的defaultOperator（有空格时用"AND"还是用"OR"操作逻辑），一般默认指定
df – 默认的查询字段，一般默认指定
qt – （query type）指定那个类型来处理查询请求，一般不用指定，默认是standard。
indent – 返回的结果是否缩进，默认关闭，用 indent=true|on 开启，一般调试json,php,phps,ruby输出才有必要用这个参数。
version – 查询语法的版本，建议不使用它，由服务器指定默认值。
hight: hl-highlight，h1=true，表示采用高亮。可以用h1.fl=field1,field2 来设定高亮显示的字段。
hl.fl: 用空格或逗号隔开的字段列表。要启用某个字段的highlight功能，就得保证该字段在schema中是stored。如果该参数未被给出，那么就会高 亮默认字段 standard handler会用df参数，dismax字段用qf参数。你可以使用星号去方便的高亮所有字段。如果你使用了通配符，那么要考虑启用 hl.requiredFieldMatch选项。
hl.requireFieldMatch:如果置为true，除非该字段的查询结果不为空才会被高亮。它的默认值是false，意味 着它可能匹配某个字段却高亮一个不同的字段。如果hl.fl使用了通配符，那么就要启用该参数。尽管如此，如果你的查询是all字段（可能是使用 copy-field 指令），那么还是把它设为false，这样搜索结果能表明哪个字段的查询文本未被找到
hl.usePhraseHighlighter:如果一个查询中含有短语（引号框起来的）那么会保证一定要完全匹配短语的才会被高亮。
hl.highlightMultiTerm如果使用通配符和模糊搜索，那么会确保与通配符匹配的term会高亮。默认为false，同时hl.usePhraseHighlighter要为true。
hl.snippets：这是highlighted片段的最大数。默认值为1，也几乎不会修改。如果某个特定的字段的该值被置为0（如f.allText.hl.snippets=0），这就表明该字段被禁用高亮了。你可能在hl.fl=*时会这么用。
hl.fragsize:每个snippet返回的最大字符数。默认是100.如果为0，那么该字段不会被fragmented且整个字段的值会被返回。大字段时不会这么做。
hl.mergeContiguous:如果被置为true，当snippet重叠时会merge起来。
hl.maxAnalyzedChars:会搜索高亮的最大字符，默认值为51200，如果你想禁用，设为-1
hl.alternateField:如果没有生成snippet（没有terms 匹配），那么使用另一个字段值作为返回。
hl.maxAlternateFieldLength:如果hl.alternateField启用，则有时需要制定alternateField的最大字符长度，默认0是即没有限制。所以合理的值是应该为
hl.snippets * hl.fragsize这样返回结果的大小就能保持一致。
hl.formatter:一个提供可替换的formatting算法的扩展点。默认值是simple，这是目前仅有的选项。显然这不够用，你可以看看org.apache.solr.highlight.HtmlFormatter.java 和 solrconfig.xml中highlighting元素是如何配置的。注意在不论原文中被高亮了什么值的情况下，如预先已存在的em tags，也不会被转义，所以在有时会导致假的高亮。
hl.fragmenter:这个是solr制 定fragment算法的扩展点。gap是默认值。regex是另一种选项，这种选项指明highlight的边界由一个正则表达式确定。这是一种非典型 的高级选项。为了知道默认设置和fragmenters (and formatters)是如何配置的，可以看看solrconfig.xml中的highlight段。regex 的fragmenter有如下选项：
hl.regex.pattern:正则表达式的pattern
hl.regex.slop:这是hl.fragsize能变化以适应正则表达式的因子。默认值是0.6，意思是如果hl.fragsize=100那么fragment的大小会从40-160.
这些值都可以在select中加入，也可以用solrj的api去设定，也可以配置在solrconfig.xml中配置。示例如下：<requestHandler name="search" class="solr.SearchHandler" default="true"> <!– default values for query parameters can be specified, these will be overridden by parameters in the request –> <lst name="defaults"> <str name="echoParams">explicit</str> <int name="rows">10</int> <bool name="hl">true</bool> <str name="hl.fl">title,content</str> <str name="f.content.hl.fragsize">200</str> <str name="mlt.qf"> id^10.0 title^10.0 content^1.0 </str> </lst></requestHandler>
solr用着还是不错，比自己去搞Lucene好多了，可以加上jsoup去抓网页指定的内容，再配置下xml,用solrj写个好看的搜索页面。有空自己用grails写一个玩下看。
三：[solr查询语法]solr之~模糊查询
有的时候，我们一开始不可能准确地知道搜索的关键字在 Solr 中查询出的结果是什么，因此，Solr 还提供了几种类型的模糊查询。模糊匹配会在索引中对关键字进行非精确匹配。例如，有的人可能想要搜索某个前缀开始的单词（称为通配符查询），或者想要查询和关键字有一两个字母不相同的单词（称为模糊查询或编辑距离查询），或者你想要查询两个关键字，并且这两个关键字之间的距离不会大于某个最大值（称为临近查询）。总的说来，模糊匹配是查询中的一个强大的工具。
通配符查询
在 Solr 中最普遍使用的模糊查询就是使用通配符。假设你想要查询以 offic 开始的文档。下面列举出这个查询的几个版本：
查询语句： office OR officer OR official OR officiate OR … 这个列表中的单词是所有你以 offic 开头的单词。
因为你需要找到的所有匹配都在 Solr 索引中。因此，你可以使用星号（*）作为通配符来执行相同的功能：
查询语句： offi* 匹配 office， officer， official 等等。
除了放在关键字的最后，通配符也可以放到关键字中间，例如，如果你想要同时匹配 officer 和 offer：
查询语句： off*r 匹配 offer，officer，officiator 等。
星号通配符（*）表示匹配 0 个或多个字符。如果你只需要匹配一个字符，那么可以使用问号（?）通配符：
查询语句： off?r 匹配 offer 但是不匹配 officer。
以通配符为头进行查询
在 Solr 中使用通配符相当强大。但是，使用通配符进行查询也会带来很大的开销。一旦使用统配符的查询，那么在关键字中第一个通配符之前的部分需要在反向索引中全部查询出来。那后，每个查询出来的结果在逐一进行检查，看是否符合查询条件。正是因为这样，所以在统配符之前的字符越多，那么查询将会越快。例如，使用 engineer* 进行查询将不会带来很高的开销（因为这个查询在反向索引中不会找到太多的匹配），但是 e* 进行查询的开销就相当大，它将会匹配所有 e 开头的单词。
如果使用通配符开头的话，开销也会相当大。例如，你需要查询 ing 结尾的单词（像 caring，liking 和 smiling），那么将会带来严重的性能问题：
查询语句： *ing
如果你真的需要进行这样的查询，那么有一个现成的解决方案，这个解决方案就是添加 ReversedWildcardFilterFactory 到你的字段类型的分析链中（详细内容以后会讲到）。
ReversedWildcardFilterFactory 将会插入两条记录到 Solr 的索引中（一条是单词的正向文本内容，一条是单词的反向文本内容）：
索引：caring/#gnirac liking/#gnikil smiling/#gnilims
当提交了 *ing 的查询之后，Solr 知道使用索引中的反向内容去查询，这样由通配符开头带来的性能问题就转换成了普通的通配符查询问题。
但是要注意，如果将这个特性打开的话，那么在 Solr 索引中的所有关键字都将会由两条索引记录，这无疑增加了索引的大小并且降低了整个查询的速度。因此，不建议打开这个功能，除非你的应用程序真的非常需要。
关于使用统配符查询的最后一点就是使用通配符只能对单独的关键字进行插叙，而不能对短语进行查询，例如：
正常： softwar* eng?neering
不正常：”softwar* eng?neering”
如果你需要在短语中使用通配符，你将要把整个短语作为一个关键字存储到索引中，我们将会在以后讲解这个功能。
范围查询
Solr 也提供了在已知值之间的范围查询。当你需要查询某个范围之间的子集的时候，这个功能非常有用。例如，如果你只想查询 2012 年 2 月 2 日到 2012 年 8 月 2 日这六个月之间的文档，那么可以执行下面的查询：
查询语句：created:[2012-02-01T00:00.0Z TO 2012-08-02T00:00.0Z]
范围查询的语法结构也可以用在其它字段上：
查询语句： yearsOld:[18 TO 21] 匹配：18， 19， 20， 21
查询语句：title:[boat TO boulder] 匹配：boat， boil， book， boulder，等
查询语句：price:[12.99 TO 14.99] 匹配： 12.99， 13.000009， 14.99， 等
上面的范围查询都是放在一对方括号中，这成为被包含的范围查询语法（闭区间）。Solr 也支持不被包含的范围查询语法（开区间），这需要把查询范围放到大括号中：
查询语句：yearsOld:{18 TO 21} 匹配：19 和 20 但是不匹配 18 或 21
查询语句：yearsOld:{18 TO 21} Matches 19 and 20 but not 18 or 21
虽然看起来有点奇怪，但是 Solr 也提供了半包含的范围查询语法（半开区间）：
查询语句： yearsOld:[18 TO 21} 匹配：18， 19， 20， 但是不匹配 21
范围查询的效率比查询单个关键字要低，但是为某个特定的范围进行检索提供了巨大的灵活性。需要注意的是，使用范围查询的返回结果是按照 Solr 索引进行排序的，也就是说是按照字典顺序。如果你创建了一个文本字段来存储数字，那么这些数字的返回顺序应该是这样：1， 11， 111， 12， 120， 13， 等。如果是数字类型的字段，那么将使用特殊的方式来进行索引这样可以弥补这个问题，但是要明白一点，在 Solr 索引中进行排序依赖于写入索引的时候，字段中的数据是如何被处理的。详细内容以后会说明。
模糊/编辑距离查询
对于很多搜索应用来说，很重要的功能是不仅仅需要精确匹配用户的文本内容。而且还允许一些灵活的变化，比如一些用户的拼写错误或相同单词的其它变体。Solr 通过基于 Damerau-Levenshtein 距离的编辑距离测量来支持这个功能，它将容忍 80% 以上的拼写错误。
Solr 提供的模糊编辑距离查询需要用到波浪符号（~）：
查询语句： administrator~ 匹配： adminstrator， administrater， administratior，等
这个查询不仅匹配原始的关键字（administrator），还有其它与原始关键字有 2 个编辑距离的关键字。一个编辑距离表示增加，删除，取代或交换一个任意字符。关键字 adminstrator （在第六个字母出少了字符“i”）和原始关键字之间相差一个编辑距离，因为它删除了一个字符。同样 sadministrator 和原始关键字之间也是相差一个编辑距离，因为它在前面添加了一个字符。administratro 也与原始关键字有一个编辑距离，因为它将最后两个字符交换了顺序。
在编辑距离查询中也可以精确指定编辑距离：
查询语句：administrator~1 匹配一个编辑距离以内的内容。
查询语句：administrator~2 匹配两个编辑距离以内的内容（如果没有提供编辑距离的话，这个就是默认值）。
查询语句：administrator~N 匹配 N 个编辑距离以内的内容。
注意，任何编辑距离大于 2 的查询将会使查询速度变得很慢。如果编辑距离在 2 以内，那么将会使用很高效率的 Levenshtein 自动机（Levenshtein automaton），但是如果编辑距离大于 2，将会退回到更慢的编辑距离实现。
临近查询
在前面，我们看到了编辑距离查询是如何查找相似的关键字，而不是进行精确匹配。编辑距离的概念适用于关键字中字符的变换或短语中各个单词之间的变化。
如果你想要通过 Solr 的索引查询公司中所有员工的档案。一种方法是枚举出公司中所有可能的职位：
查询语句：”chief executive officer” OR “chief financial officer” OR “chief
marketing officer” OR “chief technology officer” OR …
当然，这种查询的前提是你需要知道公司中所有可能的职位，这当然不现实。另外的一种解决方案是单独搜索每个关键字：
查询语句： chief AND officer
这将会匹配所有可能的用例，但是同时也会匹配所有包含了这两个关键字的文档。例如：One chief concern arising from the incident was the safety of the police officer on duty。这个文档明显不符合我们的要求，但是如果使用上面的查询语句，那么将会返回这个文档。
Solr 提供了解决这种问题的方案：临近插叙。在上面的例子中，比较好的策略是请求 Solr 返回所有包含了关键字 chief 和关键字 officer 临近的文档。这可以通过下面的查询语句样例来实现：
查询语句： “chief officer”~1
解释：chief 和 officer 之间最多只能有一个距离
例子：”chief executive officer”, “chief financial officer”
查询语句：”chief officer”~2
解释：chief 和 officer 之间最多只能有两个编辑距离
例子：”chief business development officer”, “officer chief”
查询语句：”chief officer”~N
解释：查询 chief 和 officer 之间有 N 个编辑距离。
事实上，对短语进行精确匹配的查询语句 “chief development officer” 很容易改写成 “chief development officer”~0。这两个查询都返回相同的结果，因为在第二个查询语句中，编辑距离设置为 0，所以和精确查询得到的结果是相同的。这两种机制都需要使用到 Solr 中存储的关键字位置（前面的文章介绍过）来计算编辑距离。还有一点需要注意的是，临近查询并不是完全按照编辑距离的定义来进行查询，因为它的查询结果中，所有的关键字都必须存在。而编辑距离查询的定义中，可以对关键字进行删除和修改。
但是其它的编辑距离定义依旧保留，例如增加和换位。顺着这条线，你可能会注意到，你需要设置 2 进行临近查询的时候（”chief officer”~2）才能查询出文本 officer chief。这是因为第一次编辑将 chief 和 officer 修改成相同的位置；第二次编辑将 chief 才能将 chief 编辑到 officer 后面。这也再次说明了临近查询使用的并不是真正的编辑距离（在编辑距离中，位置互换的编辑距离只能算 1）。
