solr学习-search翻译

solr搜索概览

solr提供了一个丰富的，可扩展的search特性。为了理解灵活性的程度，在开始的时候了解下solr 搜索中的步骤和组件是十分必要的。
当一个用户在solr中执行一个搜索，搜索query被request handler处理。request Handler是solr的一个插件，定义了solr处理请求的逻辑。solr支持各种各样的request handler。一些handler用来处理查询语句，一些用来管理任务，比如index replication。
搜索应用程序默认选择一个特定的request handler。另外，应用程序可以配置不同的request handler ，覆盖默认处理器。
为了处理一个搜索语句，request handler调用一个query parser来解释查询中的语法和参数。不同的parser支持不同的语法。solr默认的query parser是Standard Query Parser，通常称为lucene query parser。solr还有DisMax query parser 和Extended DisMax（eDisMax）查询解析器。标准的查询解析器的语法检查很严格，但是DisMax的查询解析有更高的容错性。DisMax查询解析被用来提供经验相似性功能，比如google很少对用户显示语法错误。Extended DisMax查询解析器是DIsMax的提升版，处理所有Lucene查询语法，并提供语法的容错性。它包含几个额外的特性。
另外，有几个所有查询解析器都支持的公共查询参数。
查询解析器的输入：
- 搜索字符串—index需要查询的term组
- 微调查询参数。包括提升个别字符串或field的重要性，在搜索term组中使用Boolean，或排除搜索结果的内容。
- 查询应答展示控制参数。比如明确结果展示排序，限制搜索应用schema的返回filed。
搜索参数也可以指定filter query。作为搜索应答的一部分，一个filter query在整个索引上查询，并缓存结果。因为solr为filter query分配了一个单独的cache，所以战略上来说使用filter query可以提升查询的性能。（尽管有相似的名字，query filter 和analysis filter是不相关的。filter query在搜索的时候对整个index进行操作，但是analysis filter，比如Tokenizers，为产生index数据而按照特定规则解析文档。）
一个搜索查询可以要求结果中高亮特定的term；因此选中的term将会带有颜色，从而在搜索结果中彰显出来。
高亮可以让我们在一个很长的文档中，很容易找到相关的信息。solr支持多个term高亮。solr支持丰富的搜索参数来控制term怎样高亮显示。
搜索应答也可以配置成包含snippet（document 摘要）高亮。流行的搜索引擎，如Google和Yahoo！在搜索结果中返回snippet：3-4行的文档，提供了搜索结果的描述。
为了帮助使用者在分组搜索中不用额外操作，solr提供了两种分组搜索：faceting和clusting。
faceting 将搜索结果按照种类整理。在每个种类中，solr支持相关term命中的次数，这被称为facet constraint。faceting让用户很容易通过网址发掘信息，比如movie网址或产品查看网址。这些网址会有很多种类，每个种类下会有很多数据。
下面的图展示了CNET web site的一个facet使用实例，CNET也是第一个使用solr的网站。

faceting使用在建立索引时定义的field。在上面的例子中，使用的filed包含能够描述这些种类的信息digital cameras：manufacturer，resolution，zoom range。
Clustering 在搜索执行的过程中通过相似性对结果进行分组，而不是当内容创建索引的时候。clustering的结果通常缺少facet结果的层级结构，尽管如此clustering是很有用的。cluster能够揭露出搜索结果中不期望的信息，并帮助用户用户隔离出他们不需要的信息。
在早期的查询中，solr也提供了MoreListThis特性，使用户能够提交专注于特定返回term的新的查询。MoreLikeThis可以和facet，clustering一起使用。
solr的组件response writer 管理查询应答最终的展现。solr提供了一系列的response writer，包括一个XML response writer和Json Response writer。
下图描述了搜索过程的关键组成。

Velocity查询UI

