Lucene提供了方便您创建自建查询的API，也通过QueryParser提供了强大的查询语言。

本文讲述Lucene的查询语句解析器支持的语法，Lucene的查询语句解析器是使用JavaCC工

具生成的词法解析器，它将查询字串解析为Lucene Query对象。
项（Term）
一条搜索语句被拆分为一些项（term）和操作符（operator）。项有两种类型：单独项和

短语。
单独项就是一个单独的单词，例如"test" ， "hello"。
短语是一组被双引号包围的单词，例如"hello dolly"。
多个项可以用布尔操作符连接起来形成复杂的查询语句（接下来您就会看到）。
注意：Analyzer建立索引时使用的解析器和解析单独项和短语时的解析器相同，因此选择

一个不会受查询语句干扰的Analyzer非常重要。luence1.4的StandardAnalyzer的解析器已

经支持中文等亚洲国家的文字了，可以直接。标准的解析其不支持中文。

域（Field）
Lucene支持域。您可以指定在某一个域中搜索，或者就使用默认域。域名及默认域是具体

索引器实现决定的。(怎么定制默认域？)
您可以这样搜索域：域名+":"+搜索的项名。
举个例子，假设某一个Lucene索引包含两个域，title和text，text是默认域。如果您想查

找标题为"The Right Way"且含有"don't go this way"的文章，您可以输入：
title:"The Right Way" AND text:go
或者
title:"Do it right" AND right
因为text是默认域，所以这个域名可以不行。
注意：域名只对紧接于其后的项生效，所以
title:Do it right
只有"Do"属于title域。"it"和"right"仍将在默认域中搜索（这里是text域）。

项修饰符（Term Modifiers）
Lucene支持项修饰符以支持更宽范围的搜索选项。
用通配符搜索
Lucene支持单个与多个字符的通配搜索。
使用符号"?"表示单个任意字符的通配。
使用符号"*"表示多个任意字符的通配。
单个任意字符匹配的是所有可能单个字符。例如，搜索"text或者"test"，可以这样：

te?t
多个任意字符匹配的是0个及更多个可能字符。例如，搜索test, tests 或者 tester，可

以这样： test*
您也可以在字符窜中间使用多个任意字符通配符。 te*t
注意：您不能在搜索的项开始使用*或者?符号。

模糊查询
Lucene支持基于Levenshtein Distance与Edit Distance算法的模糊搜索。要使用模糊搜索

只需要在单独项的最后加上符号"~"。例如搜索拼写类似于"roam"的项这样写：
roam~
这次搜索将找到形如foam和roams的单词。
注意：使用模糊查询将自动得到增量因子（boost factor）为0.2的搜索结果.

邻近搜索(Proximity Searches)
Lucene还支持查找相隔一定距离的单词。邻近搜索是在短语最后加上符号"~"。例如在文档

中搜索相隔10个单词的"apache"和"jakarta"，这样写： "jakarta apache"~10

Boosting a Term
Lucene provides the relevance level of matching documents based on the terms

found. To boost a term use the caret, "^", symbol with a boost factor (a

number) at the end of the term you are searching. The higher the boost factor,

the more relevant the term will be.
Lucene可以设置在搜索时匹配项的相似度。在项的最后加上符号"^"紧接一个数字（增量值

），表示搜索时的相似度。增量值越高，搜索到的项相关度越好。
Boosting allows you to control the relevance of a document by boosting its

term. For example, if you are searching for jakarta apache and you want the

term "jakarta" to be more relevant boost it using the ^ symbol along with the

boost factor next to the term. You would type:
通过增量一个项可以控制搜索文档时的相关度。例如如果您要搜索jakarta apache，同时

您想让"jakarta"的相关度更加好，那么在其后加上"^"符号和增量值，也就是您输入：
jakarta^4 apache
This will make documents with the term jakarta appear more relevant. You can

also boost Phrase Terms as in the example:
这将使得生成的doucment尽可能与jakarta相关度高。您也可以增量短语，象以下这个例子

一样：
"jakarta apache"^4 "jakarta lucene"

