❶ lucene完全匹配放置首位的问题
可是我用IK分词器搜索的时候，就是完全匹配的在前面啊，你使用的是哪个Query对象？
还有 StandardAnalyzer切分中文时 ，你输入的是王小平，他会切分成”王 小 平“三个字，所以不管是”王小平33066“还是”王大小平“ 都是100%匹配的，我觉得主要还是分词的原因
❷ 倒排索引在lucene中的应用
全文检索是信息检索技术的一种，主要是把用户的查询请求和全文中的每一个词进行比较，不考虑查询请求与文本语义上的匹配。在信息检索工具中，全文检索是最具通用性和实用性的。Lucene是apache软件基金会4 jakarta项目组的一个子项目，是一个开源的全文检索引擎工具包，基于倒排文件索引结构来实现检索功能。
什么是倒排索引？与正排索引有什么区别呢？
正排表是以文档的ID为关键字，表中记录文档中每个字的位置信息，查找时扫描表中每个文档中字的信息直到找出所有包含查询关键字的文档。
正排表结构如图所示，这种组织方法在建立索引的时候结构比较简单，建立比较方便且易于维护;因为索引是基于文档建立的，若是有新的文档加入，直接为该文档建立一个新的索引块，挂接在原来索引文件的后面。若是有文档删除，则直接找到该文档号文档对应的索引信息，将其直接删除。但是在查询的时候需对所有的文档进行扫描以确保没有遗漏，这样就使得检索时间大大延长，检索效率低下。
倒排表以字或词为关键字进行索引，表中关键字所对应的记录表项记录了出现这个字或词的所有文档，一个表项就是一个字表段，它记录该文档的ID和字符在该文档中出现的位置情况。
由于每个字或词对应的文档数量在动态变化，所以倒排表的建立和维护都较为复杂，但是在查询的时候由于可以一次得到查询关键字所对应的所有文档，所以效率高于正排表。在全文检索中，检索的快速响应是一个最为关键的性能，而索引建立由于在后台进行，尽管效率相对低一些，但不会影响整个搜索引擎的效率。
倒排表的结构图如图所示：
Lucene经多年演进优化，现在的一个索引文件结构如图所示，基本可以分为三个部分：词典、倒排表、正向文件、列式存储DocValues。
倒排索引中的词典位于内存，其结构尤为重要，有很多种词典结构，各有各的优缺点，最简单如排序数组，通过二分查找来检索数据，更快的有哈希表，磁盘查找有B树、B+树，但一个能支持TB级数据的倒排索引结构需要在时间和空间上有个平衡，下图列了一些常见词典的优缺点：
Lucene3.0之前使用的也是跳跃表结构，后换成了FST，但跳跃表在Lucene其他地方还有应用如倒排表合并和文档号索引。
Lucene现在采用的数据结构为FST，它的特点就是：
1、词查找复杂度为O(len(str))
2、共享前缀、节省空间
3、内存存放前缀索引、磁盘存放后缀词块
这跟我们前面说到的词典结构三要素是一致的：1. 查询速度。2. 内存占用。3. 内存+磁盘结合。
已知FST要求输入有序，所以Lucene会将解析出来的文档单词预先排序，然后构建FST，我们假设输入为abd,abd,acf,acg，那么整个构建过程如下：
生成的FST：
100万数据性能测试
可以看出，FST性能基本跟HaspMap差距不大，但FST有个不可比拟的优势就是占用内存小，只有HashMap10分之一左右，这对大数据规模检索是至关重要的，毕竟速度再快放不进内存也是没用的。
倒排表就是文档号集合，但怎么存，怎么取也有很多讲究，Lucene现使用的倒排表结构叫Frame of reference,它主要有两个特点：
1. 数据压缩，可以看下图怎么将6个数字从原先的24bytes压缩到7bytes。
假设现在有两篇文章：
文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too
文章2的内容为：He once lived in Shanghai.
倒排索引建立过程如下：
（1）取得关键词
由于lucene是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施：
a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理(注：中文分词比英文分词更加复杂，如：“帽子和服装”、“中华人民共和国”等，有兴趣可以单独研究)。
b.文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉
c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。
d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”
e.文章中的标点符号通常不表示某种概念，也可以过滤掉
在lucene中以上措施由Analyzer类完成。 经过上面处理后，
文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou]
文章2的所有关键词为：[he] [live] [shanghai]
（2）建立倒排索引
有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成: “关键词”对“拥有该关键词的所有文章号”。
文章1，2经过倒排后变成
通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：
a.字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；
b.关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。
加上“出现频率”和“出现位置”信息后，我们的索引结构变为：
（3）检索过程
lucene的检索过程分为以下几个步骤：
1. 内存加载tip文件，通过FST匹配前缀找到后缀词块位置。
2. 根据词块位置，读取磁盘中tim文件中后缀块并找到后缀和相应的倒排表位置信息。
3. 根据倒排表位置去doc文件中加载倒排表。
（4）检索结果
如果此时检索“tom live”，那么只需要检索包含[tom]和[live]这两个词的文档
可以看到，两个词都在文档1中出现，且词频更高. 而文档2只被live命中一次。因此，检索结果中文档1的相关度更高。lucene默认使用TF/IDF算法来计算文档的相关度。
❸ 什么是检索在Lucene的查询中所有匹配文档的最有效方法，未排序
关键词:信息检索模型;相关性;查询;搜索引擎中图分类号:TP391 文献标识码:A 文章编号:1007-9599 (2010) 05-0000-02Comparision on Information Retrieva ModelsSong Yawei,Xiao Cheng(Jiangsu Provincial Communications Planning and Design Institute Co.,LTD,Nanjing 210005,China)Abstract:This article described the main contents and the construction strategy of the models of information retrieval,demonstrated a lot of methods in common usages,which is to calculate the model of information retrieval.And in this article,the advantages and disadvantages were analyzed,the problems that is still existing have been researched.In addition,the current situation of this research and the development tendency of the model of information retrieval were deeply summarizad in this article.Keywords:Information retrieval models;Relativity;Inquiry;Search engine当前，随着互联网的普及和网上信息的爆炸式增长，信息检索系统及其核心技术搜索引擎的性能和效率问题已成为人们研究和关注的焦点。影响一个搜索引擎系统的性能有很多因素，但最主要的是信息检索模型，其研究内容包括文档和查询的表示方法、评价文档和用户查询相关性的匹配策略、查询结果的排序方法和用户进行相关度反馈的机制。本文从研究文档与用户查询“相关性”匹配的角度出发，对信息检索模型研究的主要内容和构建策略进行了详细的描述，并给出了几种常用的信息检索模型相关性算法，分析了它们的优缺点及存在的问题，总结了当前信息检索模型的研究现状和发展趋势，其目的在于提高信息检索、查询的性能和效率。一、构建信息检索模型的策略当前，构建信息检索模型的主要策略有以下两个:(一)通用的信息检索模型构建一个通用的信息检索模型，研究优化的匹配算法，提高查询速度、查全率和查准率，最大程度地满足一般用户的查询需求。(二)用户兴趣模型根据特定用户查询兴趣要求构建用户兴趣模型或共同兴趣模型，能够尽可能地满足特殊用户查询的需求。它可以构建一个适合行业或专业应用语义要求信息获取模型。如google就能推断用户的使用意图，提供动态的、即时的用户“个性化定制”信息，帮助用户快速、准确地定位到所需要的信息。二、常用的信息检索相关性算法(一)布尔模型布尔模型是基于特征项的严格匹配模型，文本查询的匹配规则遵循布尔运算的法则。用户可以根据检索项在文档中的布尔逻辑关系提交查询，搜索引擎则根据事先建立的倒排文件结构，确定查询结果。标准的布尔逻辑模型为二元逻辑，所搜索的文档要么与查询相关，要么与查询无关。查询结果一般不进行相关性排序。在布尔模型中，一个文档通过一个关键词条的集合来表示，这些词条都来自一个词典。在查询与文档匹配的过程中，主要看该文档中的词条是否满足查询条件。布尔模型用文档的检索状态值作为一种评价查询和文档相似性的一种方法。这里，首先定义关键词集合S，关键词为t1，t2，…，tn。这些关键词可以和逻辑操作符AND，OR和NOT形成不同的条件查询。如果得到条件表达式的值为True，该文档相对于此条查询的检索状态值为1;如果若干文档相对于此条查询的检索状态值都为1，则可以认为，这些文档与此用户的查询是相关的。布尔模型的主要优点有两点:一是实现起来比较容易，速度快，计算的代价相对较少。二是查询语言表达简单，用户可以使用任意复杂的查询表达式，易于表示同义关系(如:聋教育OR特殊教育)和词组(如:计算机AND基础AND课程改革)。它的缺点是，由于所有检索到的与用户查询条件相关的文档具有相同的检索状态值，则不能对查询结果按照相关性进行排序;另外关键词也没有考虑权重的影响，缺乏定量分析和灵活性以及不能表述模糊匹配。而为了克服布尔型信息获取模型查询结果的无序性，在查询结果处理中引进了模糊逻辑运算，将所检索的数据库文档信息与用户的查询要求进行模糊逻辑比较，按照相关的优先次序排列查询结果。(二)向量空间模型向量空间模型把信息库中的文本以及用户的查询都表示成向量空间中的点(向量)，用它们之间夹角的余弦作为相似性度量。向量空间模型是现在的文本检索系统以及网络搜索引擎的基础。在向量空间模型中，信息检索系统如果涉及n个关键词Term，则建立n维的向量空间，每一维都代表不同的关键词Term。首先要建立文本和用户查询的向量，一个n元组的文档向量Di的每个坐标都通过对应关键字的权重来表示，查询向量中的权重表示对应关键词对于用户来说的重要程度。然后进行查询向量和文本向量的相似性计算。并可以在匹配结果的基础上进行相关反馈，优化用户的查询。在知道了文档向量与查询向量后，查询与文档的相似性就可以通过公式(2)求解。 (2)在公式(2)中，文档Di可以用n维的向量表示，其中每个分量表示某一Term在整篇文档中的权重。Q = (q1，q2，…，qn)中ql表示Terml在Q中的权重。向量空间模型的优点在于:1.检索词加权改进了检索效果。2.部分匹配策略允许检索出与查询条件相近的文献。3.可以根据相似度对文献进行排序。它的缺点是，在这种模型中的基本假设，关键词Term向量之间被假设为相互无关的，而实际是有时它们之间大多是依赖关系，如在自然语言中，词或短语之间存在着十分密切的联系。所以这一假设对计算结果的可靠性造成一定的影响。另外，在查询中，也不能像布尔模型一样使用关键词之间的逻辑运算关系。(三)概率模型概率模型主要是基于概率排序原则:即如果文档按照与查询的概率相关性的大小排序，那么排在最前面的是最有可能被获取的文档。它主要针对信息检索中相关性判断的不确定性以及查询信息表示的模糊性。在前面的向量模型中，我们假定关键词Term向量是正交的，不考虑Term向量之间的依赖关系。而在概率模型中，可以通过概率计算表达关键词Term之间，以及关键词Term和文档之间的依赖关系，预测文档与用户查询的相关概率，并可以对获取的结果按照相关度概率的大小进行排序(简称PRP)。概率模型有两个主要的参数:一个文档和用户查询的相关概率Pr(rel)及不相关概率Pr(nonrel)，并且Pr(rel)=1-Pr(nonrel)。即Pr[term t in documentdocument is relevant]=Rt/R (3)Pr[term t in document document is irrelevant]= (ft-Rt)/(N- Rt) (4)其中:R表示与用户查询相关的文档数;Rt表示在相关R中出现关键词Term t的文档数;N表示文档数;ft表示在N个文档中出现关键词Term t的文档数。由式(3)和(4)，可以得到:Pr[term t is not in document document is relevant]= (R- Rt)/R (5)Pr[term t is not in document document is irrelevant]=(N-ft-(R- Rt))/(N- Rt) (6)根据上面所给的“条件概率”，可以计算出关键词Term t的权重: (7)在公式(7)中，如果wt>0，表明词Term t出现的文档与用户查询相关;如果wt<0，出现Term t的文档与用户查询无关。概率模型的主要缺点是对文本集的依赖性过强，而且条件概率值很难估计。概率模型的一个特例是贝叶斯网络，该网络以概率的方式定义了关键词的权重随着与其相关的关键词的权重的改变而改变方式。由于该模型适用于超文本信息系统，因而该模型的应用越来越广泛。但是该模型的缺点是，计算复杂度很大，因而该模型不适合很大的网络。三、结束语目前，大多数信息检索模型都依赖于布尔模型，而在实验环境中用的最多并居于主导地位的是传统的向量空间模型。信息检索模型还有许多其他变种，如基于布尔模型的变种有:模糊集合模型、扩展布尔模型;基于矢量空间模型的变种有:通用矢量空间模型、潜在语义索引模型、神经网络模型;基于概率模型的变种有:推理网模型、可信网模型。而总体上来看，这些模型及其变种都是“语法”层次的信息检索模型，没有具有“语义”特征的规范的词汇集。
❹ 为什么说Lucene不好
在Lingway公司，我们使用了Lucene至进今已有好几年时间。对那些刚接触Lucene的人来说，这里是使用它的关键：Apache Lucene是一个由java编写的高性能，全方位的单词搜索引擎库。
在批评它之前，我必须承认Lucene是一个高性能的划词搜索引擎。几年来，Lucene已经被看作是用java编写的嵌入式搜索引擎中的一等公民。它的声誉每日剧增，并且仍然是开源java搜索引擎中的最佳。每个人都在说：“Doug Cutting做了一项伟大的工作”。然而，最近的几个月内，开发的进程变得缓慢，我认为Lucene将不会满足现代的文档处理需求。不要把东西搞糟：我不是搜索引擎开发者，我只是个开发者，使用搜索引擎，来提供合适信息的检索科技。
Lucene不是最好选择，至少对我们而言如此，并且情况并没有得到改变。我们列出Lucene的局限性：Lingway公司基于语意来生成复杂的查询。例如当你正在查找关于“中东地区冲突”的文章，你也许还需要找关于“伊拉克战争”文章。在上面这个用例中，“战争”和“伊拉克”分别是“冲突”和“中东”的扩展。我们使用一种技术能分析你的查询，产生相应的最合适的扩展，为它们生成查询。然而，为了得到相关的结果，这些还是不够的：通过Lucene实现的类似Google的等级或是经常变化积分的并不能满足语意级别积分。例如，一个包含“中”和“东”短语，但是被超过一个以上的单词隔开，这种情况并不是我们想要查找的。更重要的是，相对常规的单词，我们应该给扩展更低的分数。比如，我们应该给“中东地区冲突”这个短语更高的分数，而不是“伊拉克战争”。
在Lingway公司，我们认为这种文章相关性技术是一种未来的搜索引擎。Google在文章搜索上做的很出色。但我们想要的却是最相关的文章。但是，大部分的当代搜索引擎都没有对这样复杂查询做相关的设计…Lucene被wikipedia使用，如果你注意到当你查询查过一个单词时，大多数的查询结果并不是由关联的…
为了演示需求，这里有一个Lingway公司即将上线的KM3.7产品的界面截图。这里我们用法语写一个查询，用来查找那些同样主题，而用英语写的文章。注意，这可不仅仅是简简单单的翻译，我们称之为语言交叉模式：
注意到那些绿色的匹配:chanteur变成了singer,但是我们也发现singing被匹配了。同样情况流行乐成为蓝调的扩展。
6大理由不选用Lucene
6. 没有对集群的内置支持。
如果你创建集群，你可以写出自己对Directory的实现，或是使用Solr或者使用Nutch+Hadoop。Solr和Nutch都支持Lucene，但不是直接的替代。Lucene是可嵌入的，而你必须支持Solr和Nutch..我认为Hadoop从Lucene团队中产生并不惊讶:Lucene并不是通用的。它的内在性决定了对大多数场合来说它是非常快速的，但是对大型文档集合时,你不得不排除Lucene。因为它在内核级别上并没有实现集群，你必须把Lucene转换到别的搜索引擎，这样做并不直接。转换到Solr或者Nutch上的问题会让你遇到许多不必要的麻烦:Nutch中的集成crawling和Solr中的检索服务。
5.跨度查询太慢
这对Lingway公司来说可能是个特殊的问题。我们对跨度查询有很强要求,Lucene检索结构已经开始添加这一细节，但它们当初可没这么想。最基础的实现导致了复杂的算法并且运行缓慢，尤其是当某些短语在一份文档中重复了许多次出现。这是为什么我倾向说Lucene是一个高性能的划词检索引擎当你仅仅使用基本的布尔查询时。
4.积分不能被插件化
Lucene有自己对积分算法的实现,当条件增加时使用Similarity类。但很快它显示出局限性当你想要表示复杂的积分,例如基于实际匹配和元数据的查询。如果你这样做，你不得不继承Lucene的查询类。因为Lucene使用类似tf/idf的积分算法，然而在我们遇到的场合，在语意上的积分上Lucene的积分机制并不合适。我们被迫重写每一个Lucene的查询类使得它支持我们自定义的积分。这是一个问题。
3.Lucene并非良好设计
作为一个系统架构师，我倾向认为(1)Lucene有一个非常糟糕的OO设计。虽然有包，有类的设计，但是它几乎没有任何设计模式。这让我想起一个由C(++)开发者的行为，并且他把坏习惯带到了java中。这造成了，当你需要自定义Lucene来满足你的需求(你将来必定会遇到这样的需求)，你必须面对这样的问题。例如：
<!--[if !supportLists]--> <!--[endif]-->几乎没有使用接口。查询类（例如BooleanQuery,SpanQuery,TermQuery…）都是一个抽象类的子类。如果你要添加其中的一个细节，你会首先想到写一个接口来描述你扩展的契约，但是抽象的Query类并没有实现接口，你必须经常的变化自己的查询对象到Query中并在本地Lucene中调用。成堆的例子如(HitCollecor,…)这对使用AOP和自动代理来说也是一个问题.
<!--[if !supportLists]--> <!--[endif]-->别扭的迭代实现.没有hasNext()方法,next()方法返回布尔类型并刷新对象内容.这对你想要保持对迭代的元素跟踪来说非常的痛苦.我假定这是故意用来节省内存但是它又一次导致了算法上的杂乱和复杂.
2.一个关闭的API使得继承Lucene成为痛苦
在Lucene的世界中,它被称之为特性。当某些用户需要得到某些细节，方针是开放类。这导致了大多数的类都是包保护级别的，这意味着你不能够继承他们（除非在你创建的类似在同一个包下，这样做会污染客户代码）或者你不得不复制和重写代码。更重要的是，如同上面一点提到的，这个严重缺乏OO设计的结构，一些类应该被设为内部类却没有，匿名类被用作复杂的计算当你需要重写他们的行为。关闭API的理由是让代码在发布前变得整洁并且稳定。虽然想法很光荣，但它再一次让人感到痛苦。因为如果你有一些代码和Lucene的主要思路并不吻合，你不得不经常回归Lucene的改进到你自己的版本直到你的补丁被接受。
然而当开发者开始越来越长的限制API的更改，你的补丁很少有机会被接受。在一些类和方法上加上final修饰符会让你遇到问题。我认为如果Spring框架有这样的限制，是觉不会流行起来。
<!--[if !supportLists]-->1. Lucene搜索算法不适合网格计算<!--[endif]-->
Lucene被写出来的时候硬件还没有很大的内存，多处理器也不存在。因此，索引结构是被设计成使用线性的内存开销很小的方式。我花了很长的时间来重写跨度查询算法，并使用多线程内容（使用双核处理器），但是基于迭代器的目录读取算法几乎不能实现。在一些罕见的场合你能做一些优化并能迭代一个索引通过并行方式，但是大多数场合这是不可能的。我们遇到的情况是，当我们有一个复杂的，超过50+的内嵌跨度查询，CPU还在空闲但I/O却一直忙�担踔猎谑褂昧荙AMDirectory.
有没有替代品？
我认为最后一个观点充满疑问:Lucene到达了它的极限当它在现在硬件基础的条件下，检索大型数据集合时。那就是我为什么寻找下一个可以替代Lucene的出现。在阅读了博客目录和 Wikia的讨论后，我发现并没有很多的替代品。然而我最后推荐一个有希望的方案：MG4J。它有一个良好的面向对象设计，性能良好的检索（索引比Lucene慢），内存开销上也很小，达到10倍于Lucene速度的跨度查询，在我的跨度查询基准上，并且是原生上支持集群。同样它也内置了负载平衡，而Lucene最近才加入这项功能并且还是实验性质的。然而MG4J仍然缺少一些特性例如简单的索引指数，文档移除和更简单的使用索引处理。让我感到高兴的是我可以自定义Lucene上的功能在MG4J上只需花几个小时，而在Lucene上却需要数天。
我认为对开源的搜索引擎来说仍然有发展空间，它不是通过单台电脑用有限的内存来索引批量文档，而是通过透明的分布式索引来提供对大型数据集合检索更为快捷的答案。你不必利用应用来获得集群特性。Lucene对第一类搜索引擎有了很好的实现，单我认为它并不符合我们的需求：在一个合理的时间内找到最佳的答案。基于tf/idf的搜索算法和google的等级并不是未来搜索引擎的趋势。实现对原数据和语义的复杂查询并找出相关的信息，这是Lingway公司(通过Lucene和其他搜索引擎技术)所作的，不过它要求有更多支持新硬件的新技术。
使用Lucene的一个好理由
无论我如何指责Lucene,它仍然是java开源解决方案中的最佳实现。
❺ lucene的底层数据结构
lucene是很有深度的，特别是文件存储、读取、排序部分。需要一定的编程经验。没有经验的话，最好不要去硬钻。
要明白文本是以何种形式存储在磁盘上，为什么要这样存储，以及如何读取出来，如何算分，如何排序。
❻ lucene 功能强大吗相比百度谷歌差多远
一点都不难，我们毕业设计就用lucene做的，写一个简单的搜索引擎，几百行代码就成了。占多大内存影响因素很多：1、你存储lucene索引位置（硬盘还是内存），2、你程序写的好不好，3你要索引站内文件还是这个互联网的，至于第三个问题，你自己想想看，人家网络和google是专门有公司运营的，当然比你一个人写的强大多了，在一个问题就是lucene只是一个工具包，不能和网络，google比的
❼ lucene按匹配度排序是怎么做到的
Lucene的搜索结果默认按相关度排序，这个相关度排序是基于内部的Score和DocID，Score又基于关键词的内部评分和做索引时的boost。默认Score高的排前面，如果Score一样，再按索引顺序，先索引的排前面。那么有人问了，如果我要先索引的排后面怎么办呢？隐士研究了源码后发现这是相当简单的事情。以下代码基于Lucene 2.0。
看Sort的默认构造函数，相关度就是SortField.FIELD_SCORE和SortField.FIELD_DOC的组合。
java 代码
/**
* Sorts by computed relevance. This is the same sort criteria as calling
* {@link Searcher#search(Query) Searcher#search()}without a sort criteria,
* only with slightly more overhead.
*/
public Sort() {
this(new SortField[] { SortField.FIELD_SCORE, SortField.FIELD_DOC });
}
那么该如何构造我们需要的SortField呢？请看SortField的一个构造函数，有一个参数reverse可供我们调整结果集的顺序。
java 代码
/** Creates a sort, possibly in reverse, by terms in the given field with the
* type of term values explicitly given.
* @param field Name of field to sort by. Can be <code>null</code> if
* <code>type</code> is SCORE or DOC.
* @param type Type of values in the terms.
* @param reverse True if natural order should be reversed.
*/
public SortField (String field, int type, boolean reverse) {
this.field = (field != null) ? field.intern() : field;
this.type = type;
this.reverse = reverse;
}
由此可见，只要构造一个SortField[]就可以实现我们要的功能，请看：
java 代码
// 评分降序，评分一样时后索引的排前面
new SortField[] { SortField.FIELD_SCORE, new SortField(null, SortField.DOC, true) }
// 评分升序，评分一样时后索引的排前面，呵呵，此为最不相关的排前面，挺有趣的
new SortField[] { new SortField(null, SortField.SCORE, true), new SortField(null, SortField.DOC, true) }
呵呵，只要将此SortField[]作为参数传入Sort的构造函数得到Sort的一个instance，将此instance传入searcher.search(query, sort)即可得到了期望的结果。
❽ 用Lucene searchafter分页，怎样排序
TopFieldDocs tds = searcher.search(query, num, sort);
return (FieldDoc) tds.scoreDocs[num - 1];
在获取上一页最后一个ScoreDoc方法中，也需要将sort传入。 TopDocs tds = searcher.search(query, num, sort); return tds.scoreDocs[num - 1];