全文索引,创建全文索引?

大家好,今天本篇文章就来给大家分享全文索引,以及创建全文索引对应的知识和见解,内容偏长哪个,大家要耐心看完哦,希望对各位有所帮助,不要忘了收藏本站喔 。
1全文索引的原理原理是先定义一个词库,然后在文章中查找每个词条(term)出现的频率和位置,把这样的频率和位置信息按照词库的顺序归纳,这样就相当于对文件建立了一个以词库为目录的索引,这样查找某个词的时候就能很快的定位到该词出现的位置 。
问题在处理英文文档的时候显然这样的方式是非常好的,因为英文自然的被空格分成若干词,只要我们有足够大的词汇库就能很好的处理 。但是亚洲文字因为没有空格作为断词标志,所以就很难判断一个词,而且人们使用的词汇在不断的变化,而维护一个可扩展的词汇库的成本是很高的,所以问题出现了 。
解决出现这样的问题使“分词”成为全文索引的关键技术 。目前有两种基本的 *** :
二元法 它把所有有可能的每两两汉字的组合看为一个词组,这样就没有维护词库的开销 。
词库法 它使使用词库中的词作为切分的标准,这样也出现了词库跟不上词汇发展的问题,除非你维护词库 。
实际上现在很多著名的搜索引擎都使用了多种分词的办法,比如“正向更大匹配”+“逆向更大匹配”,基于统计学的新词识别,自动维护词库等技术,但是显然这样的技术还没有做到完美 。
2什么是全文索引 全文检索技术全文检索,是指直接以全文本信息作为主要处理对象,并根据数据资料的内容而不是外在特征来实现的信息检索手段 。它的基本工作方式是能够将所有包含检索词的文献检索出来,不管这个词出现在文献的什么位置,或者说文献中的任意一个词都可以作为检索到该文献的条件 。
全文检索提供存取全文文本(指原始记录)的空间,文本中任何字符和字符串均可作为检索的入口点,全文检索是以原始记录中的检索词、字间的特定位置为对象的运算,对文献不作标引,故没有标引用词 。因此,全文检索是一种可以不依赖叙词表而直接使用自由词的检索 ***。

全文索引,创建全文索引?

文章插图
3MySQL的全文索引Fulltext Index | 包括ngram InnoDB的全文索引使用反向索引的设计 。反向索引存储了一个单词(word)列表,对于每个单词,都有一个文档的列表,来标识这个单词出现的地方 。为了支持临近搜索(proximity search),每个单词的位置信息也以字节偏移的方式存储 。
当创建了InnoDB全文索引,一系列的索引表会一同被创建,见下面的例子:
最前面的六个表包含了反向索引,它们被称作附属索引表(auxiliary index table) 。当输入的表被索引(tokenized)后,每个独立的单词(亦称作“tokens”)会被携带其DOC_ID和位置信息插入到索引表中 。根据单词之一个字符的字符集排序权重,在六个索引表中对单词进行完全排序和分区 。
反向索引分区到六个附属索引表以支持并行的索引创建 。默认有2个线程复制索引(Tokenize)、排序、插入单词和关联数据到索引表中 。工作的线程的数量由innodb_ft_sort_pll_degree 配置项控制的 。对于大表的全文索引,可以考虑增加线程数量 。
如果主表创建在 xx表空间,索引表存储在它们自己的表空间中 。反之,索引表存储于其索引的表空间中 。
前面例子展示的另外一种索引表被称作通用索引表,它们被用于全文索引的“删除处理(deletion handing)”和存储内部状态 。不同于为每个全文索引都各自创建的反向索引表,这组表对特定表的所有全文索引都是共用的 。
即使全文索引删掉了,通用索引(Common Index)也会被保留,当全文索引删除后,为这个索引而创建的FTS_DOC_ID列依然保留,因为移除FTS_DOC_ID列会导致重构之前被索引的表 。管理FTS_DOC_ID列需要用到通用索引表 。
为了防止大量并发读写附属表,InnoDB使用全文索引缓存去临时缓存最近的插入行 。在存满并刷入磁盘之前,缓存的内容一直存储在内存之中,可以通过查询 INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHE 表去查看最近缓存的插入行 。
缓存和批处理刷新行为避免了对辅助索引表的频繁更新,频繁更新可能会在繁忙的插入和更新期间导致并发访问问题 。批处理还避免了对同一个word的多次插入,更大化的减少了重复的条目 。相同的word会先merge再刷入到磁盘中,而不是为每个word单独插入,这样提高了插入效率并且使得索引附属表尽可能的小 。

推荐阅读