數(shù)據(jù)庫(kù)速度比較

這里的數(shù)字非常老，幾乎沒(méi)什么意義。在更新之前仍使用這篇文檔只是為了證明SQLite不是停滯不前的。

執(zhí)行程序總結(jié)

一系列的測(cè)試程序已經(jīng)被運(yùn)行去測(cè)量SQLite 2.7.6，PostgreSQL 7.1.3，和 MySQL 3.23.41 的相對(duì)性能。以下是根據(jù)實(shí)驗(yàn)得出的一些總結(jié)：

• SQLite 2.7.6 是非常快的，有時(shí)可以比安裝在RedHat 7.2 上的預(yù)置的PostgreSQL 7.1.3 快10倍甚至20倍。

• SQLite 2.7.6 總是很快， 有時(shí)比MySQL 3.23.41 快2倍多。

• SQLite 執(zhí)行CREATE INDEX or DROP TABLE時(shí)不像其它數(shù)據(jù)庫(kù)那樣快。但這不是什么問(wèn)題，因?yàn)檫@些是很少運(yùn)用的操作。

• 如果你把 multiple 操作聚集到一個(gè)單獨(dú)的事物項(xiàng)，SQLite可以更快些。

但以下幾點(diǎn)是值得注意的：

• 這些測(cè)試程序不是在測(cè)量多用戶使用時(shí)數(shù)據(jù)庫(kù)的性能，也不是在測(cè)量包含multiple的最優(yōu)化復(fù)雜查詢(xún)。

• 這些測(cè)試是在一個(gè)相對(duì)小的數(shù)據(jù)庫(kù)里完成的（大約14兆字節(jié)）。 它們沒(méi)有測(cè)試數(shù)據(jù)庫(kù)引擎的大小對(duì)程序運(yùn)行速度的影響有多大。

測(cè)試環(huán)境

測(cè)試所用的平臺(tái)是一個(gè)具有1GB內(nèi)存的1.6GHz Athlon和一個(gè)IDE驅(qū)動(dòng)硬盤(pán)。操作系統(tǒng)是具有一個(gè)stock內(nèi)核的RedHat Linux 7.2 。

使用的PostgreSQL 和MySQL服務(wù)器被RedHat 7.2 中的默認(rèn)程序所傳送。（PostgreSQL 7.1.3 版和MySQL3.23.41版）所使用的引擎自始至終沒(méi)有被調(diào)整過(guò)。需要特別注意的是，RedHat 7.2 中默認(rèn)的MYSQL配置不支持處理事物項(xiàng)，這一點(diǎn)使MYSQL的速度大大增加。但SQLite還是有能力完成大部分的測(cè)試的。

我被告知，RedHat 7.3 中預(yù)設(shè)的PostgreSQL配置是非常落后的（它必須在具有 8MB RAM 的機(jī)器上工作）。 and that PostgreSQL則可以通過(guò)調(diào)整一些配置來(lái)運(yùn)行的快些。 Matt Sergeant 報(bào)道說(shuō)他已經(jīng)調(diào)整了他的PostgreSQL裝置，并且像下面所顯示的一樣重新進(jìn)行測(cè)試。他的結(jié)果顯示 PostgreSQL和MySQL運(yùn)行速度一樣。如想查看結(jié)果，訪問(wèn)：

http://www.sergeant.org/sqlite_vs_pgsync.html

SQLite實(shí)在同樣的配置下被測(cè)試的，它是用 -O6 optimization 和 -DNDEBUG=1 交叉編寫(xiě)，這樣使許多SQLite代碼中的"assert()"語(yǔ)句 無(wú)法運(yùn)行。

所有的測(cè)試都是在一個(gè)靜止的機(jī)器上進(jìn)行的。所有的測(cè)試時(shí)由一個(gè)簡(jiǎn)單的TCL文稿編排程序產(chǎn)生和運(yùn)行的。 A copy of this Tcl script can be found in the你可以在源文件目錄文件SQLite source tree in the file tools/speedtest.tcl中發(fā)現(xiàn)TCL文稿編排程序的副本.

所有測(cè)試中的時(shí)間都是以精確到秒的背景時(shí)鐘來(lái)計(jì)算的.SQLite有兩個(gè)單獨(dú)的時(shí)間值. 第一個(gè)時(shí)間值在一個(gè)完整磁盤(pán)同步化打開(kāi)的默認(rèn)裝置里.同步話打開(kāi)后,為了確保重要數(shù)據(jù)已被真正的寫(xiě)入磁盤(pán)驅(qū)動(dòng)表面,SQLite在關(guān)鍵的時(shí)候執(zhí)行 fsync()系 統(tǒng)調(diào)用. 在數(shù)據(jù)庫(kù)更新過(guò)程中,當(dāng)操作系統(tǒng)崩潰時(shí)或者計(jì)算機(jī)突然斷電時(shí),為了保證數(shù)據(jù)庫(kù)的完整性,同步化是非常有必要的.第二個(gè)時(shí)間值是當(dāng)同步化關(guān)閉的時(shí)候.關(guān)閉同 步化, SQLite有時(shí)會(huì)運(yùn)行的快些,但如果系統(tǒng)崩潰或者突然斷電數(shù)據(jù)庫(kù)將會(huì)受到損失. 通常來(lái)說(shuō),同步化的SQLite的時(shí)間是為了和PostgreSQL(因?yàn)樗彩峭交?比較,異步化的SQLite是為了和也是異步化的MySQL引 擎比較.

測(cè)試 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');

因?yàn)闆](méi)有一個(gè)中央服務(wù)器來(lái)控制訪問(wèn)，SQLite必須先關(guān)閉再打開(kāi)數(shù)據(jù)庫(kù)文件，這樣高速緩存器就失去了作用。在這個(gè)測(cè)試中，每個(gè) SQL語(yǔ)句都是一個(gè)獨(dú)立的事務(wù)元，所以數(shù)據(jù)庫(kù)文件必須被打開(kāi)和關(guān)閉，高速緩存必須刷新1000次。 盡管這樣，異步版本的SQLite還是和MYSQL一樣快。但同步版本的卻是非常慢。SQLite在每個(gè)同步事務(wù)元后調(diào)用fsync()，因而確保了磁盤(pán)表面所有的數(shù)據(jù)都是安全的。13秒的測(cè)試時(shí)間大部分都被用于磁盤(pán)I/O。