SQLite测试报告

测试 1: 1000 INSERTs

CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));
INSERT INTO t1 VALUES(1,13153,'thirteen thousand one hundred fifty three');
INSERT INTO t1 VALUES(2,75560,'seventy five thousand five hundred sixty');
... 995 lines omitted
INSERT INTO t1 VALUES(998,66289,'sixty six thousand two hundred eighty nine');
INSERT INTO t1 VALUES(999,24322,'twenty four thousand three hundred twenty two');
INSERT INTO t1 VALUES(1000,94142,'ninety four thousand one hundred forty two');

因为没有一个中央服务器来控制访问，SQLite必须先关闭再打开数据库文件，这样高速缓存器就失去了作用。在这个测试中，每个 SQL语句都是一个独立的事务元，所以数据库文件必须被打开和关闭，高速缓存必须刷新1000次。 尽管这样，异步版本的SQLite还是和MYSQL一样快。但同步版本的却是非常慢。SQLite在每个同步事务元后调用fsync()，因而确保了磁盘表面所有的数据都是安全的。13秒的测试时间大部分都被用于磁盘I/O。

Test 2: 25000 INSERTs in a transaction

BEGIN;
CREATE TABLE t2(a INTEGER, b INTEGER, c VARCHAR(100));
INSERT INTO t2 VALUES(1,298361,'two hundred ninety eight thousand three hundred sixty one');
... 24997 lines omitted
INSERT INTO t2 VALUES(24999,447847,'four hundred forty seven thousand eight hundred forty seven');
INSERT INTO t2 VALUES(25000,473330,'four hundred seventy three thousand three hundred thirty');
COMMIT;

Test 3: 25000 INSERTs into an indexed table

BEGIN;
CREATE TABLE t3(a INTEGER, b INTEGER, c VARCHAR(100));
CREATE INDEX i3 ON t3(c);
... 24998 lines omitted
INSERT INTO t3 VALUES(24999,442549,'four hundred forty two thousand five hundred forty nine');
INSERT INTO t3 VALUES(25000,423958,'four hundred twenty three thousand nine hundred fifty eight');
COMMIT;

Test 4: 100 SELECTs without an index

SELECT count(*), avg(b) FROM t2 WHERE b>=0 AND b<1000;
SELECT count(*), avg(b) FROM t2 WHERE b>=100 AND b<1100;
SELECT count(*), avg(b) FROM t2 WHERE b>=200 AND b<1200;
... 94 lines omitted
SELECT count(*), avg(b) FROM t2 WHERE b>=9700 AND b<10700;
SELECT count(*), avg(b) FROM t2 WHERE b>=9800 AND b<10800;
SELECT count(*), avg(b) FROM t2 WHERE b>=9900 AND b<10900;

Test 5: 100 SELECTs on a string comparison

SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%one%';
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%two%';
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%three%';
... 94 lines omitted
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%ninety eight%';
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%ninety nine%';
SELECT count(*), avg(b) FROM t2 WHERE c LIKE '%one hundred%';

Test 6: INNER JOIN without an index

SELECT t1.a FROM t1 INNER JOIN t2 ON t1.b=t2.b;

Test 7: Creating an index

CREATE INDEX i2a ON t2(a);
CREATE INDEX i2b ON t2(b);

测试9: 有索引的25000 UPDATEs

BEGIN;
UPDATE t2 SET b=468026 WHERE a=1;
UPDATE t2 SET b=121928 WHERE a=2;
... 24996 lines omitted
UPDATE t2 SET b=35065 WHERE a=24999;
UPDATE t2 SET b=347393 WHERE a=25000;
COMMIT;

在这个测试中，最近的2.7.0 版 SQLite和MYSQL运行速度一样，但是最近对SQLite的优化使它速度比UPDATEs快一倍。

测试10: 有索引的25000 text UPDATEs

BEGIN;
UPDATE t2 SET c='one hundred forty eight thousand three hundred eighty two' WHERE a=1;
UPDATE t2 SET c='three hundred sixty six thousand five hundred two' WHERE a=2;
... 24996 lines omitted
UPDATE t2 SET c='three hundred eighty three thousand ninety nine' WHERE a=24999;
UPDATE t2 SET c='two hundred fifty six thousand eight hundred thirty' WHERE a=25000;
COMMIT;

2.7.0 版本的SQLite过去和MYSQL运行速度一样，但现在2.7.6 版的SQLite的速度是MYSQL的两倍，是PostgreSQL的20倍。

在这个测试中，PostgreSQL也很慢，一个有经验的管理者可以通过调试服务器使之运行的快些。

Test 11: 来于SELECT的INSERTs

BEGIN;
INSERT INTO t1 SELECT b,a,c FROM t2;
INSERT INTO t2 SELECT b,a,c FROM t1;
COMMIT;

在这个测试中，异步的SQLite比MYSQL慢（MYSQL似乎特别擅长INSERT...SELECT语句）。 PostgreSQL引擎仍然是非常慢的， 61秒中的大部分时间被用来等待磁盘I/O。

测试 12: 没有索引的DELETE

DELETE FROM t2 WHERE c LIKE '%fifty%';

在这个测试中，The synchronous version of同步版本的 SQLite是这组中最慢的，但异步版本的SQLite是最快的。不同的是，它需要额外的时间去执行fsync()。

测试 13: 有索引的DELETE

DELETE FROM t2 WHERE a>10 AND a<20000;

这个测试非常重要，因为在这里PostgreSQL比MySQL要快。SQLite比前两者都要快。

测试 14: 一个大 DELETE之后的一个大INSERT

INSERT INTO t2 SELECT * FROM t1;

一些老版的SQLite（2.4.0 以前的版本）在执行完DELETEs及新INSERTs后明显慢下来，但在这个测试中我们可以看到，这个问题已经被解决了。

测试 15: 一个大的DELETE及许多小INSERTs

BEGIN;
DELETE FROM t1;
INSERT INTO t1 VALUES(1,10719,'ten thousand seven hundred nineteen');
... 11997 lines omitted
INSERT INTO t1 VALUES(11999,72836,'seventy two thousand eight hundred thirty six');
INSERT INTO t1 VALUES(12000,64231,'sixty four thousand two hundred thirty one');
COMMIT;

SQLite通常总是会在一个事务处理程序中执行INSERTs，这也许就是为什么在这个测试中SQLite通常比其它数据库快很多的原因。

测试 16: DROP TABLE

DROP TABLE t1;
DROP TABLE t2;
DROP TABLE t3;

SQLite在执行撤销表格这一操作时比其它数据库要慢一些。 这也许是因为当SQLite撤销一个表格的时候，它必须全面检查并清除数据库文件中的记录。与之不同的是，MySQL和 PostgreSQL分别的文件夹来代表每个表格，所以如果它们想撤销一个表格，它们只需删除一个文件，这当然要快一些了。

但是，撤销表格并不是一个常用的操作，所以SQLite慢一些也不会有什么问题.