详细了解SQLITE　优缺点　性能测试
什么是SQLITE：
SQLite是一个开源免费的数据库，一般用于嵌入系统或者小规模的应用软件开发中，你可以像使用Access一样使用它，你可以免费用于任何应用，包括商业应用，另外，它还支持各种平台和开发工具，这点是某些数据库（比如Access、DBISAM）。
SQLite是一种嵌入式数据库，它跟微软的Access差不多，只是一个.db格式的文件。但是与Access不同的是，它不需要安装任何软件，非常轻巧。很多软件都有用到这个家伙，包括腾讯QQ、迅雷(你在迅雷的安装目录里可以看到有一个sqlite3.dll的文件，就是它了)，以及现在大名鼎鼎的android等。SQlite3是它的第三个主要版本。就是SQLite3.0的意思。对了，金山词霸也有用到SQLite，其实太多软件用那玩意儿了。
sqlite的主要优点：
&　零配置(Zero Configuration)
SQlite3不用安装，不用配置，不用启动，关闭或者配置数据库实例。当系统崩溃后不用做任何恢复操作，再下次使用数据库的时候自动恢复。
　紧凑（compactness）：
　　SQLite是被设计成轻量级，自包含的。一个头文件，一个lib库，你就可以使用关系数据库了，不用任何启动任何系统进程。一般来说，整个SQLITE库小于225KB。
　可移植(Portability)
　它是运行在Windows,Linux,BSD,Mac OS
X和一些商用Unix系统，比如Sun的Solaris,IBM的AIX，同样，它也可以工作在许多嵌入式操作系统下，比如QNX,VxWorks,Palm
OS, Symbin和Windows CE。
　　最大特点：采用无数据类型，所以可以保存任何类型的数据，SQLite采用的是动态数据类型，会根据存入值自动判断。SQLite具有以下五种数据类型：
1.NULL：空值。
2.INTEGER：带符号的整型，具体取决有存入数字的范围大小。
3.REAL：浮点数字，存储为8-byte IEEE浮点数。
4.TEXT：字符串文本。
5.BLOB：二进制对象。
但同样的，这样的做法会导致在插入和修改时，要花去更多的时间。
SQLITE的缺点：
１：SQLITE不可储存过多的数据库，它的性能发挥最好只能在存放较小的数据量情况下。不要把它当做MYSQL甚至ORACLE来使用。它只是一个200K的数据库。
2：sqlite3不像MYSQL那样使用固定日志文件，所有使用insert、update、delete的运行效率只是一般，sqlite3的一个事务，需要调用
fsync()操作，而一般的大型数据库，如mysql只用到了2次。sqlite3对每个事务都创建一个临时文件来记录日志，这个日志创建、更新和删除竟然使用了3次
fsync()！为什么不用一个固定的日志文件呢？实在难以理解设计者的思路。可能他们把重点放在
性能上吧。通过阅读sqlite3-3.5.1的源代码，发现作者也试图对这个问题进行修正，可能由于可靠性的原因，一直没有正式公布。
操作数据库有主要有三种途径，
１.根据ANDROID的API编的相关程序
２.SQLITE命令符形式，WINDOWS,和LINUX下都可以。
３.第三方GUI管理程序。
LevelDB、TreeDB、SQLite3性能对比测试
下面是对LevelDB、TreeDB、SQLite3
这几个数据库的性能对比测试，分别使用了LevelDB (revision 39) SQLite3 (version 3.7.6.3)
及& (version 1.2.67)这三个版本的数据库。
测试机器配置：six-core Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, with 12288
KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz
文件系统：测试脚本分别跑在两台机器上，其文件系统一台为ext3（磁盘为 SATA Hitachi
HDS721050CLA362），一台为ext4（配备磁盘 SATA Samsung HD502HJ）
性能测试源码：
LevelDB: .
Kyoto TreeDB: .
基本测试的条件如下：
每个数据库使用4GB内存
数据库都处于异步写模式(LevelDB’s sync option, TreeDB’s OAUTOSYNC option,
SQLite3’s synchronous options 都关闭)，也就是说写操作不用等数据真正写到磁盘上才返回。
Key 的长度为16字节
Value 的长度为100字节 (这个长度才能让数据库的压缩算法能够起作用，将数据压缩至50％大小左右)
顺序读写时Key值递增变化
随机读时生成随机的Key值
测试结果：
结果显示，在顺序读写和随机写上，LevelDB 在性能上都遥遥领先，在随机读上面 Kyoto
Cabinet 引擎稍快一些。
在几种不同策略下进行写操作测试
为长数据（数据长度为100,000字节）
LevelDB在Value较长时性能比较低，这是由于LevelDB对每一次写操作都会至少进行两次写动作，一次是写数据文件，另一次是写日志文件。这里慢的主要原因是LevelDB在进行这些操作时对值进行了过多的Copy。
B. 批量写操作
一次写操作写字节的数据，由于TreeDB不支持批量写入，故未对其进行对比测试
上面结果是由于LevelDB数据的组织方式，导致顺序写和随机写在性能上都变化不大。
C. 同步进行写操作
对 LevelDB, 设置 WriteOptions.sync = true.
对 TreeDB, 将 TreeDB’s OAUTOSYNC 选项开启.
对 SQLite3, 设置 “PRAGMA synchronous = FULL”.
如果你看一下ext4文件系统下的测试数据，你会发现ext3和ext4在表现上非常不同。
D. 无压缩的写操作
LevelDB 和 TreeDB 都支持相应的数据压缩算法(LevelDB
使用的是& , TreeDB 使用的是&)，由于SQLite不支持压缩，所以这里的测试数据只是从上面的基本测试结果copy过来的。
LevelDB开启压缩比不开启压缩效率更高，而TreeDB则相反，这可能是由于TreeDB采用的压缩算法（LZO）与LevelDB采用的压缩算法（Snappy）相比计算代价更高。
E. 使用更大内存
将每个独立库的内存增大到128MB，对LevelDB来说，其中120MB用来做 write buffer，另外8MB用来做
cache（原来是2MB的 write buffer 和2MB的cache），对SQLite来说，我们不改变其page
size，还是保持为1kb，但是我们增大其page数量从4k增加到128k，对TreeDB来说，我们同样不改变其page大小，也只是增大其
cache，从4MB增大到128MB。
SQLite 在采用了大内存后性能变化并不大，而 LevelDB 和 TreeDB 的随机写性能却有显著提高。LevelDB
在增大内存后性能提升的原因是其write buffer 更大，从而减少了创建的sorted file的次数。减少了磁盘IO。而
TreeDB 的性能提升原因是由于其数据库的更大部分被映射到内存中了。
在几种不同策略下进行读操作测试
A. 大的Cache空间
我们分配128MB给每个数据库，对LevelDB来说，我们分配8MB给 write
buffer，120MB给cache，对另外两个数据库，由于它们不支持区分 write buffer 和cache，所以统一将
cache size设置成128MB。
从结果可以看到，增大Cache在数据库读性能上都有所提升，其中最为显著的是TreeDB，其随机读性能大幅提升。主要是由于有足够的内存使得其所有读操作都几乎是在内存中进行。
B. 无压缩的读操作
下面结果是我们对预先无压缩状态写入的100万条key为16字节、value为100字节的数据后进行的读性能测试。同样的
SQLite 由于不支持压缩，所以下面数据是直接从其基本测试上copy过来的。
结果可以看到，取消压缩对读取性能提升不是特别大，当然，如果你的数据都在内存中的话，执行解压操作也不会对性能造成太大影响。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。SQLite负载量有多大,不会象access那样容易出问题吧_百度知道
SQLite负载量有多大,不会象access那样容易出问题吧
我有更好的答案
这个很难回答，你可以找工具压一下
其他类似问题
为您推荐：
sqlite的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁sqlite3，使用递归select ，sqlite3_step会发生 Access violation
[问题点数：50分，无满意结帖，结帖人zxjrainbow]
sqlite3，使用递归select ，sqlite3_step会发生 Access violation
[问题点数：50分，无满意结帖，结帖人zxjrainbow]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
<<<<<<>>>>>> Stashed changes
本帖子已过去太久远了，不再提供回复功能。SQLITE和ACCESS性能对比测试
一般来说,传统的桌面应用,尤其是ms平台下,多用access数据库,近年,sqllite越来越流行,而且其对手机终端的支持,更使得起使用率越来越高.access和sqlite有太多的相似之处.可他们性能究竟怎么样呢,我查询了一些对比资料,如下:
ACCESS 插入性能测试：
平台：SYS:WINXP;CPU:2*1.6GHZ;RAM:1G;APP:VC+ADO
1.单条显式事务：
&#160;&#160;&#160; 1 00条：
&#160;&#160; 1000条： 5s
10000条： 50s
2.单条非显式事务：
&#160;&#160;&#160;&#160;
100条：31ms
&#160;&#160; 1000条：156ms
10000条：1500ms
3.批量事务：
&#160;&#160;&#160; 1
00条：16ms
&#160;&#160; 1000条：141ms
10000条：1469ms
以上可以看出，ACCESS单条非显式事务插入的时间几乎和批量事务的插入时间一样，这大概就是网上得出ACCESS快于sqlite的原因吧，但是；单条非显式事务的
方式只能用单连接，如果有多个连接并发访问，则会出现严重问题，在一个链接插入后的相当长一段时间内（有时数S），其它链接都无法插入数据库。可以推理
ADO+ACCESS是采用了一种类似CACHE的做法缓存了操作，但是却一直锁住数据库。单条的显式事务可以保证多链接的访问，但是速度会慢很多，下面再对比一下
SQLITE的测试性能；
SQLITE PC平台插入性能测试：
平台：SYS:WINXP+VMWARE+FEDORA7(LINUX2.6.21)；CPU;1.6GHZ;RAM:412M;
APP:C+SQLITE
1.单条显式事务（SQLITE默认为每个操作开启事务）
&#160;&#160;&#160;
100条：0.587s
&#160; 1000条：6.962s
10000条：56.004s
2.批量事务
&#160;&#160;&#160;
100条：81ms（可能误差较大）
&#160; 1000条：124ms
10000条：1257ms
SQLITE 嵌入式平台插入性能测试：
平台：SYS:LINUX2.6.14;CPU:HI3512 ARM9 200MHZ级别；RAM:32M,ROM:32M NOR
FLASH;APP:C+SQLITE
1.单条显式事务（SQLITE默认为每个操作开启事务）
&#160;&#160;&#160;
100条：1.98s
&#160; 1000条：19.97s
10000条：34.63s
2.批量事务
&#160;&#160;&#160;
100条：0.15s
&#160; 1000条：0.89s
10000条：8.24s
由这个测试可以看出，在微软平台下，access和sqlite性能基本相当，而在linux平台下，sqlite的并发性能要高出不少。
本文转载自：
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}