Performance and Limitations
SQLite is a speedy database. But the words speedy, fast, peppy, or quick are rather subjective terms. To be
perfectly honest, there are things SQLite can do faster than other databases, and there are things that it
cannot. Suffice it to say, within the parameters for which it has been designed, SQLite can be said to be
consistently fast and efficient across the board. SQLite uses B-trees for indexes and B+-trees for tables,
the same as most other database systems. For searching a single table, it is as fast if not faster than any
other database on average. Simple SELECT, INSERT, and UPDATE statements are extremely quick—virtually
at the speed of RAM (for in-memory databases) or disk. Here SQLite is often faster than other databases,
because it has less overhead to deal with in starting a transaction or generating a query plan and because
it doesn’t incur the overhead of making a network calls to the server or negotiating authentication and
privileges. Its simplicity here makes it fast.
As queries become larger and more complex, however, query time overshadows the network call or
transaction overhead, and the game goes to the database with the best optimizer. This is where larger,
more sophisticated databases begin to shine. While SQLite can certainly do complex queries, it does not
have a sophisticated optimizer or query planner. You can always trust SQLite to give you the result, but
what it won’t do is try to determine optimal paths by computing millions of alternative query plans and
selecting the fastest candidate, as you might expect from Oracle or PostgreSQL. Thus, if you are running
complex queries on large data sets, odds are that SQLite is not going to be as fast as databases with
sophisticated optimizers.
So, there are situations where SQLite is not as fast as larger databases. But many if not all of these
conditions are to be expected. SQLite is an embedded database designed for small to medium-sized
applications. These limitations are in line with its intended purpose. Many new users make the mistake
of assuming that they can use SQLite as a drop-in replacement for larger relational databases.
Sometimes you can; sometimes you can’t. It all depends on what you are trying to do.
In general, there are two major variables that define SQLite’s main limitations:
•Concurrency(并发). SQLite has coarse-grained locking, which allows multiple readers
but only one writer at a time. Writers exclusively lock the database during writes,
and no one else has access during that time. SQLite does take steps to minimize
the amount of time in which exclusive locks are held. Generally, locks in SQLite
are kept for only a few milliseconds. But as a general rule of thumb, if your
application has high write concurrency (many connections competing to write to
the same database) and it is time critical, you probably need another database. It
is really a matter of testing your application to know what kind of performance
you can get. We have seen SQLite handle more than 500 transactions per second
for 100 concurrent connections in simple web applications. But your transactions
may differ in the number of records being modified or the number and complexity
of the queries involved. Acceptable concurrency all depends on your particular
application and can be determined empirically only by direct testing. In general,
this is true with any database: you don’t know what kind of performance your
application will get until you do real-world tests.
•Networking(网络). Although SQLite databases can be shared over network file systems,
the latency associated with such file systems can cause performance to suffer.
Worse, bugs in network file system implementations can also make opening and
modifying remote files—SQLite or otherwise—error prone. If the file system’s
locking does not work properly, two clients may be allowed to simultaneously
modify the same database file, which will almost certainly result in database
corruption. It is not that SQLite is incapable of working over a network file system
because of anything in its implementation. Rather, SQLite is at the mercy of the
underlying file system and wire protocol, and those technologies are not always
perfect. For instance, many versions of NFS have a flawed fcntl()
implementation, meaning that locking does not behave as intended. Newer NFS
versions, such are Solaris NFS v4, work just fine and reliably implement the
requisite locking mechanisms needed by SQLite. However, the SQLite developers
have neither the time nor the resources to certify that any given network file
system works flawlessly in all cases.


Again, most of these limitations are intentional, resulting from SQLite’s design. Supporting high

write concurrency, for example, brings with it great deal of complexity, and this runs counter to SQLite’s
simplicity in design. Similarly, being an embedded database, SQLite intentionally does not support
networking. This should come as no surprise. In short, what SQLite can’t do is a direct result of what it
can. It was designed to operate as a modular, simple, compact, and easy-to-use embedded relational

database whose code base is within the reach of the programmers using it. And in many respects, it can

do what many other databases cannot, such as run in embedded environments where actual power
consumption is a limiting factor.
While SQLite’s SQL implementation is quite good, there are some things it currently does not
implement. These are as follows:
• Complete trigger support. SQLite supports almost all the standard features for
triggers, including recursive triggers and INSTEAD OF triggers. However, for all
trigger types, SQLite currently requires FOR EACH ROW behavior, where the triggered
action is evaluated for every row affected by the triggering query. ANSI SQL 92 also
describes a FOR EACH STATEMENT trigger style, which is not currently supported.
• Complete ALTER TABLE support. Only the RENAME TABLE and ADD COLUMN variants
of the ALTER TABLE command are supported. Other kinds of ALTER TABLE
operations such as DROP COLUMN, ALTER COLUMN, and ADD CONSTRAINT are not
OUTER JOIN and FULL OUTER JOIN are not. Every RIGHT OUTER JOIN has a provably
semantically identical LEFT OUTER JOIN, and vice versa. Any RIGHT OUT JOIN can be
implemented as a LEFT OUTER JOIN by simply reversing the order of the tables and
modifying the join constraint. A FULL OUTER JOIN can be implemented as a
combination of two LEFT OUTER JOIN statements, a UNION, and appropriate NULL
filtering in the WHERE clause.
• Updatable views. Views in SQLite are read-only. You may not execute a DELETE,
INSERT, or UPDATE statement on a view. But you can create a trigger that fires on an
attempt to DELETE, INSERT, or UPDATE a view and do what you need in the body of
the trigger.

• Windowing functions. One of the new feature sets specified in ANSI SQL 99 are
the windowing functions. These provide post-processing analytic functions for
results, such a ranking, rolling averages, lag and lead calculation, and so on.
SQLite currently only targets ANSI SQL 92 compliance, so it doesn’t support
windowing functions like RANK(), ROW_NUMBER(), and so on.
• GRANT and REVOKE. Since SQLite reads and writes an ordinary disk file, the only
access permissions that can be applied are the normal file access permissions of
the underlying operating system. GRANT and REVOKE commands in general are
aimed at much higher-end systems where there are multiple users who have
varying access levels to data in the database. In the SQLite model, the application
is the main user and has access to the entire database. Access in this model is
defined at the application level—specifically, what applications have access to the
database file.
In addition to what is listed here, there is a page on the SQLite wiki devoted to reporting
unsupported SQL. It is located at www.sqlite.org/cvstrac/wiki?p=UnsupportedSql.


From: The Definitive Guide to SQLite (2nd edition)








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



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


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


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


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

发布了270 篇原创文章 · 获赞 274 · 访问量 377万+


©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客