By default, the boost factor is 1. Although, the boost factor must be positive,

it can be less than 1 (i.e. .2)
默认情况下，增量值是1。增量值也可以小于1（例如0.2），但必须是有效的。

布尔操作符
布尔操作符可将项通过逻辑操作连接起来。Lucene支持AND, "+", OR, NOT 和 "-"这些操

作符。（注意：布尔操作符必须全部大写）

OR
OR操作符是默认的连接操作符。这意味着如果两个项之间没有布尔操作符，就是使用OR操

作符。OR操作符连接两个项，意味着查找含有任意项的文档。这与集合并运算相同。符号

||可以代替符号OR。
搜索含有"jakarta apache" 或者 "jakarta"的文档，可以使用这样的查询：
"jakarta apache" jakarta 或者 "jakarta apache" OR jakarta

AND
AND操作符匹配的是两项同时出现的文档。这个与集合交操作相等。符号&&可以代替符号

AND。
搜索同时含有"jakarta apache" 与 "jakarta lucene"的文档，使用查询：
"jakarta apache" AND "jakarta lucene"

+
"+"操作符或者称为存在操作符，要求符号"+"后的项必须在文档相应的域中存在。
搜索必须含有"jakarta"，可能含有"lucene"的文档，使用查询：
+jakarta apache

NOT
NOT操作符排除那些含有NOT符号后面项的文档。这和集合的差运算相同。符号！可以代替

符号NOT。
搜索含有"jakarta apache"，但是不含有"jakarta lucene"的文档，使用查询：
"jakarta apache" NOT "jakarta lucene"
注意：NOT操作符不能单独与项使用构成查询。例如，以下的查询查不到任何结果：
NOT "jakarta apache"

-
"-"操作符或者禁止操作符排除含有"-"后面的相似项的文档。
搜索含有"jakarta apache"，但不是"jakarta lucene"，使用查询：
"jakarta apache" -"jakarta lucene"

分组（Grouping）
Lucene支持使用圆括号来组合字句形成子查询。这对于想控制查询布尔逻辑的人十分有用

。
搜索含有"jakarta"或者"apache"，同时含有"website"的文档，使用查询：
(jakarta OR apache) AND website
这样就消除了歧义，保证website必须存在，jakarta和apache中之一也存在。
转义特殊字符（Escaping Special Characters）
Lucene支持转义特殊字符，因为特殊字符是查询语法用到的。现在，特殊字符包括
+ - && || ! ( ) { } [ ] ^ " ~ * ? : \
转义特殊字符只需在字符前加上符号\,例如搜索(1+1):2，使用查询
\(1\+1\)\:2  
（李宇翻译，来自Lucene的帮助文档）上面这段看了之后很有帮助，解除了使用中的不少

疑惑，谢谢翻译者，同时应该看到，有的时候详细查看使用帮助文档是非常有用的。
------------------------------------------------------------------------------
索引文件格式

本文定义了Lucene（版本1.3）用到的索引文件的格式。
Jakarta Lucene是用Java写成的，同时有很多团体正在默默的用其他的程序语言来改写它

。如果这些新的版本想和Jakarta Lucene兼容，就需要一个与具体语言无关的Lucene索引

文件格式。本文正是试图提供一个完整的与语言无关的Jakarta Lucene 1.3索引文件格式

的规格定义。
随着Lucene不断发展，本文也应该更新。不同语言写成的Lucene实现版本应当尽力遵守文

件格式，也必须产生本文的新版本。
本文同时提供兼容性批注，描述文件格式上与前一版本不同的地方。

定义
Lucene中最基础的概念是索引（index），文档（document），域（field）和项（term）

。
索引包含了一个文档的序列。
· 文档是一些域的序列。
· 域是一些项的序列。
· 项就是一个字串。
存在于不同域中的同一个字串被认为是不同的项。因此项实际是用一对字串表示的，第一

个字串是域名，第二个是域中的字串。

倒排索引
为了使得基于项的搜索更有效率，索引中项是静态存储的。Lucene的索引属于索引方式中