solr包含了一个简单的查询UI，UI基于VelocityResponseWriter（也叫做Solritas）。其中给出了几个特性的实例，比如searching，faceting，highlighting， autocomplete，geospatial searching。
当使用sample_techproducts_configs配置，能够通过地址http://localhost:8983/solr/techproducts/browse访问。

关联

Relevance是查询结果满足用户查询信息的一个度量。
一个查询应答的关联依赖于query执行的场景。一个单独的查询应用可能在多个用户的多个场景使用，满足不同的需求和期望。比如说，一个其后数据的搜索引擎可能被用于高校研究员学习气候走势，农民用于计算春天最后一个霜冻的可能日期，公共研究员关注下雨模式和洪水周期，以及一个高校学生计划到一个地区度假的行李该装什么。因为这些人的动机不同，每个特定结果的关联性也应该不同。
怎样才能使查询结果具有广泛适用性？关联可以解决这个问题。在一些场景中，需要查询结果中不包含一些特定的文档。比如传票中的合法电子取证。但是另外一些情况就不需要，比如在网上大量的蛋糕食谱中搜索食谱。当配置solr时，你应该综合权衡各个因素，比如及时性和简单性。
电子取证和食谱的实例显示了关联的两个重要概念：
- Precision。查询出的结果占总数的百分比。
- Recall。查询出的结果，返回给调用者的百分比。
回到上边提到的例子，电子取证需要recall=100%，返回所有查询出来的相关信息。但是在食谱的应用中不需要提供这么高的准确度。在一些情况下，返回太多的数据不合理。在一些场景，返回少一些的，具有更高关联性的数据是最好的方式。
使用precision和recall的定义，可以在不同的用户和查询时，给出高质量的关联结果。一个完美的系统会为每个用户的每个请求设置100% precision和100% recall。 换句话说，系统会给出所有相关的信息，而剔除所有不相关的信息。在实际中，真实系统的precision和recall通常给出固定数目的结果，最常用的是10 。
在faceting，query filter和其他搜索组件中，solr应用可以灵活的配置，帮助用户微调搜索结果，从而返回更具关联性的数据。solr可以通过配置precision和recall来实现特定用户群体的需求。
应该考虑的用户配置：
- 应用不同用户的需求。
- 在不同场景返回有意义的种类。
- document 关联的继承
- document的时间性是否有意义。
记住这些因子，对搭建系统很有帮助。

查询语法和解析

solr支持多个查询解析器，并为搜索应用设计者提供了高灵活性来控制查询解析。
这部分解释了怎样定制query parser。同时也描述了solr主要query parser的语法和特征，并描述了其他parser的主要使用场景。solr parser有一些公共的查询参数，可以参考Common Query Parameters章节。
这里讲描述：
- Standard 查询解析器
- DisMax查询解析器
- Extended DisMax查询解析器
- 其他解析器
query parser 插件都是QParserPlugin的子类。如果需要自定义解析，可以扩展这个类。

公共查询参数

下面是几个公共参数，被Search RequestHandler支持。

defType

设定solr 处理q查询参数的query parser。比如：
defType=dismax
如果没有设定defType，默认采用Standard Query Parser（相当于defType= Lucene）

排序参数

排序参数将搜索结果按照asc或desc的顺序排列。参数可以用于数值或字符类型的内容。排序方向的设定，大小写都支持（asc 和ASC都支持）
solr可以使用document评分或者进行了索引或docValues设置的单个值field进行排序。（也就是说field需要配置multiValued=false，并且docValues=true或indexed=true设置了一个，才能排序。如果field没有开启docValues，那么在运行时将采用索引的term。）也就是说：
- field没有被标记（filed没有analyzer，且它的内容没有分解成token，那么这导致无法排序）。或者
- filed使用了analyzer（比如KeywordTokenizer），只生成了一个term。
如果希望一个用来标记并用于搜索的field能够进行排序，在schema中定义filed的copyField。在filed上搜索，在它的拷贝上排序。

