概述
Sqlite是一个很优秀的数据库，不仅体积小，多平台支持，而且数据库具有单个文件，方便在不同平台上快速部署等很多优势。
关于Sqlite的性能，总是最具有争议的地方。不过之前也在网上看到过有人把sqlite和Mysql做过对比，然后呢，在配置相似的情况下得出的结果是sqlite和mysql的IO性能实际上相差无几。
得到这样的结论也不难想象，因为sqlite和mysql都是基于文件的数据库，IO性能最终还要受到磁盘的IO速度的限制。因此，在mysql没有使用各种加速引擎的情况下，两者的性能的确不相上下。
在之前的一片文章中提到，给sqlite的字段增加索引可以大大提高查找的速度。今天这里再引入另外一个方法，就是使用Sqlite自带的全文分词索引。
这里说的全文分词索引并不是指给sqlite的某个表上的某个列建立索引（index），而是指类似与谷歌、百度、微软bing 类似的搜索引擎的“全文分词索引”（full-text index），虽然它们使用了相似的技术，但它们本身是完全不同的东西。
测试
Sqlite官方文档(http://www.sqlite.org/fts3.html)就描述了使用Sqlite自带的FTS3 和 FTS4 虚拟表模型来进行全文分词检索的方法。并且举了一个例子，在一个具有50万左右条目的表中来对比全文索引和普通表的like搜索法的对比：
首先是建立两个表：地一个是虚拟表，第二个是普通的表
CREATE VIRTUAL TABLE en1 USING fts3(content TEXT); /* FTS3 table */ CREATE TABLE en2(content TEXT); /* Ordinary table */
第二步，这时候这个数据库中已经有了超过50万的数据条目
然后分别从两个表中匹配相同的数据
SELECT count(*) FROM en1 WHERE content MATCH 'linux'; /* 0.03 seconds */ SELECT count(*) FROM en2 WHERE content LIKE '%linux%'; /* 22.5 seconds */
结果
结果是，使用了虚拟表的全文检索用了0.03s，而普通的表则用了22.5秒。性能差了将近一千倍。
但是值得注意的一个结果是使用Match 语句匹配出来的结果和使用like ‘%%’ 匹配出的结果完全不同，很典型的匹配结果是，like语句可以匹配出像”linuxophobe” 或 “EnterpriseLinux”这样的结果，而使用match 语句只能匹配出包含 linux 这样单词的结果。
但是在数据量很大的时候，检索的速度反而更加重要。
提高数据库查询的速度的方法有很多种，本文介绍的全文检索只是一种思路。更加复杂的系统必须使用更加独立的方法实现全文检索。
本文地址：http://tweetyf.org/2013/04/sqlite_optimization_fulltext_index.html
Google+
热门评论