SQLite这么娇小可爱，不多了解点都不行啊

SQLite，是一款轻型的数据库，是遵守 ACID 的关系型数据库管理系统。它的设计目标是嵌入式的，目前 Android 和 iOS 的设备内置的

在我眼里，MySQL 和 Oracle 是这样的

而 SQLite 在是这样的

所以这么萌的数据库，我真的应该多了解她的。

简介

SQLite，是一款轻型的数据库，是遵守 ACID 的关系型数据库管理系统。它的设计目标是嵌入式的，目前 Android 和 iOS 的设备内置的都是 SQLite 数据库。SQLite 虽然娇小，但也支持事务和多数的 SQL92 标准。

主要特点

主要缺点

如果只在移动设备使用 SQLite，那么他的优点足够好，并且缺点不明显，所以大叔 MySQL 走开。SQLite 妹妹快过来。

事务与锁（

SQLite 的事务和锁是很重要的概念。

锁

SQLite 有 5 个不同的锁状态

SQLite 有一个加锁表，记录数据库连接的锁状态。每个数据库连接在同一时刻只能处于其中一个锁状态。每种状态(UNLOCKED)都有一种锁与之对应。

读

数据库连接最初处于 UNLOCKED 状态，在此状态下，连接还没有存取数据库。当连接到了一个数据库，甚至已经用 BEGIN 开始了一个事务时，连接都还处于 UNLOCKED 状态。为了能够从数据库中读取数据，连接必须必须进入 SHARED 状态，也就是说首先要获得一个 SHARED 锁。多个连接可以同时获得并保持共享锁，也就是说多个连接可以同时从同一个数据库中读数据，SQLite 是支持并发读取数据的。

写

一个连接想要写数据库，它必须首先获得一个 RESERVED 锁。一个数据库上同时只能有一个 RESERVED 锁，保留锁可以与共享锁共存，RESERVED 锁即不阻止其它拥有 SHARED 锁的连接继续读数据库，也不阻止其它连接获得新的 SHARED 锁。 一旦一个连接获得了 RESERVED 锁，它就可以将数据写入缓冲区，而不是实际地写到磁盘。 当连接想要提交修改(或事务)时，需要获得 PENDING 锁，之后连接就不能再获得新的 SHARED 锁了，但已经拥有 SHARED 锁的连接仍然可以继续正常读数据库。当所有其它 SHARED 锁都被释放时，拥有 PENDING 锁的连接就可以将其锁提升至 EXCLUSIVE 锁，此时就可以将以前对缓冲区所做的修改写到数据库文件。所以SQLite 是不支持并发写的。

事务

SQLite 有三种不同的事务

事务类型在 BEGIN 命令中指定：

DEFERRED

一个 DEFERRED 事务不获取任何锁(直到它需要锁的时候)，BEGIN 语句本身也不会做什么事情——它开始于 UNLOCK 状态。默认情况下就是这样的，如果仅仅用 BEGIN 开始一个事务，那么事务就是 DEFERRED 的，同时它不会获取任何锁；当对数据库进行第一次读操作时，它会获取 SHARED 锁；同样，当进行第一次写操作时，它会获取 RESERVED 锁。

MMEDIATE

由 BEGIN 开始的 IMMEDIATE 事务会尝试获取 RESERVED 锁。如果成功，BEGIN IMMEDIATE 保证没有别的连接可以写数据库。但是，别的连接可以对数据库进行读操作；但是，RESERVED 锁会阻止其它连接的 BEGIN IMMEDIATE 或者 BEGIN EXCLUSIVE 命令，当其它连接执行上述命令时，会返回 SQLITE_BUSY 错误。这时你就可以对数据库进行修改操作了，但是你还不能提交，当你 COMMIT 时，会返回 SQLITE_BUSY 错误，这意味着还有其它的读事务没有完成，得等它们执行完后才能提交事务。

EXCLUSIVE

EXCLUSIVE 事务会试着获取对数据库的 EXCLUSIVE 锁。这与 IMMEDIATE 类似，但是一旦成功，EXCLUSIVE 事务保证没有其它的连接，所以就可对数据库进行读写操作了。

死锁

如果两个以 BEGIN DEFERRED 开始事务的连接都处于 SHARED 状态，并且都在等待对方结束 SHARED 从而进入 RESERVED 的话，就会进入死锁状态。所以BEGIN DEFERRED 开始的事务是有可能产生死锁的.

Write-Ahead Logging ( >=3.7.0 )

SQLite 3.7.0 之前是不支持写的时候读得。为了能够读得时候写，引入了 Write-Ahead Logging（WAL）机制，这样可以支持一个写和多个读并发。

在引入 WAL 机制之前，SQLite 使用 rollback journal 机制实现原子事务。

rollback journal 机制的原理是：在修改数据库文件中的数据之前，先将修改所在分页中的数据备份在另外一个地方，然后才将修改写入到数据库文件中；如果事务失败，则将备份数据拷贝回来，撤销修改；如果事务成功，则删除备份数据，提交修改。

WAL 机制的原理是：修改并不直接写入到数据库文件中，而是写入到另外一个称为 WAL 的文件中；如果事务失败，WAL 中的记录会被忽略，撤销修改；如果事务成功，它将在随后的某个时间被写回到数据库文件中，提交修改。

同步 WAL 文件和数据库文件的行为被称为 checkpoint（检查点），它由 SQLite 自动执行，默认是在 WAL 文件积累到 1000 页修改的时候；当然，，在适当的时候，也可以手动执行 checkpoint，SQLite 提供了相关的接口。执行 checkpoint 之后，WAL 文件会被清空。

在读的时候，SQLite 将在 WAL 文件中搜索，找到最后一个写入点，记住它，并忽略在此之后的写入点（这保证了读写和读读可以并行执行）；随后，它确定所要读的数据所在页是否在 WAL 文件中，如果在，则读 WAL 文件中的数据，如果不在，则直接读数据库文件中的数据。

在写的时候，SQLite 将之写入到 WAL 文件中即可，但是必须保证独占写入，因此写写之间不能并行执行。

WAL 在实现的过程中，使用了共享内存技术，因此，所有的读写进程必须在同一个机器上，否则，无法保证数据一致性。

优点

缺点

访问数据库的所有程序必须在同一主机上，且支持共享内存技术。

每个数据库现在对应 3 个文件：.db，-wal，-shm。

当写入数据达到 GB 级的时候，数据库性能将下降。

3. 7.0 之前的 SQLite 无法识别启用了 WAL 机制的数据库文件。