example result – 如果排序参数被忽略，根据score desc排序 score desc score降序排列 price asc price field进行升序排列 inStock desc，price asc inStock field降序排列，并在排序结果中用price field升序排列

排序参数语法：
- 一个排序必须包含一个field（或者用score伪装成field），之后跟一个空格（在url中编码为+或者%20），之后再跟一个排序方向（asc或desc）。
- 多个排序可以用逗号分隔，语法： sort=

start 参数

制定了查询结果开始的偏移位置，从这个位置之后开始返回数据。
默认是0.也就是说默认情况下solr的搜索结果没有偏移。
可以用于分页。

rows 参数

从查询结果中分页返回，指定返回的数目。
默认是10.

fq（Filter Query）参数

fq定义了一个查询，在不影响score的时候，限制返回数据的集合大小。由于fq的查询结果被单独缓存，对于加速复杂查询有很大的帮助。当之后有个查询使用相似的过滤条件，那么会命中缓存，过滤结果会从缓存中返回。
当使用fq参数，注意以下几点：
- fq参数在一个查询中可以定义多次。只有document存在于每个fq结果集的交集中，才会被返回。在下面的例子中，只有popularity大于10并且section=0的document才会满足条件。

fq=popularity:[10 TO *]&fq=section:0

• filter query能够包含复杂的Boolean查询语句。之前的例子可以写成一个fq，包含两个条件：

fq=+popularity:[10 TO *] +section:0

• 每个fq的结果document集合都是单独缓存的。因此，考虑之前的例子：如果两个条件经常被一起使用，就使用一个fq包含两个条件；如果两个条件都独立使用，那么久用两个fq。
• 可以使用filter语法来代替fq，保证单独缓存，且达到缓存过滤查询的联合。
• 和所有的参数一样：URL中的特殊字符需要替换和编码。内置的工具可以帮助你进行URL编码。比如： http://meyerweb.com/
  eric/tools/dencoder/

fl（Field List)参数

fl参数制定了返回结果中包含的field。这些字段必须设置stored=“true”或docValues=”true“。
field列表是空格或逗号分隔的字段名称的字符串。“score”可以作为一个描述document分数的字段返回。字符“*”选择了document中所有的filed，这些字段应该设置stored=“true”或docValues=”true“且useDocValuesAsStored=”true“（当开启docValues时，自动开启）。也可以对这些filed使用pseudo-field，function和transformer。
下面的表格显示了fl的基本实例：

Field List Result id name price 只返回这三个字段 id name，price 只返回这三个字段 id score 返回id字段和document score * 返回所有的stored字段，也包括docValues filed。这也是fl的默认配置。

score

返回所有的field，以及每个field的score *，dv_field_name 返回document中所有的stored field，以及docValues字段，以及来自dv_field_nam的docValues（即使useDocValuesAsStored= false)

fl的function
function在结果中作用于每个document，且返回pseudo-field：

fl=id,title,product(price,popularity)

fl 的document transformer
document transformer可以用于修改结果中每个document的信息。

fl=id,title,[explain]

field 别名
通过添加前缀‘“displayName”’，可以更改filed，function或transformer的key。比如：

fl=id,sales_price:price,secret_sauce:prod(price,popularity),why_score:[explain style=nl]

{"response": { "numFound": 2, "start": 0, "docs": [{ "id": "6H500F0", "secret_sauce": 2100.0, "sales_price": 350.0, "why_score": { "match": true, "value": 1.052226, "description": "weight(features:cache in 2) [DefaultSimilarity], result of:", "details": [{ "..."}]}}]}}

debug参数

debug可以定义多次，支持下面的参数：
- debug=query：只返回关于query的debug信息。
- debug=timing：返回query执行耗费时间
- debug=results:返回关于score结果的信息。
默认情况下，score explanation作为大的String值返回，使用换行符和tab组织结构和可读性，但是debug.explain.structured=true需要配置。
- debug=all:返回所有的信息。
为了向后兼容旧版本的solr，debugQuery=true应该用debug=all来替换。
默认的操作不包括debug信息。

