[转]SQLite性能和限制

前端之家收集整理的这篇文章主要介绍了[转]SQLite性能和限制前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

来源:http://www.jb51.cc/article/p-ankahlwe-oa.html

性能和限制

SQLite是一个很快的数据库,但"快"这个词本身是一个主观的和模糊不清的词。坦白地讲,对于有些事情,SQLite比其他数据库做得快,也有些事情比不上其他数据库。利用SQLite提供的配置参数,SQLite是足够快速和高效的。与大多数数据库一样,SQLite使用B-tree做索引,使用B+-tree处理表。因此,在对单表进行查询时,平均而言,SQLite与其他数据库一样快(至少不慢于)。简单的SELECT、INSERT和UPDATE语句是相当快速的--几乎与内存(如果是内存数据库)或者磁盘同速。SQLite通常要快于其他数据库,因为它在处理一个事务开始,或者一个查询计划的产生方面开销较小,并且没有调用服务器的网络或认证以及权限协商的开销。它的简单性使它更快。

但是随着查询变大变复杂,查询时间使得网络调用或者事务处理开销相形见绌,SQLite将会与其他数据库一样。这时一些大型的设计复杂的数据库开始发挥作用了。虽然SQLite也能处理复杂的查询,但是它没有精密的优化器或者查询计划器。SQLite知道如何使用索引,但是它没有保存详细的表统计信息。假如执行17路join,SQLite也会连接表并给您结果,并不像您在Oracle或者PostgreSQL中期望的那样,SQLite没有通过计算各种替代查询计划并选择最快的候选计划来尝试判断优化路径。因此,假如您在大型数据集合上运行复杂的查询,SQLite与那些有复杂设计的查询计划器的数据库运行一样快的机会是非常小的。

一些情况下,SQLite可能不如大型数据库快,但大多数的这些情况是预期的。SQLite是为中小规模的应用程序设计的一个嵌入式的数据库,这些限制是设计目的预见到的。许多新用户错误地认为使用SQLite可以代替大型关系数据库。事实是有时可以这样做,有时不行,这完全取决于您准备用SQLite来做什么。

一般情况下,SQLite的局限性主要有以下两方面:

并发。SQLite的锁机制是粗粒度的,它允许多个读,但是一次只允许一个写。写锁会在写期间排他地锁定数据库,其他人在此期间不能访问数据库。SQLite已经采取措施以最小化排它锁所占用的时间。通常来讲,SQLite中的锁只保持几毫秒。但是按照一般经验,如果您的应用程序有很高的写并发(许多连接竞争向同一数据库写),并且是时间关键型,您可能需要其他数据库。需要实际测试您的应用程序才能知道能获得怎样的性能。作者曾见过一个简单的网络应用程序中,SQLite用100个并发连接每秒处理500多个事务。您的事务所修改的记录数以及查询所涉及的复杂性可能有所不同。什么样的并发性是可接受的,这取决于具体的应用程序,只能通过直接测试来判断。总之,对任何数据库都是真理:直到您做了实际测试才能知道应用程序能获得怎样的性能。

网络。虽然SQLite数据库可以通过网络文件系统共享,但是与这种文件系统相关的潜在延时会导致性能受损。更糟的是,网络文件系统实现中的一些缺陷也使得打开和修改远程文件--SQLite或其他--很容易出错。如果文件系统的锁实现不当,可能允许两个客户端同时修改同一个数据库文件,这样必然会导致数据库出错。实际上,并不是因为SQLite的实现导致SQLite不能在网络文件系统上工作。相反,SQLite在底层文件系统和有线协议下工作,但是这些技术有时并不完善。例如,许多NFS使用有缺陷的fcntl(),这意味着锁可能并不像设想的那样工作。一些较新版本的NFS,如Solaris NFSV4就可以工作正常,SQLite需要的锁机制也是相当可靠的。然而,SQLite开发者既没有时间,也没有资源去验证任何给定的网络文件系统在所有的情况下都可以无缺陷工作。

再次申明,绝大部分限制是有意设计的--它们是SQLite设计的结果。例如,支持高度的写并发会带来很大的复杂性,这将使SQLite的简单性无法保持。同样,作为嵌入式数据库,SQLite是有意不支持网络的。这一点并不奇怪。总之,SQLite不能做的都是它所能做的直接结果。它开始的设计就是一款模块化、简单、紧凑的以及易于使用的嵌入式关系数据库,它的基础代码都在使用它的程序员的掌握范围内。从多方面看,它能完成许多其他数据库不能做的事情,例如,运行在电力消耗实际上是一项制约因素的嵌入式环境中。

尽管SQLite的实现已经相当好了,但仍有部分特性未能实现,这些特性有:

完整的触发器支持。SQLite支持几乎所有的标准触发器功能,包括递归触发器和INSTEAD OF触发器。但是对于所有的触发器类型,当受触发器查询影响的每一行做评估时,SQLite需要FOR EACH ROW行为。ANSI SQL92也说明了当前不支持FOR EACH STATEMENT。

完整的修改表结构支持。目前只支持RENAME TABLE和ADD COLUMN类型的ALTER TABLE命令。其他类型的ALTER TABLE操作,例如DROP COLUMN、ALTER COLUMN以及ADD CONSTRAINT还未实现。

右外连接与全外连接。左外连接(LEFT OUT JOIN)已经支持,但是右外连接(RIGHT OUTER JOIN)和全外连接(FULL OUTER JOIN)还未实现。所有的右外连接在语义上都有相同的左外连接,相反也成立。通过简单逆向表的顺序和修改连接限制,左外连接可以作为右外连接的实现。全外连接可以通过组合左外连接和UNION以及在WHERE子句中进行恰当的NULL过滤实现。

可更新的视图。SQLite的视图使只读的,您不能在视图上执行DELETE、INSERT或者UPDATE语句。但是您可以创建一个启动对视图进行DELETE、INSERT或者UPDATE的触发器,在触发器内完成您需要执行的操作。

窗口功能。ANSI SQL99的新功能之一就是窗口功能。该功能提供结果集的后处理分析,例如排序、平均移动以及超前和滞后计算等。SQLite目前支持ANSI SQL92的一部分,因此,它不支持像RANK()、ROW_NUMBER()等。

授权和撤销。由于SQLite能读写普通的磁盘文件,因此,唯一可以应用的访问权限就是所在操作系统的普通文件的访问权限。授权(GRANT)和撤销(REVOKE)命令一般是在高端系统中使用的,这些系统中有多个用户,不同用户对数据库中的数据有不同的访问级别。SQLite模型中,应用程序是主用户,能够访问整个数据库。这种模型中的访问明确定义为应用程序级--具体地说,就是应用程序可以访问数据库文件。

除了这里列出的,SQLite Wiki上有个专门的页面列出SQLite不支持的SQL。网址是www.sqlite.org/cvstrac/wiki?p=UnsupportedSql

原文链接:https://www.f2er.com/sqlite/201024.html

猜你在找的Sqlite相关文章