mysql inmemory_SQLite性能 - inmemory模式。

SQLite创建的数据库有一种模式IN-MEMORY，但是它并不表示SQLite就成了一个内存数据库。IN-MEMORY模式可以简单地理解为，(2020 表述勘误：本来创建的数据库文件是基于磁盘的，现在整个文件使用内存空间来代替磁盘空间，没有了文件作为backingstore，不必在修改数据库后将缓存页提交到文件系统)，其它操作保持一致。也就是数据库的设计没有根本改变。

inmemory与tempdb是两种节约模式，节约的对象为(rollback)日志文件以及数据库文件，减少IO。inmemory将日志写在内存，并且去除数据库文件作为backingStore，缓存页不用提交到文件系统。tempdb只会在只会在脏的缓存页超过当前总量的25％才会同步刷写到文件，换句话说在临时数据库模式下，事务提交时并不总同步脏页，因此减少了IO数量，事务日志也受这种机制影响，所以在临时数据库模式下，事务日志是不是MEMORY并不重要。回过头来看，内存模式则是临时模式的一种极致，杜绝所有的IO。这两种模式都只能存在一个sqlite3连接，关闭时销毁。

提到内存，许多人就会简单地理解为，内存比磁盘速度快很多，所以内存模式比磁盘模式的数据库速度也快很多，甚至有人望文生意就把它变成等同于内存数据库。

它并不是为内存数据库应用而设计的，本质还是文件数据库。它的数据库存储文件有将近一半的空间是空置的，这是它的B树存储决定的，(2020 勘误：对于固定长度记录，页面使用率最大化，对于非自增计数键的索引，页面一般会保留20～60％的空间，方便插入)请参看上一篇SQLite存储格式。内存模式只是将数据库存储文件放入内存空间，但并不考虑最有效管理你的内存空间，其它临时文件也要使用内存，事务回滚日志一样要生成，只是使用了内存空间。它的作用应该偏向于临时性的用途。

(2020 补充：下面的测试有局限性，)

我们先来看一下下面的测试结果，分别往memory和disk模式的sqlite数据库进行1w, 10w以及100w条数据的插入，采用一次性提交事务。另外使用commit_hook捕捉事务提交次数。

(注：测试场景为在新建的数据库做插入操作，所以回滚日志是很小的，并且无需要在插入过程中查找而从数据库加载页面，因此测试也并不全面)

内存模式

磁盘模式

在事务提交前的耗时 (事务提交后的总耗时)：

1w

10w

100w

内存模式

0.04s

0.35s

3.60s

磁盘模式

0.06s (0.27s)

0.47s (0.72s)

3.95s (4.62s)

可以看到当操作的数据越少时，内存模式的性能提高得越明显，事务IO的同步时间消耗越显注。

上图还有一组数据比较，就是在单次事务提交中，如果要为每条插入语句准备的话

1w

10w

100w

内存模式

0.19s

1.92s

19.46s

磁盘模式

0.21s (0.35s)

2.06s (2.26s)

19.88s (20.41s)

我们从SQLit