的倒排索引，因为对于一个项这种索引可以列出包含它的文档。这刚好是文档与项自然联

系的倒置。

域的类型
Lucene中，域的文本可能以逐字的非倒排的方式存储在索引中。而倒排过的域称为被索引

过了。域也可能同时被存储和被索引。
域的文本可能被分解许多项目而被索引，或者就被用作一个项目而被索引。大多数的域是

被分解过的，但是有些时候某些标识符域被当做一个项目索引是很有用的。

段（Segment）
Lucene索引可能由多个子索引组成，这些子索引成为段。每一段都是完整独立的索引，能

被搜索。索引是这样作成的：
1. 为新加入的文档创建新段。
2. 合并已经存在的段。
搜索时需要涉及到多个段和/或者多个索引，每一个索引又可能由一些段组成。

文档号（Document Number）
内部的来说，Lucene用一个整形（interger）的文档号来指示文档。第一个被加入到索引

中的文档就是0号，顺序加入的文档将得到一个由前一个号码递增而来的号码。
注意文档号是可能改变的，所以在Lucene外部存储这些号码时必须小心。特别的，号码的

改变的情况如下：
· 只有段内的号码是相同的，不同段之间不同，因而在一个比段广泛的上下文环境中使用

这些号码时，就必须改变它们。标准的技术是根据每一段号码多少为每一段分配一个段号

。将段内文档号转换到段外时，加上段号。将某段外的文档号转换到段内时，根据每段中

可能的转换后号码范围来判断文档属于那一段，并减调这一段的段号。例如有两个含5个文

档的段合并，那么第一段的段号就是0，第二段段号5。第二段中的第三个文档，在段外的

号码就是8。
· 文档删除后，连续的号码就出现了间断。这可以通过合并索引来解决，段合并时删除的

文档相应也删掉了，新合并而成的段并没有号码间断。

绪论
索引段维护着以下的信息：
· 域集合。包含了索引中用到的所有的域。
· 域值存储表。每一个文档都含有一个“属性－值”对的列表，属性即为域名。这个列表

用来存储文档的一些附加信息，如标题，url或者访问数据库的一个ID。在搜索时存储域的

集合可以被返回。这个表以文档号标识。
· 项字典。这个字典含有所有文档的所有域中使用过的的项，同时含有使用过它的文档的

文档号，以及指向使用频数信息和位置信息的指针。
· 项频数信息。对于项字典中的每个项，这些信息包含含有这个项的文档的总数，以及每

个文档中使用的次数。
· 项位置信息。对于项字典中的每个项，都存有在每个文档中出现的各个位置。
· Normalization factors. For each field in each document, a value is stored

that is multiplied into the score for hits on that field. 标准化因子。对于文档

中的每一个域，存有一个值，用来以后乘以这个这个域的命中数（hits）。
· 被删除的文档信息。这是一个可选文件，用来表明那些文档已经删除了。
接下来的各部分部分详细描述这些信息。

文件的命名（File Naming）
同属于一个段的文件拥有相同的文件名，不同的扩展名。扩展名由以下讨论的各种文件格

式确定。
一般来说，一个索引存放一个目录，其所有段都存放在这个目录里，尽管我们不要求您这

样做。

基本数据类型（Primitive Types）

Byte
最基本的数据类型就是字节（byte，8位）。文件就是按字节顺序访问的。其它的一些数据

类型也定义为字节的序列，文件的格式具有字节意义上的独立性。

UInt32
32位无符号整数，由四个字节组成，高位优先。

UInt32 --> <Byte>4
Uint64
64位无符号整数，由八字节组成，高位优先。

UInt64 --> <Byte>8
VInt
可变长的正整数类型，每字节的最高位表明还剩多少字节。每字节的低七位表明整数的值

。因此单字节的值从0到127，两字节值从128到16,383，等等。

VInt 编码示例
Value
First byte
Second byte
Third byte

0
00000000
1
00000001
2
00000010
...
127
01111111
128
10000000
00000001
129
10000001
00000001
130
10000010
00000001
...
16,383
11111111
01111111
16,384
10000000
10000000
00000001
16,385
10000001
10000000
00000001
...

