sqlLite性能
最近使用sqlLite做了一些项目工具，对sqlLite的性能大概有了一个比较浅显的了解，在这里分析一下，希望能作为大家做技术选型的参考。
首先是写能力，sqlLite是一个单文件数据库，再加上锁问题，sqlLite的写能力比较弱，但是考虑到sqlLite主要应对的场景是桌面程序和嵌入式，这个写能力也完全能符合这个定位。
但是如果考虑在服务端使用sqlLite,还是要根据业务场景慎重考虑，尤其是写功能比较多的场景
下面是写性能的一些数据量级的参考
100条
插入订阅记录 ： 101 条 耗时[ 484 ]
500条
插入订阅记录 ：500 条 耗时[ 1979 ]
500 条差不多就已经2秒钟了
1000 条
插入订阅记录 ： 1000 条 耗时[ 5416
插入订阅记录 ： 1000 条 耗时[ 3958 ]
插入订阅记录 ： 1000 条 耗时[ 4869 ]
插入订阅记录 ： 1000 条 耗时[ 4022 ]
插入订阅记录 ： 1000 条 耗时[ 4278 ]
1000条数据写入基本上在4秒左右，这个性能与MYSQL这些数据库的差距还是很大的。
还有一点，sqllite的锁机制是库锁，写入时不能多线程并发写入，所以以上性能通过多线程并不能解决，反而会报错。因此为sqlLite维护一个大的链接池，没有必要，反而会报错。
小编的解决方案是创建多个sqlLite库来提高并发写能力，但是小编的业务场景是相对独立的，不会出现多表联查的情况。
读性能
虽然 SQLlite的写能力比较拉胯，但是不得不说，读能力还是可圈可点的。
小编使用SQLLite保存业务系统订阅的日志，日志内容是通过Mock工具读取的小说，数据有随机性，共创建了大概26万数据 。
下面是读性能的一些记录。
共匹配[ 5601 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 108 ] 毫秒。
共匹配[ 5601 ] 条, 页码[ 113 ] 页大小[ 50 ] ,耗时[ 228 ] 毫秒。
共匹配[ 5601 ] 条, 页码[ 110 ] 页大小[ 50 ] ,耗时[ 174 ] 毫秒。
共匹配[ 260409 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 2387 ] 毫秒。
共匹配[ 260409 ] 条, 页码[ 5 ] 页大小[ 50 ] ,耗时[ 415 ] 毫秒。
共匹配[ 260409 ] 条, 页码[ 6 ] 页大小[ 50 ] ,耗时[ 432 ] 毫秒。
共匹配[ 260409 ] 条, 页码[ 5 ] 页大小[ 50 ] ,耗时[ 411 ] 毫秒。
共匹配[ 8 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 367 ] 毫秒。
共匹配[ 8 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 379 ] 毫秒。
共匹配[ 260420 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 666 ] 毫秒。
共匹配[ 260420 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 702 ] 毫秒。
共匹配[ 1000 ] 条, 页码[ 1 ] 页大小[ 50 ] ,耗时[ 148 ] 毫秒。
对于这个查询结果，本身还是比较满意的，并且这个性能我并没有创建索引，如果创建索引性能会提升很多，并且查询都是 模糊查询，所以也没有创建索引的必要。
对于一个单文件数据库，这性能小编还是比较满意的。
为什么选择SqlLite
上面已经说明了SqlLite的一些性能问题，那么为什么还要选择SqlLite 。
首先SqlLite是小编这个运行记录组件的数据库解决方案之一，并不是仅支持SqlLite，对于一些中小型项目，SqlLite完全可以满足需求，并且不会增加集成成本，基本上一个注解既可以注入。
介绍一下运行记录组件的主要功能
如上图所示，运行记录功能提供了 接口访问记录 ，日志订阅 ，项目配置 ，接口列表 ，其中 访问记录由于并发量比较大，并未采用SqlLite 而是使用了Lucene ,其余三个功能模块都默认使用SqlLite存储数据。
其中日志订阅功能是数据量最大的，但是这个模块主要是记录业务系统的一些特定日志（主要是异常的错误日志），如果一个系统一个月能跑出来1万+ 的错误日志，就说明要么代码有问题，要么业务模型有问题，这也是这个模块设计的宗旨，帮助系统主动发现一下超出预期的错误，主动处理。
并且在这个模块里，小编采用了定时任务和缓存的机制批量记录错误记录，因此无需担心这个模块会影响业务系统性能。
至于这个系统工具，小编完善后会开源，欢迎有需要的订阅支持。
