SQLITE的局限性

SQLite和其他大部分現代SQL數據庫在基本設計目標上是不同的，它的目標是簡(jiǎn)單。SQLite遵循這一目標，即使這樣偶爾會(huì )導致某些特性實(shí)現的低效化。下面列舉了SQLite的一些缺陷：

SQL-92特性方面

正如前面提到的，SQLite不支持SQL-92的在很多企業(yè)數據庫系統中可用的一些特性。
如：
外鍵約束（可解析的，但非強制）
很多ALTER TABLE特性
一些TRIGGER相關(guān)的特性
RIGHT和FULL OUTER JOIN
更新一個(gè)VIEW
GRANT和REVOKE

你可以在SQLite的主頁(yè)上獲取最新信息。
http://www.sqlite.org/omitted.html
http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql

低并發(fā)操作

SQLite只支持平面事務(wù)；它沒(méi)有嵌套和營(yíng)救點(diǎn)能力。嵌套意味著(zhù)在一個(gè)事務(wù)中可以有子事務(wù)的能力。營(yíng)救點(diǎn)允許一個(gè)事務(wù)返回到前面已經(jīng)到達的狀態(tài)。它沒(méi)有能力確保高層次事務(wù)的并發(fā)。它允許在單個(gè)的數據庫文件上多個(gè)并發(fā)的讀事務(wù)，但是只能有一個(gè)排他的寫(xiě)事務(wù)。這個(gè)局限性意味著(zhù)如果有事務(wù)在讀數據庫文件的一部分，所有其他的事務(wù)將被禁止寫(xiě)該文件的任何一部分。類(lèi)似的，如果有事務(wù)在寫(xiě)數據庫文件的一部分，所有其他事務(wù)將被禁止讀或者寫(xiě)該文件的任何一部分。

應用限制

因為它事務(wù)處理的有限并發(fā)，SQLite只擅長(cháng)處理小型的事務(wù)。在很多情況下，這不是問(wèn)題。每個(gè)應用迅速的完成它的數據庫工作然后繼續前進(jìn)，因此沒(méi)有一個(gè)事務(wù)會(huì )持有數據庫超過(guò)多少毫秒。但是在一些應用中，特別是寫(xiě)入密集的，要求更多的并發(fā)的事務(wù)處理（表或者行級別的而不是數據庫級別的）那么你將要為該應用使用其他不同的DBMS。SQLite并不打算成為一個(gè)企業(yè)DBMS。他最適合于實(shí)現，維護和管理的簡(jiǎn)單性比商業(yè)數據庫的無(wú)盡復雜特性更為重要的情況。

NFS問(wèn)題

SQLite使用本地文件鎖原語(yǔ)來(lái)控制事務(wù)處理的并發(fā)性。如果數據庫文件駐留在網(wǎng)絡(luò )分區上，可能會(huì )導致文件鎖不能工作。很多的NFS實(shí)現被認為在它們的文件鎖中是有bug的（在Unix和Windows上）。如果文件鎖不能像預計的一樣工作，那么就可能會(huì )有兩個(gè)或兩個(gè)以上的應用程序在同時(shí)修改相同數據庫的同一部分，導致了數據庫的毀壞。因為這個(gè)問(wèn)題的出現是因為位于下層的文件系統的實(shí)現的BUG，所以SQLite沒(méi)有辦法阻止它的發(fā)生。

另一原因是大多數網(wǎng)絡(luò )文件系統的連接延時(shí)，效果不是很好。在這種環(huán)境下，在數據庫文件必須要跨網(wǎng)絡(luò )訪(fǎng)問(wèn)的情況下，實(shí)現了客戶(hù)端-服務(wù)器的模型的DBMS會(huì )比SQLite更有效。

數據庫規模