这种编码提供了一种在高效率解码时压缩数据的方法。

Chars
Lucene输出UNICODE字符序列，使用标准UTF-8编码。

String
Lucene输出由VINT和字符串组成的字串，VINT表示字串长，字符串紧接其后。
String --> VInt, Chars

索引包含的文件（Per-Index Files）
这部分介绍每个索引包含的文件。

Segments文件
索引中活动的段存储在Segments文件中。每个索引只能含有一个这样的文件，名

为"segments".这个文件依次列出每个段的名字和每个段的大小。
Segments --> SegCount, <SegName, SegSize>SegCount
SegCount, SegSize --> UInt32
SegName --> String
SegName表示该segment的名字，同时作为索引其他文件的前缀。
SegSize是段索引中含有的文档数。

Lock文件
有一些文件用来表示另一个进程在使用索引。
· 如果存在"commit.lock"文件，表示有进程在写"segments"文件和删除无用的段索引文

件，或者表示有进程在读"segments"文件和打开某些段的文件。在一个进程在读

取"segments"文件段信息后，还没来得及打开所有该段的文件前，这个Lock文件可以防止

另一个进程删除这些文件。
· 如果存在"index.lock"文件，表示有进程在向索引中加入文档，或者是从索引中删除文

档。这个文件防止很多文件同时修改一个索引。

Deleteable文件
名为"deletetable"的文件包含了索引不再使用的文件的名字，这些文件可能并没有被实际

的删除。这种情况只存在与Win32平台下，因为Win32下文件仍打开时并不能删除。
Deleteable --> DelableCount, <DelableName>DelableCount
DelableCount --> UInt32
DelableName --> String

段包含的文件（Per-Segment Files）
剩下的文件是每段中包含的文件，因此由后缀来区分。
域（Field）
域集合信息（Field Info）
所有域名都存储在这个文件的域集合信息中，这个文件以后缀.fnm结尾。
FieldInfos (.fnm) --> FieldsCount, <FieldName, FieldBits>FieldsCount
FieldsCount --> VInt
FieldName --> String
FieldBits --> Byte
目前情况下，FieldBits只有使用低位，对于已索引的域值为1，对未索引的域值为0。
文件中的域根据它们的次序编号。因此域0是文件中的第一个域，域1是接下来的，等等。

这个和文档号的编号方式相同。
域值存储表（Stored Fields）
域值存储表使用两个文件表示：

1. 域索引（.fdx文件）。
如下，对于每个文档这个文件包含指向域值的指针：
FieldIndex (.fdx) --> <FieldValuesPosition>SegSize
FieldValuesPosition --> Uint64
FieldValuesPosition指示的是某一文档的某域的域值在域值文件中的位置。因为域值文件

含有定长的数据信息，因而很容易随机访问。在域值文件中，文档n的域值信息就存在n*8

位置处（The position of document n's field data is the Uint64 at n*8 in this

file.）。

2. 域值（.fdt文件）。
如下，每个文档的域值信息包含：
FieldData (.fdt) --> <DocFieldData>SegSize
DocFieldData --> FieldCount, <FieldNum, Bits, Value>FieldCount
FieldCount --> VInt
FieldNum --> VInt
Bits --> Byte
Value --> String
目前情况下，Bits只有低位被使用，值为1表示域名被分解过，值为0表示未分解过。

项字典（Term Dictionary）
项字典用以下两个文件表示：
1. 项信息（.tis文件）。
TermInfoFile (.tis)--> TermCount, TermInfos
TermCount --> UInt32
TermInfos --> <TermInfo>TermCount
TermInfo --> <Term, DocFreq, FreqDelta, ProxDelta>
Term --> <PrefixLength, Suffix, FieldNum>
Suffix --> String
PrefixLength, DocFreq, FreqDelta, ProxDelta
--> VInt
项信息按项排序。项信息排序时先按项所属的域的文字顺序排序，然后按照项的字串的文