explainOther参数

explainOther参数制定了Lucene查询，从而指定document的集合。如果这个参数设置了并设为空，那么查询会返回debugging 信息。查询的信息由主查询（q参数设定）确定，并会随着符合Lucene查询的document“explain info”一起返回。比如：

q=supervillians&debugQuery=on&explainOther=id:juggernaut

上面的查询允许查看符合条件的document的分数解释信息，并和符合id:juggernaut的document的explain信息进行比对，找出为什么查询结果不正确。
此参数默认不设置，不会有额外的解释信息返回。

timeAllowed 参数

timeAllowed设定搜索完成的时间（按ms计算）。如果指定时间内搜索没有完成，将会返回局部结果，但是类似于numFound，facet count和stats将不会计算整个结果集合。
核对时间的点：
- Query Expansion
- Document collection
由于这个检查是周期执行的，所以请求实际执行时间会稍微多余或等于timeAllowed指定时间。如果请求处理的其他阶段花费时间，比如自定义组件，这个参数将无法中断请求处理。

segmentTerminateEarly 参数

这个参数可以设成true或false。
如果设成true，且mergePolicyFactory是通过sort设定了排序参数的 SortingMergePolicyFactory，solr将会使用EarlyTerminatingSortingCollector。
如果使用了提前终止，responseHeader中将会设置segmentTerminatedEarly信息。
类似于使用timeAllowed，当提前终止，numFound，Facet以及stats不会计算整个结果集的信息。
默认情况segmentTerminateEarly = false。

omitHeader参数

可以设成true或false。
如果设成true，返回的结果中排除header信息。header包含了请求信息，比如完成的时间。默认值为false。

wt参数

wt选择了solr格式化查询结果的Response Writer。可以在Response Writer章节阅读详细信息。
如果没有设定，将会使用JSON格式返回。

cache参数

solr缓存所有查询和filter query。可以通过cache=false，不缓存结果。
可以通过cost选项控制non-cached filter query执行顺序。这会允许消耗小的non-cached filter 在消费大的non-cached filter之前执行。
对于每个高消耗的filter，如果cache=false,且cost>=100，且查询实现了PostFilter接口，这个query将会需要一个Collector用于在document满足主查询以及其他filter query时起作用。可以有多个后处理filter，他们也是通过cost排序。
例如：
这是一个普通的range查询filter，所有符合的document数据将会生成和缓存。

fq={!frange l=10 u=100}mul(popularity,price)

下面query和主query并行执行：

fq={!frange l=10 u=100 cache=false}mul(popularity,price)

下面query在每个document满足主query以及其他所有的filter时进行操作。

fq={!frange l=10 u=100 cache=false cost=100}mul(popularity,price)

logParamsList参数

默认情况下，solr记录所欲的请求参数。这个参数限制了哪些请求参数被记录。这会帮助控制记录那些重要的参数。
例如，你可以定义：

logParamsList=q,fq

那么只有q和fq的参数被记录。
如果希望没有参数被记录，那么设置 logParamsList为空 （logParamsList=）。

echoParams参数

echoParams控制哪些请求的参数包含在response头中。
echoParams参数包括以下值：
- explicit：默认值。只有实际请求中携带的参数，加上_parameter,添加到结果头中。
- all：query中所有的请求参数都返回。包括solrconfig.xml中的request handler 定义所有信息，请求中包括的参数。如果一个参数在handler和请求中都村子，则会在结果头中出现多次。
- none：结果头中删除“params”字段。请求参数的任何信息都不会返回。
下面是一个JSON返回结果，echoParams参数没有设置，所以默认值为explicit。请求URL包含三个参数q,wt以及indent：

{ "responseHeader": { "status": 0, "QTime": 0, "params": { "q": "solr", "indent": "true", "wt": "json", "_": "1458227751857" } }, "response": { "numFound": 0, "start": 0, "docs": [] }}