因為它的開(kāi)發(fā)人員的開(kāi)發(fā)設計選擇，SQLite可能不是一個(gè)做非常大型的數據庫好選擇。在理論上,一個(gè)數據庫文件文件可以有2TB（241）。日志子系統的內存開(kāi)銷(xiāo)和數據庫大小是成比例的。對每個(gè)寫(xiě)事務(wù)，無(wú)論事務(wù)實(shí)際是寫(xiě)是讀那個(gè)頁(yè)，SQLite為每個(gè)數據庫頁(yè)維護一個(gè)內存內信息位。默認的頁(yè)大小是1024字節。即使如此，對一個(gè)有超過(guò)幾百萬(wàn)頁(yè)的數據庫，內存開(kāi)銷(xiāo)可能成為一個(gè)嚴重的瓶頸。

對象的數目和類(lèi)型

一個(gè)表或者索引被限制為最多有264 – 1個(gè)項。當然，你不可能有這么多的條目，因為數據庫的241字節大小限制。在SQLite的當前的實(shí)現中，一個(gè)單獨的條目能夠持有230字節的數據。（下層的文件格式支持行大小相當于262字節的數據。）在打開(kāi)一個(gè)數據庫文件時(shí)，SQLite會(huì )閱讀并且預處理來(lái)自主目錄表的所有條目并且創(chuàng )建很多內存目錄對象。所以，為了最好的性能，最好控制表，索引，視圖和觸發(fā)器的數目。同樣雖然沒(méi)有限制表中列的數目，超過(guò)幾百列還是似乎太過(guò)的。只有表開(kāi)始的31列是候選為必然被優(yōu)化的。你能夠在一個(gè)索引中盡可能加入列，但是有超過(guò)30列的索引將不會(huì )被用來(lái)優(yōu)化。

宿主變量引用

在一些嵌入DBMS中，SQL語(yǔ)句能夠直接引用宿主變量（即來(lái)自應用程序空間的那些值）。在SQLite中這是不行的。作為替代SQLite允許使用sqlite3_bind_* API函數來(lái)對輸入參數而不是輸出值綁定對SQL語(yǔ)句宿主變量。這種策略通常比直接的訪(fǎng)問(wèn)策略更好，因為后者需要特殊的預處理來(lái)將SQL語(yǔ)句轉化為特殊的API調用。

存儲過(guò)程

很多DBMS有被稱(chēng)為存儲過(guò)程的能力來(lái)創(chuàng )建和存儲。存儲過(guò)程是形成邏輯作業(yè)單元和執行特殊任務(wù)的一組SQL語(yǔ)句。SQL查詢(xún)過(guò)程能夠使用這些過(guò)程。SQLite沒(méi)有這個(gè)能力。

另外一些局限

不支持外鍵

如果你的表格中有類(lèi)似的語(yǔ)句，sqlite會(huì )忽略的:

create table zope_suf.userroles (
name varchar(64) not null references zope_suf.users(name)
...

上面的外鍵refernces約束是不支持的，如果要支持，需要手工寫(xiě)trigger。

參考：http://www.sqlite.org/cvstrac/wiki?p=ForeignKeyTriggers

Client/Server應用

Sqlite是沒(méi)有Server的，當然更適合做web應用一些。如果做C/S則需要通過(guò)文件共享來(lái)訪(fǎng)問(wèn)數據庫，這個(gè)性能就差了；而且可能有寫(xiě)沖突。

高訪(fǎng)問(wèn)量的網(wǎng)站

Sqlite不可能把數據庫對象分別部屬在不同的計算機上，也就是說(shuō)不可能實(shí)現數據庫的clusting。如果要有這個(gè)特性，需要考慮其他C/S架構的數據庫。

非常大的數據集

在處理事務(wù)中，sqlite會(huì )在內存中分配一個(gè)臟頁(yè)面表: 每1M的數據庫會(huì )耗用256Byte 的內存。如果你的數據庫修改達到數G，這個(gè)內存耗用會(huì )非常大。

如果數據的修改和存儲超過(guò)數十G(應該不會(huì ))，你應該考慮其他的數據庫。

高并行

SQLite是整個(gè)數據庫級別的讀寫(xiě)鎖，大量并行讀寫(xiě)，可能存在沖突。因此不適合多個(gè)進(jìn)程并行讀寫(xiě)的情況。