字顺序排序。
项的字前缀往往是共同的，与字的后缀组成字。PrefixLength变量就是表示与前一项相同

的前缀的字数。因此，如果前一个项的字是"bone"，后一个是"boy"的话，PrefixLength值

为2，Suffix值为"y"。

FieldNum指明了项属于的域号，而域名存储在.fdt文件中。
DocFreg表示的是含有该项的文档的数量。
FreqDelta指明了项所属TermFreq变量在.frq文件中的位置。详细的说，就是指相对于前一

个项的数据的位置偏移量（或者是0，表示文件中第一个项）。
ProxDelta指明了项所属的TermPosition变量在.prx文件中的位置。详细的说，就是指相对

于前一个项的数据的位置偏移量（或者是0，表示文件中第一个项）。

2. 项信息索引（.tii文件）。
每个项信息索引文件包含.tis文件中的128个条目，依照条目在.tis文件中的顺序。这样设

计是为了一次将索引信息读入内存能，然后使用它来随机的访问.tis文件。
这个文件的结构和.tis文件非常类似，只在每个条目记录上增加了一个变量IndexDelta。
TermInfoIndex (.tii)--> IndexTermCount, TermIndices
IndexTermCount --> UInt32
TermIndices --> <TermInfo, IndexDelta>IndexTermCount
IndexDelta --> VInt
IndexDelta表示该项的TermInfo变量值在.tis文件中的位置。详细的讲，就是指相对于前

一个条目的偏移量（或者是0，对于文件中第一个项）。

项频数（Frequencies）
.frq文件包含每一项的文档的列表，还有该项在对应文档中出现的频数。
FreqFile (.frq) --> <TermFreqs>TermCount
TermFreqs --> <TermFreq>DocFreq
TermFreq --> DocDelta, Freq?
DocDelta,Freq --> VInt
TermFreqs序列按照项来排序（依据于.tis文件中的项，即项是隐含存在的）。
TermFreq元组按照文档号升序排列。
DocDelta决定了文档号和频数。详细的说，DocDelta/2表示相对于前一文档号的偏移量（

或者是0，表示这是TermFreqs里面的第一项）。当DocDelta是奇数时表示在该文档中频数

为1，当DocDelta是偶数时，另一个VInt（Freq）就表示在该文档中出现的频数。
例如，假设某一项在文档7中出现一次，在文档11中出现了3次，在TermFreqs中就存在如下

的VInts序列： 15, 22, 3

项位置（Position）
.prx文件包含了某文档中某项出现的位置信息的列表。
ProxFile (.prx) --> <TermPositions>TermCount
TermPositions --> <Positions>DocFreq
Positions --> <PositionDelta>Freq
PositionDelta --> VInt
TermPositions按照项来排序（依据于.tis文件中的项，即项是隐含存在的）。
Positions元组按照文档号升序排列。
PositionDelta是相对于前一个出现位置的偏移位置（或者为0，表示这是第一次在这个文

档中出现）。
例如，假设某一项在某文档第4项出现，在另一个文档中第5项和第9项出现，将存在如下的

VInt序列： 4, 5, 4

标准化因子（Normalization Factor）
.nrm文件包含了每个文档的标准化因子，标准化因子用来以后乘以这个这个域的命中数。
Norms (.nrm) --> <Byte>SegSize
每个字节记录一个浮点数。位0-2包含了3位的尾数部分，位3-8包含了5位的指数部分。
按如下规则可将这些字节转换为IEEE标准单精度浮点数：
1. 如果该字节是0，就是浮点0；
2. 否则，设置新浮点数的标志位为0；
3. 将字节中的指数加上48后作为新的浮点数的指数；
4. 将字节中的尾数映射到新浮点数尾数的高3位；并且
5. 设置新浮点数尾数的低21位为0。

被删除的文档（Deleted Document）
.del文件是可选的，只有在某段中存在删除操作后才存在：
Deletions (.del) --> ByteCount,BitCount,Bits
ByteSize,BitCount --> Uint32
Bits --> <Byte>ByteCount
ByteCount表示的是Bits列表中Byte的数量。典型的，它等于（SegSize/8）+1。
BitCount表示Bits列表中多少个已经被设置过了。
Bits列表包含了一些位（bit），顺序表示一个文档。当对应于文档号的位被设置了，就标

