1 隨着查詢變大變復雜,查詢時間使得網絡調用或者事務處理開銷相形見絀, 2 這時一些大型的設計復雜的數據庫開始發揮作用了。 3 雖然SQLite也能處理復雜的查詢,但是它沒有精密的優化器或者查詢計划器。 4 SQLite知道如何使用索引,但是它沒有保存詳細的表統計信息。假如執行17路join,SQLite也會連接表並給您結果,並不像您在Oracle或者PostgreSQL中期望的那樣,SQLite沒有通過計算各種替代查詢計划並選擇最快的候選計划來嘗試判斷優化路徑。 5 因此,假如您在大型數據集合上運行復雜的查詢,SQLite與那些有復雜設計的查詢計划器的數據庫運行一樣快的機會是非常小的。
SQLite是為中小規模的應用程序設計的一個嵌入式的數據庫
局限性一:
並發。SQLite的鎖機制是粗粒度的,它允許多個讀,但是一次只允許一個寫。 寫鎖會在寫期間排他地鎖定數據庫,其他人在此期間不能訪問數據庫。 SQLite已經采取措施以最小化排它鎖所占用的時間。 通常來講,SQLite中的鎖只保持幾毫秒。 但是按照一般經驗,如果您的應用程序有很高的寫並發(許多連接競爭向同一數據庫寫),並且是時間關鍵型,您可能需要其他數據庫。 需要實際測試您的應用程序才能知道能獲得怎樣的性能。 一個簡單的網絡應用程序中,SQLite用100個並發連接每秒處理500多個事務。 事務所修改的記錄數以及查詢所涉及的復雜性可能有所不同。 什么樣的並發性是可接受的,這取決於具體的應用程序,只能通過直接測試來判斷。 總之,對任何數據庫都是真理:直到您做了實際測試才能知道應用程序能獲得怎樣的性能。 |
局限性二:
網絡。 雖然SQLite數據庫可以通過網絡文件系統共享,但是與這種文件系統相關的潛在延時會導致性能受損。 更糟的是,網絡文件系統實現中的一些缺陷也使得打開和修改遠程文件--SQLite或其他--很容易出錯。 如果文件系統的鎖實現不當,可能允許兩個客戶端同時修改同一個數據庫文件,這樣必然會導致數據庫出錯。 實際上,並不是因為SQLite的實現導致SQLite不能在網絡文件系統上工作。 相反,SQLite在底層文件系統和有線協議下工作,但是這些技術有時並不完善。 例如,許多NFS使用有缺陷的fcntl(),這意味着鎖可能並不像設想的那樣工作。 一些較新版本的NFS,如Solaris NFSV4就可以工作正常,SQLite需要的鎖機制也是相當可靠的。 然而,SQLite開發者既沒有時間,也沒有資源去驗證任何給定的網絡文件系統在所有的情況下都可以無缺陷工作。 |
局限說明:
絕大部分限制是有意設計的--它們是SQLite設計的結果。 例如,支持高度的寫並發會帶來很大的復雜性,這將使SQLite的簡單性無法保持。 同樣,作為嵌入式數據庫,SQLite是有意不支持網絡的。 這一點並不奇怪。總之,SQLite不能做的都是它所能做的直接結果。 它開始的設計就是一款模塊化、簡單、緊湊的以及易於使用的嵌入式關系數據庫,它的基礎代碼都在使用它的程序員的掌握范圍內。 從多方面看,它能完成許多其他數據庫不能做的事情,例如,運行在電力消耗實際上是一項制約因素的嵌入式環境中。 |
sqlite未實現的特性:
1 完整的觸發器支持。 2 SQLite支持幾乎所有的標准觸發器功能,包括遞歸觸發器和INSTEAD OF觸發器。 3 但是對於所有的觸發器類型,當受觸發器查詢影響的每一行做評估時,SQLite需要FOR EACH ROW行為。 4 ANSI SQL92也說明了當前不支持FOR EACH STATEMENT。 5 6 完整的修改表結構支持。 7 目前只支持RENAME TABLE和ADD COLUMN類型的ALTER TABLE命令。 8 其他類型的ALTER TABLE操作, 9 例如DROP COLUMN、ALTER COLUMN以及ADD CONSTRAINT還未實現。 10 11 右外連接與全外連接。 12 左外連接(LEFT OUT JOIN)已經支持,但是右外連接(RIGHT OUTER JOIN)和全外連接(FULL OUTER JOIN)還未實現。 13 所有的右外連接在語義上都有相同的左外連接,相反也成立。 14 通過簡單逆向表的順序和修改連接限制,左外連接可以作為右外連接的實現。 15 全外連接可以通過組合左外連接和UNION以及在WHERE子句中進行恰當的NULL過濾實現。 16 17 可更新的視圖。 18 SQLite的視圖使只讀的, 19 您不能在視圖上執行DELETE、INSERT或者UPDATE語句。 20 但是您可以創建一個啟動對視圖進行DELETE、INSERT或者UPDATE的觸發器, 21 在觸發器內完成您需要執行的操作。 22 23 窗口功能。 24 ANSI SQL99的新功能之一就是窗口功能。 25 該功能提供結果集的后處理分析,例如排序、平均移動以及超前和滯后計算等。 26 SQLite目前支持ANSI SQL92的一部分,因此,它不支持像RANK()、ROW_NUMBER()等。 27 28 授權和撤銷。 29 由於SQLite能讀寫普通的磁盤文件, 30 因此,唯一可以應用的訪問權限就是所在操作系統的普通文件的訪問權限。 31 授權(GRANT)和撤銷(REVOKE)命令一般是在高端系統中使用的, 32 這些系統中有多個用戶,不同用戶對數據庫中的數據有不同的訪問級別。 33 SQLite模型中,應用程序是主用戶,能夠訪問整個數據庫。這種模型中的訪問明確定義為應用程序級--具體地說,就是應用程序可以訪問數據庫文件。 34 35 除了這里列出的,SQLite Wiki上有個專門的頁面列出SQLite不支持的SQL。網址是www.sqlite.org/cvstrac/wiki?p=UnsupportedSql。
不支持外鍵約束
◇網絡文件系統(以下簡稱NFS)
有時候需要訪問其它機器上的SQLite數據庫文件,就會把數據庫文件放置到網絡共享目錄上。這時候你就要小心了。當SQLite文件放置於NFS時,在並發讀寫的情況下可能會出問題(比如數據損壞)。原因據說是由於某些NFS的文件鎖實現上有Bug。
1:SQLITE不可儲存過多的數據庫,它的性能發揮最好只能在存放較小的數據量情況下。不要把它當做MYSQL甚至ORACLE來使用。它只是一個200K的數據庫。
2:sqlite3不像MYSQL那樣使用固定日志文件,所有使用insert、update、delete的運行效率只是一般,sqlite3的一個事務,需要調用 4次 fsync()操作,而一般的大型數據庫,如mysql只用到了2次。sqlite3對每個事務都創建一個臨時文件來記錄日志,這個日志創建、更新和刪除竟然使用了3次 fsync()!為什么不用一個固定的日志文件呢?實在難以理解設計者的思路。可能他們把重點放在 "Select"
1 參考鏈接:http://blog.csdn.net/yuzhouxiang/article/details/7373111