由于sqlite对多进程操作支持效果不太理想，在项目中，为了避免频繁读写 文件数据库带来的性能损耗，我们可以采用操作sqlite内存数据库，并将内存数据库定时同步到文件数据库中的方法。
实现思路如下：
1、创建文件数据库；
2、创建内存数据库（文件数据库、内存数据库的内部表结构需要一致）；
3、在内存数据库中attach文件数据库，这样可以保证文件数据库中的内容在内存数据库中可见；
4、对于insert、select操作，在内存数据库中完成，对于delete、update操作，需要同时访问内存、文件数据库；
5、定时将内存数据库中的内容flush到文件数据库。
一、内存数据库：
在SQLite中，数据库通常是存储在磁盘文件中的。然而在有些情况下，我们可以让数据库始终驻留在内存中。最常用的一种方式是在调用sqlite3_open()的时候，数据库文件名参数传递":memory:"，如：
rc = sqlite3_open(":memory:", &db);
在调用完以上函数后，不会有任何磁盘文件被生成，取而代之的是，一个新的数据库在纯内存中被成功创建了。由于没有持久化，该数据库在当前数据库连接被关闭后就会立刻消失。需要注意的是，尽管多个数据库连接都可以通过上面的方法创建内存数据库，然而它们却是不同的数据库，相互之间没有任何关系。事实上，我们也可以通过Attach命令将内存数据库像其他普通数据库一样，附加到当前的连接中，如：
ATTACH DATABASE ':memory:' AS aux1;
二、临时数据库：
在调用sqlite3_open()函数或执行ATTACH命令时，如果数据库文件参数传的是空字符串，那么一个新的临时文件将被创建作为临时数据库的底层文件，如：
rc = sqlite3_open("", &db);
或
ATTACH DATABASE '' AS aux2;
和内存数据库非常相似，两个数据库连接创建的临时数据库也是各自独立的，在连接关闭后，临时数据库将自动消失，其底层文件也将被自动删除。
尽管磁盘文件被创建用于存储临时数据库中的数据信息，但是实际上临时数据库也会和内存数据库一样通常驻留在内存中，唯一不同的是，当临时数据库中数据量过大时，SQLite为了保证有更多的内存可用于其它操作，因此会将临时数据库中的部分数据写到磁盘文件中，而内存数据库则始终会将数据存放在内存中。
sqlite分两种源码结构，一种是比较常见的sqlite3.c 一个文件十几万行代码。另一种是，将各个模块分离出的源码结构。
一、主要分为三部分：
虚拟机(Virtual Machine)
Back-end(后端)
compiler(编译器)
1、虚拟机（Virtual Machine）
2、B-tree和Pager
B-Tree使得VDBE可以在O(logN)下查询，插入和删除数据，以及O(1)下双向遍历结果集。B-Tree不会直接读写磁盘，它仅仅维护着页面(pager)之间的关系。当B-Tree需要页面或者修改页面时，它就会调用Pager。当修改页面时，pager保证原始页面首先写入日志文件，当它完成写操作时，pager根据事务状态决定如何做。B-tree不直接读写文件，而是通过page cache这个缓冲模块读写文件，对于性能是有重要意义的（这和操作系统读写文件类似，在Linux中，操作系统的上层模块并不直接调用设备驱动读写设备，而是通过一个高速缓冲模块调用设备驱动读写文件，并将结果存到高速缓冲区）。
3、编译器（Compiler）
3.1、分词器(Tokenizer)
Tokenizer.c
3.2、分析器(Parser)
SQLite的语法分析器是用Lemon（一个开源的LALR(1)语法分析器的生成器）生成的，生成的文件为parser.c。
3.3、代码生成器（Code Generator）
代码生成器是SQLite中最庞大，最复杂的部分。它与Parser关系紧密，根据语法分析树生成VDBE程序执行SQL语句的功能。
由诸多文件构成：select.c,update.c,insert.c,delete.c,trigger.c,where.c等文件。
这些文件生成相应的VDBE程序指令，比如SELECT语句就由select.c生成。
3.4、查询优化
代码生成器不仅负责生成代码，也负责进行查询优化。
主要的实现位于where.c中，生成的WHERE语句块通常被其它模块共享，比如select.c，update.c以及delete.c。
这些模块调用sqlite3WhereBegin()开始WHERE语句块的指令生成，然后加入它们自己的VDBE代码返回，最后调用sqlite3WhereEnd()结束指令生成。
B树：https://www.cnblogs.com/dongguacai/p/7239599.html
相同数量的key在B树中生成的节点要远远少于二叉树中的节点，相差的节点数量就等同于磁盘IO的次数。这样到达一定数量后，性能的差异就显现出来了。
插入或者删除元素都会导致节点发生裂变反应，有时候会非常麻烦，但正因为如此才让B树能够始终保持多路平衡，这也是B树自身的一个优势：自平衡；
B树主要应用于文件系统以及部分数据库索引，如MongoDB，大部分关系型数据库索引则是使用B+树实现。
sqlite中的锁
就数据库而言,处理的并发实际上分为读并发,写并发,读写并发,我们广义上说的并发实际上指的是读写并发,要了解这些,我们还需要先了解一下sqlite中的锁.
sqlite中一共有五种锁分别是
未加锁(UNLOCKED)
文件没有持有任何锁，即当前数据库不存在任何读或写的操作。其它的进程可以在该数据库上执行任意的读写操作。此状态为缺省状态。
共享锁(SHARED)
在此状态下，该数据库可以被读取但是不能被写入。在同一时刻可以有任意数量的进程在同一个数据库上持有共享锁，因此读操作是并发的。换句话说，只要有一个或多个共享锁处于活动状态，就不再允许有数据库文件写入的操作存在。
保留锁(RESERVED)
假如某个进程在将来的某一时刻打算在当前的数据库中执行写操作，然而此时只是从数据库中读取数据，那么我们就可以简单的理解为数据库文件此时已经拥有了保留锁。当保留锁处于活动状态时，该数据库只能有一个或多个共享锁存在，即同一数据库的同一时刻只能存在一个保留锁和多个共享锁. 需要说明的是update操作 实际上是一个读操作加一个写操作
未决锁(PENDING)
PENDING锁的意思是说，某个进程正打算在该数据库上执行写操作，然而此时该数据库中却存在很多共享锁(读操作)，那么该写操作就必须处于等待状态，即等待所有共享锁消失为止，与此同时，新的读操作将不再被允许，以防止写锁饥饿的现象发生。在此等待期间，该数据库文件的锁状态为PENDING，在等到所有共享锁消失以后，PENDING锁状态的数据库文件将在获取排他锁之后进入EXCLUSIVE状态。
排它锁(EXCLUSIVE)
在执行写操作之前，该进程必须先获取该数据库的排他锁。然而一旦拥有了排他锁，任何其它锁类型都不能与之共存。因此，为了最大化并发效率，SQLite将会最小化排他锁被持有的时间总量。
读操作锁变化
了解了sqlite的锁之后 我们再来看针对读写操作,sqlite内部的锁变化
读操作的目的是获取共享锁shared从而来访问数据 那么 在获得共享锁(SHARED)之前
首先检查是否有排它锁(EXCLUSIVE) 如果有 则说明sqlite正在进行写入操作 为保障数据一致 所以无法获取共享锁(SHARED)
如果没有 再检查是否有未决锁(PENDING)如果有 表示当前有准备进行的写操作并阻止共享锁(SHARED)的获取
如果检测不到上述两个锁 将获得共享锁(SHARED) 读取数据 然后释放共享锁
写操作锁变化
对于写操作,写操作的目的是为了获得 排它锁(EXCLUSIVE) 独占数据库从而一致性,其内部锁变化如下
首先 检查数据库是否有保留锁(RESERVED)与排它锁(EXCLUSIVE) 如果有 则说明在此次写操作之前还准备有或者正在进行一次写操作
此时如法获取排它锁(EXCLUSIVE) 如果没有 则获取未决锁(PENDING) 当未决锁(PENDING)获得时,将无法再获取到共享锁(SHARED),也就是说sqlite此时已经不再处理读请求
在持有未决锁(PENDING)期间 将会不断询问内部是否还有共享锁(SHARED)
当等待所有共享锁(SHARED)消失 当所有共享锁(SHARED)消失时 此时锁状态将由未决锁(PENDING)切换至排它锁(EXCLUSIVE)
并写入数据 当排它锁(EXCLUSIVE)激活时 阻止任何类型的其它锁获取 直至写入完毕并释放排它锁(EXCLUSIVE)
总结
最后我们来总结一下
1.当有写操作时，其他读操作会被驳回
2.当有写操作时，其他写操作会被驳回
3.当开启事务时，在提交事务之前，其他写操作会被驳回
4.当开启事务时，在提交事务之前，其他事务请求会被驳回
5.当有读操作时，其他写操作会被驳回
6.读操作之间能够并发执行--------------------- 本文来自 https://blog.csdn.net/zhangsheng_1992/article/details/52598396?utm_source=copy