志着这个文档已经被删除了。位的顺序是从低到高。因此，如果Bits包含两个字节，0x00

和0x02，那么表示文档9已经删除了。

局限性（Limitations）
在以上的文件格式中，好几处都有限制项和文档的最大个数为32位数的极限，即接近于40

亿。今天看来，这不会造成问题，但是，长远的看，可能造成问题。因此，这些极限应该

或者换为UInt64类型的值，或者更好的，换为VInt类型的值（VInt值没有上限）。
有两处地方的代码要求必须是定长的值，他们是：
1. FieldValuesPosition变量（存储于域索引文件中，.fdx文件）。它已经是一个UInt64

型，所以不会有问题。
2. TermCount变量（存储于项信息文件中，.tis文件）。这是最后输出到文件中的，但是

最先被读取，因此是存储于文件的最前端 。索引代码先在这里写入一个0值，然后在其他

文件输出完毕后覆盖这个值。所以无论它存储在什么地方，它都必须是一个定长的值，它

应该被变成UInt64型。
除此之外，所有的UInt值都可以换成VInt型以去掉限制
------------------------------------------------------------------------------

---------
下面是lucene组成结构中的类说明：
org.apache.Lucene.search/ 搜索入口
org.apache.Lucene.index/ 索引入口
org.apache.Lucene.analysis/ 语言分析器
org.apache.Lucene.queryParser/ 查询分析器
org.apache.Lucene.document/ 存储结构
org.apache.Lucene.store/  底层IO/存储结构
org.apache.Lucene.util/ 一些公用的数据结构

域存储字段规则
方法 切词 索引 存储 用途
Field.Text(String name, String value) 切分词索引并存储，比如：标题，内容字段
Field.Text(String name, Reader value)  切分词索引不存储，比如：META信息，
不用于返回显示，但需要进行检索内容
Field.Keyword(String name, String value)  不切分索引并存储，比如：日期字段
Field.UnIndexed(String name, String value)  不索引，只存储，比如：文件路径
Field.UnStored(String name, String value)  只全文索引，不存储

建立索引的例子：
public class IndexFiles {  
//使用方法：: IndexFiles [索引输出目录] [索引的文件列表] ...  
public static void main(String[] args) throws Exception {   
String indexPath = args[0];    IndexWriter writer;   
//用指定的语言分析器构造一个新的写索引器（第3个参数表示是否为追加索引）   

writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);   
for (int i=1; i<args.length; i++) {     
System.out.println("Indexing file " + args[i]);     
InputStream is = new FileInputStream(args[i]);     
//构造包含2个字段Field的Document对象     
//一个是路径path字段，不索引，只存储     
//一个是内容body字段，进行全文索引，并存储     
Document doc = new Document();     
doc.add(Field.UnIndexed("path", args[i]));     
doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));     
//将文档写入索引    
 writer.addDocument(doc);     
is.close();    };   
//关闭写索引器   
writer.close();  }
}
索引过程中可以看到：

语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的，虽然lucene缺省

提供了2个比较通用的分析器SimpleAnalyser和StandardAnalyser，这2个分析器缺省都不

支持中文，所以要加入对中文语言的切分规则，需要修改这2个分析器。
Lucene并没有规定数据源的格式，而只提供了一个通用的结构（Document对象）来接受索

引的输入，因此输入的数据源可以是：数据库，WORD文档，PDF文档，HTML文档……只要能

够设计相应的解析转换器将数据源构造成成Docuement对象即可进行索引。
对于大批量的数据索引，还可以通过调整IndexerWrite的文件合并频率属性（mergeFactor

）来提高批量索引的效率。
检索过程和结果显示：

搜索结果返回的是Hits对象，可以通过它再访问Document==>Field中的内容。

假设根据body字段进行全文检索，可以将查询结果的path字段和相应查询的匹配度(score)

打印出来，

