Sqlite事宜模子、机能优化Tips、常见误区

 0.媒介

本文首要先容sqlite的事宜模子，以及基于事宜模子的一些机能优化tips，包罗事宜封装、WAL+读写疏散、分库分表、page size优化等。并基于手淘sqlite的行使近况总结了部门常见题目及误区，首要齐集在多线程的配置、多线程下机能优化的误区等。本文先提出以下几个题目(作者在举办同一存储的相关存储框架优化进程中一向狐疑的题目，同时也是客户端开拓者常常搞错的题目)并在正文中举办解答：

• 1，sqlite的多历程安详是怎么实现的?机能怎样?
• 2，sqlite的数据库毗连是什么?
• 3，言sqlite必提的读写疏散，详细指什么?能不能晋升数据读写的机能?为什么
• 4，sqlite提供的WAL特征办理了什么题目?
• 5，sqlite的多线程配置是为了办理什么题目?与读写疏散有什么相关?
• 6，什么环境下数据库会发存亡锁?
• 7，有哪些机能优化的方案?

1，sqlite首要数据布局

在深入相识sqlite之前，最好先对sqlite的首要数据布局有个提纲的领略，sqlite是一个很是完整的相关数据库体系，由许多部门构成(parser,tokenize,virtual machine等等)，同时sqlite的事宜模子相对简化，是入门进修相关数据库要领论的一个不错的选择;下文对事宜模子的说明也基于这些焦点数据布局。下面这张图较量精确的描写了sqlite的几个焦点数据布局：

1.1 Connection

connection通过sqlite3_open函数打开，代表一个独立的事宜情形(这里及下文提到的事宜，包罗显式声明的事宜，也包罗隐式的事宜，即每条独立的sql语句)

1.2 B-Tree

B-Tree认真哀求pager从disk读取数据，然后把页面(page)加载到页面缓冲区(page cache)

1.3 Pager

Pager认真读写数据库，打点内存缓存和页面(即下文提到的page caches)，以及打点事宜，锁和瓦解规复

2，sqlite事宜模子及锁

2.1 sqlite多历程安详及Linux & windows文件锁

• 关于提议锁(advisory lock)和逼迫锁(mandatory lock)

提议锁并不由内核逼迫实施，假若有历程不搜查方针文件是否已经过此外历程加了锁就往个中写入数据，内核也不会加以阻拦。因此，提议锁并不能阻止历程对文件的会见，而是必要历程事先对锁的状态做一个约定，并按照锁的当前状态和彼此相关来确定其他历程是否能对文件执行指定的操纵

逼迫锁是由内核逼迫回收的文件锁——因为内查对每个read()和write()操纵城市搜查响应的锁，会低落体系机能

• 典范的提议锁

锁文件;锁文件是最简朴的对文件加锁的要领，每个必要加锁的数据文件都有一个锁文件(lock file)。但这种方法存在较量大的题目是无法逼迫掩护必要加锁的文件，而且当加锁历程非正常退出之后，会造成其他历程的死锁

记录锁;System V和BSD4.3引入了记录锁，响应的体系挪用为lockf()和flock()。而POSIX对付记录锁提供了其它一种机制，其体系挪用为fcntl()。记录锁和锁文件有两个很重要的区别：1)记录锁可以对文件的任何一部门加锁，这对DBMS有极大的辅佐，2)记录锁的另一个利益就是它由历程持有，而不是文件体系持有，当历程竣事时，全部的锁也随之开释。对付一个历程自己而言，多个锁毫不会斗嘴。(Windows中的锁都是逼迫锁，详细不是很熟，只知道在因为windows上文锁的限定，sqlite多历程下的并发性会受影响)

2.1.1 结论

sqlite的文件锁在linux/posix上基于记录锁实现，也就是说sqlite在文件锁上会有以下几个特点：

多历程行使安详，且不会由于历程非常退出激发死锁

单历程行使机能险些不会受损，多历程行使的机能消费会受必然的影响

2.2 事宜模子(Without WAL)

sqlite对每个毗连计划了五钟锁的状态(UNLOCKED, PENDING, SHARED, RESERVED, EXCLUSIVE), sqlite的事宜模子中通过锁的状态担保读写事宜(包罗显式的事宜和隐式的事宜)的同等性和读写安详。sqlite官方提供的事宜生命周期如下图所示，我在这里轻微加了一些小我私人的领略：

这里有几点必要留意：

UNLOCKED、PENDING、SHARED、RESERVED状态长短独有的，也就是说统一个毗连中多个线程并发只读不会被阻塞。

写操纵的数据修改会先写入page cache，内容包罗journal日记、b-tree的修改等;正是因为page cache的存在，许多耗时的“重”操纵都可以不滋扰其他毗连和当前毗连的读操纵，真正意义上担保了sqlite可以同时处理赏罚一个写毗连和多个读毗连。

毗连由RESERVED状态进入EXCLUSIVE状态，必要守候读线程开释SHARED锁，也即写操纵会被读操纵阻塞

毗连由RESERVED状态进入EXCLUSIVE状态后(显式或隐式的挪用commit)，数据库进入独有状态，其他任何毗连都无法由UNLOCK状态进入SHARED状态;也即写操纵会阻塞全部毗连的读操纵(不包罗已经进入SHARED状态的操纵)，直到page caches写入数据库文件(乐成或失败)。

数据库独有状态越久，其他操纵的守候时刻越久，即SQLITE_BUSY发生的一个缘故起因

2.2.1 结论

对付通例的事宜模子(without WAL)，读写(毗连)疏散，差异毗连或统一个毗连上的读和写操纵仍相互阻塞，对机能晋升没有明明辅佐

写事宜在拿到reserve锁之前在page cache里的操纵不会影响其他毗连的读写，以是行使事宜举办批量数据的更新操纵有很是大的机能上风

事宜模子存在死锁的场景，如下图所示：

2.3 WAL对事宜模子的影响

凭证官方文档，WAL的道理如下：

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!