sqlite的缺点和限制

 随着查询变大变复杂，查询时间使得网络调用或者事务处理开销相形见绌，
 这时一些大型的设计复杂的数据库开始发挥作用了。
 虽然SQLite也能处理复杂的查询，但是它没有精密的优化器或者查询计划器。
 SQLite知道如何使用索引，但是它没有保存详细的表统计信息。假如执行17路join，SQLite也会连接表并给您结果，并不像您在Oracle或者PostgreSQL中期望的那样，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。

不支持外键约束

◇网络文件系统（以下简称NFS）
有时候需要访问其它机器上的SQLite数据库文件，就会把数据库文件放置到网络共享目录上。这时候你就要小心了。当SQLite文件放置于NFS时，在并发读写的情况下可能会出问题（比如数据损坏）。原因据说是由于某些NFS的文件锁实现上有Bug。

１：SQLITE不可储存过多的数据库，它的性能发挥最好只能在存放较小的数据量情况下。不要把它当做MYSQL甚至ORACLE来使用。它只是一个200K的数据库。

2：sqlite3不像MYSQL那样使用固定日志文件，所有使用insert、update、delete的运行效率只是一般，sqlite3的一个事务，需要调用 4次 fsync()操作，而一般的大型数据库，如mysql只用到了2次。sqlite3对每个事务都创建一个临时文件来记录日志，这个日志创建、更新和删除竟然使用了3次 fsync()！为什么不用一个固定的日志文件呢？实在难以理解设计者的思路。可能他们把重点放在 "Select"

 参考链接：http://blog.csdn.net/yuzhouxiang/article/details/7373111