public class Search {  
public static void main(String[] args) throws Exception {   
String indexPath = args[0], queryString = args[1];   
//指向索引目录的搜索器   
Searcher searcher = new IndexSearcher(indexPath);   
//查询解析器：使用和索引同样的语言分析器   
Query query = QueryParser.parse(queryString, "body",                           

   new SimpleAnalyzer());   
//搜索结果使用Hits存储   
Hits hits = searcher.search(query);   
//通过hits可以访问到相应字段的数据和查询的匹配度   
for (int i=0; i<hits.length(); i++) {     
System.out.println(hits.doc(i).get("path") + "; Score: " +                     

    hits.score(i));    };  }
}
添加修改删除指定记录（Document）

Lucene提供了索引的扩展机制，因此索引的动态扩展应该是没有问题的，而指定记录的修

改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法

也很简单，只是需要在索引时根据数据源中的记录ID专门另建索引，然后利用

IndexReader.delete(Termterm)方法通过这个记录ID删除相应的Document。

根据某个字段值的排序功能
根据某个字段值的排序功能

lucene缺省是按照自己的相关度算法（score）进行结果排序的，但能够根据其他字段进行

结果排序是一个在LUCENE的开发邮件列表中经常提到的问题，很多原先基于数据库应用都

需要除了基于匹配度（score）以外的排序功能。而从全文检索的原理我们可以了解到，任

何不基于索引的搜索过程效率都会导致效率非常的低，如果基于其他字段的排序需要在搜

索过程中访问存储字段，速度回大大降低，因此非常是不可取的。

但这里也有一个折中的解决方法：在搜索过程中能够影响排序结果的只有索引中已经存储

的docID和score这2个参数，所以，基于score以外的排序，其实可以通过将数据源预先排

好序，然后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行

排序和在搜索过程中访问不在索引中的某个字段值。

这里需要修改的是IndexSearcher中的HitCollector过程：

...　scorer.score(new HitCollector() { 
private float minScore = 0.0f; 
public final void collect(int doc, float score) {  
if (score > 0.0f &&     // ignore zeroed buckets      

(bits==null || bits.get(doc))) {   // skip docs not in bits    

totalHits[0]++;     if (score >= minScore) {              /* 原先：Lucene将

docID和相应的匹配度score例入结果命中列表中：        * hq.put(new ScoreDoc

(doc, score));   // update hit queue               * 如果用doc 或 1/doc 代替

score，就实现了根据docID顺排或逆排               * 假设数据源索引时已经按照某个

字段排好了序，而结果根据docID排序也就实现了               * 针对某个字段的排序

，甚至可以实现更复杂的score和docID的拟合。               */             

hq.put(new ScoreDoc(doc, (float) 1/doc ));       
if (hq.size() > nDocs) {    // if hit queue overfull  

hq.pop();     // remove lowest in hit queue  

minScore = ((ScoreDoc)hq.top()).score; // reset minScore       }     } 

  } }      }, reader.maxDoc());

Lucene面向全文检索的优化在于首次索引检索后，并不把所有的记录（Document）具体内

容读取出来，而起只将所有结果中匹配度最高的头100条结果（TopDocs）的ID放到结果集

缓存中并返回，这里可以比较一下数据库检索：如果是一个10,000条的数据库检索结果集

，数据库是一定要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索

匹配总数很多，Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应用是

用不到这么多的结果的，头100条已经可以满足90%以上的检索需求。

如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次

的搜索缓存数大1倍的缓存，并再重新向后抓取。所以如果构造一个Searcher去查1－120条

结果，Searcher其实是进行了2次搜索过程：头100条取完后，缓存结果用完，Searcher重

新检索再构造一个200条的结果缓存，依此类推，400条缓存，800条缓存。由于每次

Searcher对象消失后，这些缓存也访问那不到了，你有可能想将结果记录缓存下来，缓存

数尽量保证在100以下以充分利用首次的结果缓存，不让Lucene浪费多次检索，而且可以分

级进行结果缓存。

Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和

数据库应用需要将搜索的结果全部返回不同之处。