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

SQL-92特性方面

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

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

低并發操作

SQLite只支持平面事務；它沒有嵌套和營救點能力。嵌套意味著在一個事務中可以有子事務的能力。營救點允許一個事務返回到前面已經到達的狀態。它沒有能力確保高層次事務的并發。它允許在單個的數據庫文件上多個并發的讀事務，但是只能有一個排他的寫事務。這個局限性意味著如果有事務在讀數據庫文件的一部分，所有其他的事務將被禁止寫該文件的任何一部分。類似的，如果有事務在寫數據庫文件的一部分，所有其他事務將被禁止讀或者寫該文件的任何一部分。

應用限制

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

NFS問題

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

另一原因是大多數網絡文件系統的連接延時，效果不是很好。在這種環境下，在數據庫文件必須要跨網絡訪問的情況下，實現了客戶端-服務器的模型的DBMS會比SQLite更有效。

數據庫規模

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

對象的數目和類型

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

宿主變量引用

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

存儲過程

很多DBMS有被稱為存儲過程的能力來創建和存儲。存儲過程是形成邏輯作業單元和執行特殊任務的一組SQL語句。SQL查詢過程能夠使用這些過程。SQLite沒有這個能力。

另外一些局限

不支持外鍵

如果你的表格中有類似的語句，sqlite會忽略的:

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

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

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

Client/Server應用

Sqlite是沒有Server的，當然更適合做web應用一些。如果做C/S則需要通過文件共享來訪問數據庫，這個性能就差了；而且可能有寫沖突。

高訪問量的網站

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

非常大的數據集

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

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

高并行

SQLite是整個數據庫級別的讀寫鎖，大量并行讀寫，可能存在沖突。因此不適合多個進程并行讀寫的情況。

轉載于:https://www.cnblogs.com/mmix2009/archive/2013/01/24/2874811.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的SQLite的局限性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。