全文检索是一种将文件中所有文本与检索项匹配的文字资料检索方法，全文检索是将存储于数据库中整本书、整篇文章中的任意内容信息查找出来的检索。它可以根据需要获得全文中有关章、节、段、句、词等信息，也可以进行各种统计和分析。
全文检索易龙天网的设计师认为可以把它划分为二部分：
全文
全文顾名思义：就是全文检索的对象，它可能是一段话，也可能是一片文章，它可能是一个文件比如：word,txt也能是任意一种扩展名结尾的文件
检索
描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时根据建立的索引查找，类似于通过字典的检索字表查字的过程。
sphinx定义
Sphinx是一个基于SQL的全文检索引擎，可以结合MySQL,PostgreSQL做全文搜索，它可以提供比数据库本身更专业的搜索功能，使得应用程序更容易实现专业化的全文检索。Sphinx特别为一些脚本语言设计搜索API接口，如PHP,Python,Perl,Ruby等，同时为MySQL也设计了一个存储引擎插件。
sphinx特点
Sphinx 单一索引最大可包含1亿条记录，在1千万条记录情况下的查询速度为0.x秒(毫秒级)。Sphinx创建索引的速度为：创建100万条记录的索引只需 3～4分钟，创建1000万条记录的索引可以在50分钟内完成，而只包含最新10万条记录的增量索引，重建一次只需几十秒
这说明coreseek集合了sphinx的功能，支持更多的数据源，在字典，建立索引，分词更好的支持中文。可以这样理解，coreseek就是支持中文的sphinx全文检索
顾名思义：数据源就是为全文检索提供索引数据的源头，coreseek包括但不限制以下三种数据源
l xml
l mysql
l python
coreseek为了扩展，增加了python数据源功能，从而得以无限扩展Coreseek/Sphinx的数据获取功能因为Python目前具备操作所有类型数据库的能力，从而coreseek也可以从任意一种数据库之中获取数据;当然，也支持从Python可以操作的任意其他数据来源获取数据。
不同的数据源生成索引配置不一样，但是他们都是为生成索引提供数据的
生成词典
词库是以txt结尾的文件，而词典是以lib结尾的文件，词典是词库生成出来的，coreseek默认自带中文词库，我们也可以自定义词库信息
词典的构造：
需要用到sphinx服务命令mmseg -u unigram.txt，该命令执行后，将会在unigram.txt所在目录中产生一个名为unigram.txt.uni的文件，将该文件改名为uni.lib，完成词典的构造。需要注意的是，unigram.txt需要预先准备，并且编码格式必须为UTF-8编码。
词典文件格式：
河 187
x:187
造假者 1
x:1
台北队 1
x:1
湖边 1
第一行为词项，其格式为：[词条]\t[词频率]。特别提醒，有的编辑器会使用4到8个空格代表\t，这将导致该词条无法解析。需要注意的是，对于单个字后面跟这个字作单字成词的频率，这个频率需要在大量的预先切分好的语料库中进行统计，用户增加或删除词时，一般不需要修改这个数值;对于非单字词，词频率处必须为1。第二行为占位项，是由于LibMMSeg库的代码是从Coreseek其他的分词算法库(N-gram模型)中改造而来的，在原来的应用中，第二行为该词在各种词性下的分布频率。LibMMSeg的用户只需要简单的在第二行处填"x:1"即可。
用户可以通过修改词典文件增加自己的自定义词，以提高分词法在某一具体领域的切分精度
当我们配置好mysql数据源时候，sex字段数据将以属性字段存储在索引，而name字段将以全文检索字段存储在索引表里，生成索引需要用到词典表，当我们词库里设置的分词格式是：
小红 1
x:1
小明 1
x:1
生成的索引表为
词库分词格式我们没有特殊设置小红，小明时候：词库按照默认规则 把小 和 明 小 和 红 单字拆分生成索引
生成的索引表为：
搜索原理
还是以mysql数据源数据举例，当我们生成完索引进行搜索：
以“小明红”进行搜索时候，关键字会先根据词库拆分，默认咱们以上面第二中分词格式，拆分的得到的词为“小”，“红”，“明”，然后以拆分的词在索引表里查询数据，得到的结果是
过滤关键词
为关键词过滤一些特殊字符，通过sphinxAPI自带方法，结合字典把关键词进行分词，并且过滤一些特殊字符，过滤后在把拆分的词再拼接起来进行检索，例如：百度搜索
百度会自动把@&特殊字符过滤掉，再进行搜索，从而不影响搜索结果
设置filter
sphinx索引里的两种字段
在sphinx里有两种字段，一种可以理解为属性字段，一种可以理解为索引字段，属性字段就是以数值形式存储在索引数据里的字段，它包括不能用来索引，这种类型的字段一般都是用来设置filter、以及做排序,还有一种全文检索字段就是以字符形式存储在索引数据里，这种类型的字段一般都用来进行分词，例如文章内容，文章标题，等以字符形式存在的数据。下面就是索引里字段的介绍
id :ID属性，必须提供，在SQL语句中字段名称不限
对应SQL查询的第一个字段，系统自动使用，内部属性名为@id，不需要也不能在配置中设定
使用SetFilter()过滤，或者使用SetIDRange()过滤;
SphinxSE之中，使用filter或者minid, maxid过滤
sql_attr_uint :整数属性，以上group_id、date_added都可用此设置，使用SetFilter()过滤，
或者使用SetFilterRange()过滤;
SphinxSE之中，使用filter或者range过滤;
sql_attr_float :浮点数属性，以上score可用此设置，使用SetFilterFloatRange()进行范围过滤，
SphinxSE之中，使用range过滤;
sql_attr_timestamp:timestamp属性，整数，以上date_added可用此设置，可用SetFilter()过滤
或者使用SetFilterRange()过滤;
SphinxSE之中，使用filter或者range过滤
sql_attr_str2ordinal:字符串序列属性，以上title可用此设置，仅用于根据该字段排序
但是设置后，该属性不可用于过滤，也不会保存实际字符串内容，更不能全文检索
搜索结果中，其对应的信息为整数，由系统计算出来的排序序列值
全文检索字段 :全文检索字段，以上title、content等字符串或者文本的字段都可用此设置
任何出现在SQL语句中，既不是ID属性，也没有使用“sql_attr_类型”设置的字段，都是全文字段，
使用Query()搜索;
SphinxSE之中，使用query的查询文本进行搜索
filter
设置filter就是针对属性字段过滤，按照上面的mysql数据源表进行分析：只搜索男生数据,需要在sphinx搜索之前，过滤掉女生数据，这就需要在生成索引配置把sex字段设为索引的属性字段，这样就可以在搜索之前进行过滤，而不是在搜索之后再过滤，从而加快了sphinx搜索速度。
设置范围(limit)
相当于mysql数据库搜索时候的limit,也就是设置一个返回数据范围，当从索引搜索出来的数据为100时候，但是我只想要前10条，这就需要用到设置limit
设置权重(需要时候设置)
为字段设置权重，比如 name (char) body(text) 字段如果把这两个字段都生成索引，我们为name设置权重高，那么当我们为搜索返回的值设置排序的时候可以按照权重排序，这样两条数据，第一条数据name字段存在搜索的关键字，第二条数据body存在搜索的关键字，设置权重排序，因为我们为字段name设置权重高，排序第一条数据要优先于第二条数据
设置排序
sphinx默认提供6种排序方式，具体请查看相关资料，在这里我给大家介绍按一种类似SQL的方式将列组合起来，升序或降序排列，方式
@weight DESC,content_hit desc,@id ASC
加入“@”代表此字段是sphinx提供的字段，不加“@”代表是数据源提供的字段，上面一句代码的意思是：
先按照权重进行倒序，然后按照其他数据源提供的字段排序，这里用到的数据源字段 都是索引里的属性字段，属性字段上面已经和大家说过了。
设置搜索表达式
我们可以设置关键字在索引里每一个全文检索字段里进行查找，也可以针对某一个全文检索字段查找。例：
1、Query($keyword,$index,true);
2、Query("@name ({$keyword})",$index,true);
返回索引查询得到的ID数组
query执行后，检索完成，sphinx会为我们返回数组形式的值，值不仅包括搜索的一些相关信息，如果搜索到数据还会返回以二维数组形式存在的数据，二维数据包括 ID 对应数据源里数据的唯一标示字段(如 主键ID),以及一些索引里存储的属性字段
查询数据库
通过上面得到的二维数据，获得ID，通过它可以在数据源查询对应的相关信息
给查询出来的数据高亮显示
查询出相关信息，为相关信息中的关键字进行高亮处理
. 应用
搜索引擎
百度、谷歌等搜索引擎
随着网民对互联网的需求越来越多，网民查看新闻、信息的方式发生转变，搜索引擎的出现，改变了网民网上查看新闻、信息的浏览习惯。试想当不存在搜索引擎当不存在全文检索，我们在网上查找东西是多么费事的一件事情啊!
智能机器人
全文检索为智能化的推进提供了优秀的解决方案，智能机器人的出现在WEB，电视，手机等领域已经广泛应用。
谢谢关注websites博客！
Coreseek/sphinx全文检索的了解,布布扣,bubuko.com
原文：http://blog.csdn.net/websites/article/details/36626573