如果设置了echoParams=all，结果如下：

{ "responseHeader": { "status": 0, "QTime": 0, "params": { "q": "solr", "df": "text", "preferLocalShards": "false", "indent": "true", "echoParams": "all", "rows": "10", "wt": "json", "_": "1458228887287" } }, "response": { "numFound": 0, "start": 0, "docs": [] }}

Standard Query Parser

solr默认的查询解析器是“Lucene”解析器。
默认解析器主要的优势在于它提供了稳定的，直观的语法，从而构建各种结构的查询。最大的劣势在于和其他的解析器相比，如DisMax，不允许语法错误。

Standard Query Parser参数

除了公共查询参数，Faceting参数，高亮参数以及MoreLikeThis参数，标准查询解析器支持如下的参数。
- q：使用标准查询语法定义的查询。这个参数是必须的。
- q.op：定义查询表达式的默认操作符，覆盖了schema中提供的默认值。允许的值为“AND” 或”OR“.
- df：定义一个默认field，覆盖schema中的定义。
- sow：通过空格分解。如果设置为true，文本解析通过空格来分隔每个单独的term。默认值为false。空格分类term序列将会一次性将文档提供给分析器，触发analysis filter的方法处理这个序列，比如同义词和shingle。
参数的默认值在solrconfig.xml中配置，或者在请求中覆盖。

Standard Query Parser应答信息

默认情况下，standard query parser的返回结果只包含没有命名的信息。如果使用了debug参数，额外的命名为debug的信息将会返回。这里包含了有用的debug信息，包含query原始字符串，解析后的query字符串，以及中每个document的解析。如果explainOther参数被设置了，每个document都会附加额外的解释信息。
应答信息样例
这一节给出标准查询解析器的返回实例。
下面 的URL提供了一个简单的查询，且以XML的格式返回数据。
http://localhost:8983/solr/techproducts/select?q=id:SP2514N
结果：

<response><responseHeader><status>0</status><QTime>1</QTime></responseHeader><result numFound="1" start="0"> <doc> <arr name="cat"><str>electronics</str><str>hard drive</str></arr> <arr name="features"><str>7200RPM, 8MB cache, IDE Ultra ATA-133</str> <str>NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor</str></arr> <str name="id">SP2514N</str> <bool name="inStock">true</bool> <str name="manu">Samsung Electronics Co. Ltd.</str> <str name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</str> <int name="popularity">6</int> <float name="price">92.0</float> <str name="sku">SP2514N</str> </doc></result></response>

下面的例子限制了返回的field。
http://localhost:8983/solr/techproducts/select?q=id:SP2514N&fl=id+name
结果：

<response><responseHeader><status>0</status><QTime>2</QTime></responseHeader><result numFound="1" start="0"> <doc> <str name="id">SP2514N</str> <str name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</str> </doc></result></response>

为Standard Query Parser指定term

标准查询解析器将会查询分解成term和操作符。这里有两种term：single term和短语。
- single term是一个词，如“Test”，“hello”
- 短语是一组被双引号包裹的多个词，如“hello world”
多个term可以使用Boolean操作符合并成更加复杂的查询。
term modifier
solr提供了多种term modifier来为搜索增加灵活性和准确性。这些modifier包括通配符，模糊查询的支持字符等等。这一节详细描述modifier。
通配符搜索
solr标准查询解析器支持一个term中有单个或多个通配符。通配符可以用于单个term，但是不能用于搜索短语。

通配符搜索类型 字符 例子 单个字符 ？ te?t 匹配test和text 多个字符 * tes* 匹配test，testing，tester。也可以在中间使用。te*t匹配test，text。*est匹配pest，test。

