本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
很多人还是停留在会写代码的行列，例如做一个搜索功能，往往使用 SQL 中的 like 语句来解决，然而 like 语句在大数据的情况下，产生的超大影响将可能使你的整个数据库出现高 IO，CPU 久高不下的情况。那么这样的设计能用吗？答案当然是不可以。那么该怎样实现这样的多字段高级搜索呢？答案就是 Lucene，本文将详细的对比 Lucene 和 数据库中的 like 语句。
通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页， 上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。
由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" …其效率也就可想而知了。
所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。
由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。
可以通过一下表格对比一下数据库的模糊查询：
| Lucene全文索引引擎 | 数据库 | |
| 索引 | 将数据源中的数据都通过全文索引一一建立反向索引 | 对于LIKE查询来说，数据传统的索引是根本用不上的。数据需要逐个便利记录进行GREP式的模糊匹配，比有索引的搜索速度要有多个数量级的下降。 |
| 匹配效果 | 通过词元(term)进行匹配，通过语言分析接口的实现，可以实现对中文等非英语的支持。 |
使用：like "%net%" 会把netherlands也匹配出来， 多个关键词的模糊匹配：使用like "%com%net%"：就不能匹配词序颠倒的xxx.net..xxx.com |
| 匹配度 | 有匹配度算法，将匹配程度（相似度）比较高的结果排在前面。 | 没有匹配程度的控制：比如有记录中net出现5词和出现1次的，结果是一样的。 |
| 结果输出 | 通过特别的算法，将最匹配度最高的头100条结果输出，结果集是缓冲式的小批量读取的。 | 返回所有的结果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放这些临时结果集。 |
| 可定制性 | 通过不同的语言分析接口实现，可以方便的定制出符合应用需要的索引规则（包括对中文的支持） | 没有接口或接口复杂，无法定制 |
| 结论 | 高负载的模糊查询应用，需要负责的模糊查询的规则，索引的资料量比较大 | 使用率低，模糊匹配规则简单或者需要模糊查询的资料量少 |
全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求。
Lucene的创新
大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。
Lucene和其他一些全文检索系统/应用的比较：
| Lucene | 其他开源全文检索系统 | |
| 增量索引和批量索引 | 可以进行增量的索引(Append)，可以对于大量数据进行批量索引，并且接口设计用于优化批量索引和小批量的增量索引。 | 很多系统只支持批量的索引，有时数据源有一点增加也需要重建索引。 |
| 数据源 | Lucene没有定义具体的数据源，而是一个文档的结构，因此可以非常灵活的适应各种应用（只要前端有合适的转换器把数据源转换成相应结构）， | 很多系统只针对网页，缺乏其他格式文档的灵活性。 |
| 索引内容抓取 |
Lucene的文档是由多个字段组成的，甚至可以控制那些字段需要进行索引，那些字段不需要索引，近一步索引的字段也分为需要分词和不需要分词的类型： 需要进行分词的索引，比如：标题，文章内容字段 不需要进行分词的索引，比如：作者/日期字段 |
缺乏通用性，往往将文档整个索引了 |
| 语言分析 |
通过语言分析器的不同扩展实现： 可以过滤掉不需要的词：an the of 等， 西文语法分析：将jumps jumped jumper都归结成jump进行索引/检索 非英文支持：对亚洲语言，阿拉伯语言的索引支持 |
缺乏通用接口实现 |
| 查询分析 |
通过查询分析接口的实现，可以定制自己的查询语法规则： 比如： 多个关键词之间的 + – and or关系等 |
|
| 并发访问 | 能够支持多用户的使用 |
可以说在数据量很小的情况下，使用 数据库 SQL 语句的 like 语句比 Lucene 有优势，但是在数据量超大的情况下，使用 like 就非常的不明智了。而应该采用 Lucene。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Lucene 全文检索不等于like “%keyword%”