|
在我眼里，MySQL 和 Oracle 是这样的
而 SQLite 在是这样的
所以这么萌的数据库，我真的应该多了解她的。
简介
SQLite，是一款轻型的数据库，是遵守 ACID 的关系型数据库管理系统。它的设计目标是嵌入式的，目前 Android 和 iOS 的设备内置的都是 SQLite 数据库。SQLite 虽然娇小，但也支持事务和多数的 SQL92 标准。
主要特点
- Zero-Configuration 无需安装和管理配置。
- Serverless 无需服务器支持。
- Single Database File 数据文件存储在一个单一的磁盘文件。
- Stable Cross-Platform Database File 数据库文件格式跨平台，无论是大小端，或者是 32bit 或 64bit 机器都没有关系
- Compact 完整特性的 SQLite 编译出来在 500KiB 左右，裁剪特性甚至可以得到低于 300KiB 的库（当前版本 3.8.11.1）。
- Manifest typing 可以声明数据库字段类型，但是字段存储的类型实际的存储类型和实际值相关，单独的一个字段可能包含不同存储类的值。
- Variable-length records 可变长度记录，例如你存储一个字符到 VARCHAR (100) 的列，实际需要的存储空间一个字符加一个字节的存储空间。
- SQL statements compile into virtual machine code SQL 语句会被编译成虚拟机代码，这种虚拟机代码直白可读，便于调试。
- Public domain 完全开源。
- SQL language extensions
主要缺点
- SQLite 只提供数据库级的锁定，所以不支持高并发。
- 不支持存储过程。
- SQLite 没有用户帐户概念，而是根据文件系统确定所有数据库的权限。这会使强制执行存储配额发生困难，强制执行用户许可变得不可能。
如果只在移动设备使用 SQLite，那么他的优点足够好，并且缺点不明显，所以大叔 MySQL 走开。SQLite 妹妹快过来。
事务与锁（ < 3.7.0）
SQLite 的事务和锁是很重要的概念。
锁
SQLite 有 5 个不同的锁状态
- UNLOCKED（未加锁）
- SHARED（共享）
- RESERVED（保留）
- PENDING（未决）
- EXCLUSIVE（排它）
SQLite 有一个加锁表，记录数据库连接的锁状态。每个数据库连接在同一时刻只能处于其中一个锁状态。每种状态(UNLOCKED)都有一种锁与之对应。
读
数据库连接最初处于 UNLOCKED 状态，在此状态下，连接还没有存取数据库。当连接到了一个数据库，甚至已经用 BEGIN 开始了一个事务时，连接都还处于 UNLOCKED 状态。为了能够从数据库中读取数据，连接必须必须进入 SHARED 状态，也就是说首先要获得一个 SHARED 锁。多个连接可以同时获得并保持共享锁，也就是说多个连接可以同时从同一个数据库中读数据，SQLite 是支持并发读取数据的。
写
一个连接想要写数据库，它必须首先获得一个 RESERVED 锁。一个数据库上同时只能有一个 RESERVED 锁，保留锁可以与共享锁共存，RESERVED 锁即不阻止其它拥有 SHARED 锁的连接继续读数据库，也不阻止其它连接获得新的 SHARED 锁。 一旦一个连接获得了 RESERVED 锁，它就可以将数据写入缓冲区，而不是实际地写到磁盘。 当连接想要提交修改(或事务)时，需要获得 PENDING 锁，之后连接就不能再获得新的 SHARED 锁了，但已经拥有 SHARED 锁的连接仍然可以继续正常读数据库。当所有其它 SHARED 锁都被释放时，拥有 PENDING 锁的连接就可以将其锁提升至 EXCLUSIVE 锁，此时就可以将以前对缓冲区所做的修改写到数据库文件。所以SQLite 是不支持并发写的。
事务
SQLite 有三种不同的事务
- DEFERRED（推迟）
- MMEDIATE（立即）
- EXCLUSIVE（排它）
事务类型在 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 在实现的过程中，使用了共享内存技术，因此，所有的读写进程必须在同一个机器上，否则，无法保证数据一致性。
优点
- 读和写可以完全地并发执行，不会互相阻塞（但是写之间仍然不能并发）。
- WAL 在大多数情况下，拥有更好的性能（因为无需每次写入时都要写两个文件）。
- 磁盘I/O行为更容易被预测
缺点
- 访问数据库的所有程序必须在同一主机上，且支持共享内存技术。
-
每个数据库现在对应 3 个文件：.db，-wal，-shm。
- 当写入数据达到 GB 级的时候，数据库性能将下降。
- 3. 7.0 之前的 SQLite 无法识别启用了 WAL 机制的数据库文件。
- WAL 引入的兼容性问题。在启用了 WAL 之后，数据库文件格式的版本号由 1 升级到了2，因此，3.7.0 之前的 SQLite 无法识别启用了 WAL 机制的数据库文件。禁用 WAL 会使数据库文件格式的版本号恢复到1，从而可以被 SQLite 3.7.0 之前的版本识别。
- WAL 引入的性能问题。在一般情况下，WAL 会提高 SQLite 的事务性能；但是在某些极端情况下，却会导致 SQLite 事务性能的下降。
- 在事务执行时间较长或者要修改的数据量达到 GB 级的时候，WAL 文件会被占用，它会暂时阻止 checkpoint 的执行（checkpoint 会清空 WAL 文件），这将导致 WAL 文件变得很大，增加寻址时间，最终导致读写性能的下降。
- 当 checkpoint 执行的时候，会降低当时的读写性能，因此，WAL 可能会导致周期性的性能下降
|