模糊查询
solr
solr标准查询解析器支持模糊查询，算法基于Damerau-Levenshtein距离算法或者Edit距离算法。模糊查询通过相似性，而不是精确匹配来查找term。为了执行模糊查询，在单个term后使用“~”。比如，为了查询类似于“roam”的term，使用模糊插叙：
roam~
搜索结果会匹配roams，foam，&foams。当然也会匹配“roam”本身。
可以用参数控制距离最大值，参数在0-2之间取值，默认为2，比如：
roam~1
会匹配roams，foam，但是不会匹配距离为2的term，比如foams。
临近搜索
临近搜索寻找在一定距离内的匹配term。
执行临近查询，需要在短语后边添加“~”以及数字参数。比如说，为了查询“apache”以及“jakarta”，并保持距离在10以内，使用查询语句：
“jakarta apache”~10
这里涉及到的距离，是指移动term多少次可以实现短语的匹配。比如，按照上面的例子，有一个短语是“apache”+10个空格+“jakarta”组成。需要移动apache，从而保证apache在jakarta的右边，且之间只有一个空格。
范围搜索
范围搜索是指指定一个field的值在一个范围中（指定上线和下线）。在filed的值在这个范围中的时候，document才匹配此查询。范围查询可以包含或者不包含边界值。除了数值类型外，按照字典排序。比如，下边的例子popularity的值在52和10000之间：
popularity:[52 TO 10000]
范围查询不局限于时间和数值的field。你可以使用非数值的field：
title:{Aida TO Carmen}
这将会寻找title在Aida和Carmen之间，但是不包括边界值的信息。
大括号表示不包含边界值。
- 中括号[]表示包括边界值。
- 大括号表示不包括边界值。
- 大括号和中括号可以混合使用。
使用“^”加强term
Lucene/solr提供了term上的匹配等级设定。可以在搜索中使用^设定等级因子。数值越高，配皮度越高。
这可以让你通过加强term来控制document的关联度。比如，如果你正在搜索”jakarta apache”，且，希望“jakarta”具有更高关联性，那么可以为term设定加强因子，比如：
jakarta^4 apache
这会使结果和jakarta的关系更多。也可以为短语加强，比如：
“jakarta apache”^4 “Apache Lucene”
默认，加强因子是1.虽然因子必须是正值，但是可以比1小，比如0.2.
恒定分数”^=”
恒定分数查询通过^=方式设置，为每个document的匹配都制定了分数。这可以让我们只通过这个条目的匹配，而不是其他的影响因子，比如term频率或者inverse document频率。
比如：
(description:blue OR color:blue)^=1.0 text:shoes

查询特定的field

solr中的索引数据是通过Field组织的，field会在solr的schema中定义。搜索可以使用field来增加查询的精确性。比如，你可以在指定的field中查询term，比如title field。
schema定义了一个field作为默认Field。如果没有指定Field，solr只会查询默认Field。你可以指定其他Field或多个Field。
为了指定Field，在Field的名字之后加“:”，term将会在Field内查询。
比如，一个index包含两个Field：title和text。默认的Field是text。如果想查找名字叫做“The Right Way”，text包含“don’t go this way”，可以定义：
title:”The Right Way” AND text:go
title:”Do it right” AND go
由于text是默认字段，所以不需要声明Field，上面的第二个查询语句就没有指定。
Field仅仅作用于紧跟的字段，如果是title：Do it right，那么title Field只会查询Do。it和right会在默认字段查询。

标准查询解析器支持的Boolean操作

Boolean操作符使我们在查询中定义布尔逻辑。我们可以定义关注或不关注Field的term或条件查询。下面的表格详述了Boolean操作符：

Boolean 操作符 可用的字符 描述 AND && 两边的条件都需要满足 NOT ! 需要之后的term不关联 OR || 两边的条件至少一个满足 – + 需要之后的term精确匹配 – - 之后的term不在document中出现。和NOT相似。因为更接近于Google搜索引擎的语法。

所有的Boolean关键字必须大写。
DisMax只支持+，-。
默认的链接操作符为OR。这意味着如果两个term之间没有操作符，将使用OR。OR操作符链接两个term，且有一个term存在于document就满足条件。这等同于集合的union。符号|| 可以代替OR使用。
如果想搜索document包含jakarta apache或者jakarta，可以使用：
“jakarta apache” jakarta
或者
“jakarta apache” OR jakarta
Boolean操作符：+
符号+（也被称作”requiried“）表示其后的term必须存在于field中。
比如，一个查询必须包含jakarta，可能包含Lucene，可以定义为：
+jakarta Lucene
AND操作符
NOT操作符
操作符“-”
操作符-或者prohibit操作，需要document中不包含操作符后面的term。
比如，查询jakarta Apache 而不是Apache Lucene，可以定义：
“jakarta apache” -“Apache Lucene”
特殊字符替换
solr定义了以下的字符作为特殊字符：

+ - && || ! ( ) { } [ ] ^ " ~ * ? : /  

如果想在查询中不作为特殊字符，使用这些字符，需要在前面添加“\”。比如查询（1+1）：2，那么语法为：

\(1\+1\)\:2

分组条件形成子查询
Lucene/Solr支持使用括号构造子查询。对于控制Boolean的逻辑非常有用。
下面的查询搜索jakarta或apache，并包含website：

(jakarta OR apache) AND website

一个Field的条件分组
在一个Field中使用两个或更多的Boolean操作符，可以使用分组。比如：

title:(+return +"pink panther")

查询的注释

支持C风格的注释，比如：

"jakarta apache" /* this is a comment in the middle of a normal query string */ OR jakarta

Lucene查询解析器和SOlr标准查询解析器的区别

有以下几点：
- *可以用来表示无边界的查询，一边或两边都可以：
field:[* TO 100] 少于等于100
field:[100 TO *] 大于等于100
field:[* TO *] 匹配所有值
- 允许否定查询
-inStock:false 返回inStock不是false的所有结果。
-field:[* TO *] 查询所有Field没有值的document。
- FunctionQuery语法的钩子。可以使用双引号来封装方法，如下面第二个例子：
val:myfield
val:”recip(rord(myfield),1,2,3)”
- 支持查询设定解析器
inStock:true OR {!dismax qf=’name manu’ v=’ipod’}
- 支持filter（）语法，将查询子句缓存到filter cache中。这允许子查询结果被缓存和复用。比如，inStock：false将会被缓存，并在以下三个查询中复用：
q=features:songs OR filter(inStock:true)
q=+manu:Apple +filter(inStock:true)
q=+manu:Apple & fq=inStock:true
这也可以作用于单个条件缓存，如下面的例子：
q=features:songs & fq=+filter(inStock:true) +filter(price:[* TO 100])
q=manu:Apple & fq=-filter(inStock:true) -filter(price:[* TO 100])
- 范围查询，前缀匹配查询，模糊查询都包含评分。评分因子TF，IDF，index boost，coord没有起作用。
- 常量分数查询可以通过 ^=方式设定，定义了每个document整体条件的评分。
q=(description:blue color:blue)^=1.0 title:blue^=5.0
指定日期和时间
对于时间字段的查询，必须使用恰当的时间格式。时间的内容需要双引号或者转意符，来满足解析器的语法：
- createdate:1976-03-06T23:59:59.999Z
- createdate:”1976-03-06T23:59:59.999Z”
- createdate:[1976-03-06T23:59:59.999Z TO *]
- createdate:[1995-12-31T23:59:59.999Z TO 2007-03-06T00:00:00Z]
- timestamp:[* TO NOW]
- pubdate:[NOW-1YEAR/DAY TO NOW/DAY+1DAY]
- createdate:[1976-03-06T23:59:59.999Z TO 1976-03-06T23:59:59.999Z+1YEAR]
- createdate:[1976-03-06T23:59:59.999Z/YEAR TO 1976-03-06T23:59:59.999Z]