小巧、快速、可靠。
任選三項。
任選三項。
SQLite 不能直接與用戶端/伺服器 SQL 資料庫引擎（例如 MySQL、Oracle、PostgreSQL 或 SQL Server）相比，因為 SQLite 試圖解決的是不同的問題。
用戶端/伺服器 SQL 資料庫引擎致力於實現企業資料的共享儲存庫。它們強調可擴展性、並行性、集中化和控制。SQLite 致力於為個別應用程式和設備提供本地資料儲存。SQLite 強調經濟性、效率、可靠性、獨立性和簡潔性。
SQLite 並非與用戶端/伺服器資料庫競爭。SQLite 的競爭對手是 fopen()。
由於 SQLite 資料庫不需要管理，因此它非常適用於必須在沒有專業人員支援的情況下運作的設備。SQLite 非常適合用於手機、機上盒、電視、遊戲機、相機、手錶、廚房電器、恆溫器、汽車、機床、飛機、遠端感測器、無人機、醫療設備和機器人：也就是「物聯網」。
用戶端/伺服器資料庫引擎設計用於位於網路核心的精心維護的資料中心內。SQLite 在那裡也能運作，但 SQLite 也能在網路邊緣蓬勃發展，在為應用程式提供快速可靠的資料服務的同時自給自足，否則這些應用程式將會連線不穩。
應用程式檔案格式
SQLite 常被用作桌面應用程式的磁碟檔案格式，例如版本控制系統、財務分析工具、媒體目錄和編輯套件、CAD 軟體包、記錄保存程式等等。「檔案/開啟」操作會呼叫 sqlite3_open() 來附加到資料庫檔案。應用程式內容修改時會自動更新，因此「檔案/儲存」選單選項變得多餘。「檔案/另存新檔」選單選項可以使用 備份 API 來實現。
這種方法有很多好處，包括提高效能、降低成本和複雜性，以及提高可靠性。有關更多資訊，請參閱技術說明 「aff_short.html」 和 「appfileformat.html」 以及 「fasterthanfs.html」。此用例與下面的 資料傳輸格式 和 資料容器 用例密切相關。
網站
SQLite 非常適合作為大多數低到中等流量網站（也就是說，大多數網站）的資料庫引擎。SQLite 可以處理的網路流量取決於網站使用資料庫的程度。一般來說，任何每天點擊量少於 10 萬次的網站都應該可以正常使用 SQLite。每天 10 萬次點擊量是一個保守估計，而不是硬性上限。SQLite 已被證明可以處理 10 倍的流量。
SQLite 網站 (https://www.sqlite.org/) 當然也使用 SQLite，截至撰寫本文時（2015 年），它每天處理大約 40 萬到 50 萬個 HTTP 請求，其中大約 15-20% 是觸及資料庫的動態頁面。動態內容在每個網頁上使用 大約 200 個 SQL 陳述式。此設定在單個虛擬機器上運行，該虛擬機器與其他 23 個虛擬機器共享一台實體伺服器，但大多數時候仍將負載平均值保持在 0.1 以下。
資料分析
了解 SQL 的人可以使用 sqlite3 命令列介面（或各種第三方 SQLite 存取程式）來分析大型資料集。原始資料可以從 CSV 檔案匯入，然後可以對這些資料進行切割和篩選，以產生各式各樣的摘要報告。更複雜的分析可以使用以 Tcl 或 Python（兩者都內建 SQLite）編寫的簡單腳本，或者使用 R 或其他語言搭配現成的轉接器來完成。可能的用途包括網站日誌分析、運動統計分析、編譯程式設計指標和分析實驗結果。許多生物資訊學研究人員都以這種方式使用 SQLite。
當然，同樣的事情也可以使用企業級用戶端/伺服器資料庫來完成。SQLite 的優點是它更容易安裝和使用，而且產生的資料庫是一個單一檔案，可以寫入 USB 隨身碟或透過電子郵件傳送給同事。
企業資料的快取
許多應用程式使用 SQLite 作為企業關聯式資料庫管理系統 (RDBMS) 中相關內容的快取。這可以減少延遲，因為現在大多數查詢都是針對本地快取進行，避免了網路往返。它還可以減少網路和中央資料庫伺服器的負載。而且在許多情況下，這意味著用戶端應用程式可以在網路中斷期間繼續運作。
伺服器端資料庫
系統設計人員回報，在資料中心執行的伺服器應用程式上使用 SQLite 作為資料儲存庫已獲得成功，換句話說，就是使用 SQLite 作為應用程式特定資料庫伺服器的底層儲存引擎。
使用這種模式，整體系統仍然是用戶端/伺服器：用戶端透過網路向伺服器發送請求並取回回覆。但用戶端請求和伺服器回應不是發送泛型 SQL 並取回原始表格內容，而是高階且應用程式特定的。伺服器將請求轉換為多個 SQL 查詢，收集結果，進行後處理、過濾和分析，然後建構僅包含必要資訊的高階回覆。
開發人員回報，在這種情況下，SQLite 通常比用戶端/伺服器 SQL 資料庫引擎更快。資料庫請求由伺服器序列化，因此並行性不是問題。透過「資料庫分片」也改善了並行性：為不同的子網域使用單獨的資料庫檔案。例如，伺服器可能為每個使用者都有一個單獨的 SQLite 資料庫，這樣伺服器就可以處理數百或數千個同步連線，但每個 SQLite 資料庫都只由一個連線使用。
資料傳輸格式
由於 SQLite 資料庫是一個採用明確定義的跨平台格式的單一精簡檔案，因此它經常被用作在不同系統之間傳輸內容的容器。傳送者將內容收集到一個 SQLite 資料庫檔案中，將該檔案傳輸給接收者，然後接收者使用 SQL 根據需要提取內容。
即使端點具有不同的字長和/或位元組順序，SQLite 資料庫也能促進系統之間的資料傳輸。資料可以是大型二進位 blob、文字以及小型數值或布林值的複雜組合。可以透過新增表格和/或欄位輕鬆擴展資料格式，而不會破壞舊版接收者。SQL 查詢語言意味著接收者不需要一次解析整個傳輸，而是可以根據需要查詢接收到的內容。資料格式是「透明的」，因為可以使用來自多個供應商的各種普遍可用的開源工具輕鬆解碼以供人類檢視。
檔案歸檔和/或資料容器
SQLite 歸檔概念展示了如何使用 SQLite 作為 ZIP 歸檔或 Tarball 的替代品。儲存在 SQLite 中的檔案歸檔只比同等的 ZIP 歸檔略大一點，在某些情況下實際上更小。而且 SQLite 歸檔具有增量和原子更新的功能，並且能夠儲存更豐富的元資料。
Fossil 2.5 版及之後的版本除了傳統的 tarball 和 ZIP 封存檔之外，還提供 SQLite 封存檔 作為下載格式。sqlite3.exe 命令列 shell 3.22.0 版及之後的版本可以使用 .archive 命令 建立、列出或解壓縮 SQL 封存檔。
對於任何需要將不同內容捆綁成一個自包含且自描述的套件，以便通過網路傳輸的情況，SQLite 都是一個很好的解決方案。內容以 定義明確、跨平台且穩定的檔案格式 進行編碼。這種編碼效率很高，接收者可以提取內容的一小部分，而無需讀取和解析整個檔案。
SQL 封存檔可用作軟體或內容更新的分發格式，廣播給許多客戶端。例如，這種想法的變體用於將電視節目指南傳輸到機上盒，以及通過無線方式將更新傳送到車輛導航系統。
取代臨時磁碟檔案
許多程式使用 fopen()、fread() 和 fwrite() 來建立和管理自訂格式的資料檔案。SQLite 非常適合取代這些臨時資料檔案。與直覺相反，在讀寫磁碟內容方面，SQLite 可以比檔案系統 更快。
內部或臨時資料庫
對於需要以各種方式篩選和排序大量資料的程式，將資料載入到記憶體中的 SQLite 資料庫，並使用帶有 JOIN 和 ORDER BY 子句的查詢來提取所需格式和順序的資料，通常比手動編寫相同的操作更容易、更快速。以這種方式在內部使用 SQL 資料庫還可以使程式具有更大的靈活性，因為可以新增新的欄位和索引，而無需重新編寫每個查詢。
在展示或測試期間替代企業資料庫
用戶端應用程式通常使用允許連接到各種 SQL 資料庫引擎的通用資料庫介面。將 SQLite 納入支援的資料庫組合，並將 SQLite 引擎靜態連結到用戶端中是很有意義的。這樣，用戶端程式就可以獨立使用 SQLite 資料檔案進行測試或展示。
教育和訓練
由於 SQLite 設定和使用簡單（安裝非常簡單：只需將 sqlite3 或 sqlite3.exe 可執行檔複製到目標機器並運行即可），因此 SQLite 是一個很好的資料庫引擎，可用於 SQL 教學。學生可以輕鬆建立任意數量的資料庫，並且可以將資料庫通過電子郵件發送給教師以供評論或評分。對於有興趣研究 RDBMS 如何實現的更進階的學生來說，模組化且註釋和文件完善的 SQLite 程式碼可以作為一個很好的基礎。
實驗性 SQL 語言擴充功能
SQLite 簡單、模組化的設計使其成為原型設計新的、實驗性資料庫語言特性或想法的良好平台。
用戶端/伺服器應用程式
如果有多個用戶端程式通過網路將 SQL 傳送到同一個資料庫，則應使用用戶端/伺服器資料庫引擎，而不是 SQLite。SQLite 可以在網路檔案系統上運行，但由於大多數網路檔案系統都存在延遲，因此效能不會很好。此外，許多網路檔案系統實現（在 Unix 和 Windows 上）中的檔案鎖定邏輯都有錯誤。如果檔案鎖定無法正常工作，兩個或多個用戶端可能會嘗試同時修改同一個資料庫的同一部分，從而導致資料損壞。由於此問題是由底層檔案系統實現中的錯誤引起的，因此 SQLite 無法採取任何措施來防止它。
一個好的經驗法則是避免在多台電腦通過網路同時直接存取（沒有中間應用程式伺服器）同一個資料庫的情況下使用 SQLite。
高流量網站
SQLite 通常可以很好地作為網站的資料庫後端。但如果網站寫入密集，或者繁忙到需要多台伺服器，那麼請考慮使用企業級的客戶端/伺服器資料庫引擎，而不是 SQLite。
非常大的資料集
SQLite 資料庫的大小限制為 281 TB（248 位元組，256 TiB）。即使它可以處理更大的資料庫，SQLite 也會將整個資料庫儲存在單個磁碟檔案中，而許多檔案系統會將檔案的最大大小限制在低於此值的範圍內。因此，如果您正在考慮這種規模的資料庫，最好考慮使用客戶端/伺服器資料庫引擎，它將其內容分散到多個磁碟檔案中，甚至可能分散到多個磁碟區中。
高併發性
SQLite 支援無限數量的同時讀取器，但它在任何時刻只允許一個寫入器。在許多情況下，這不是問題。寫入器會排隊。每個應用程式都能快速完成其資料庫工作並繼續執行，並且任何鎖定的持續時間都不會超過幾十毫秒。但是，有些應用程式需要更高的併發性，而這些應用程式可能需要尋找不同的解決方案。
資料與應用程式是否透過網路分隔？→ 選擇客戶端/伺服器
關聯式資料庫引擎充當減少頻寬的資料篩選器。因此，最好將資料庫引擎和資料保存在同一個實體裝置上，這樣高頻寬的引擎到磁碟連結就不必穿越網路，只有較低頻寬的應用程式到引擎連結才需要。
但 SQLite 是內建於應用程式中的。因此，如果資料與應用程式位於不同的裝置上，則需要透過網路建立更高頻寬的引擎到磁碟連結。這是可行的，但並非最佳做法。因此，當資料與應用程式位於不同的裝置上時，通常最好選擇客戶端/伺服器資料庫引擎。
請注意：在此規則中，「應用程式」是指發出 SQL 陳述式的程式碼。如果「應用程式」是應用程式伺服器，並且內容與應用程式伺服器位於同一台實體機器上，那麼即使最終使用者在另一個網路節點之外，SQLite 可能仍然適用。
許多並行寫入器？→ 選擇客戶端/伺服器
如果許多執行緒和/或程序需要同時寫入資料庫（並且它們無法排隊輪流執行），那麼最好選擇支援該功能的資料庫引擎，這通常意味著客戶端/伺服器資料庫引擎。
SQLite 每個資料庫檔案一次只支援一個寫入器。但在大多數情況下，寫入事務只需幾毫秒，因此多個寫入器可以簡單地輪流執行。SQLite 可以處理比許多人想像的更多的寫入併發性。儘管如此，客戶端/伺服器資料庫系統因為有一個長期執行的伺服器程序來協調存取，通常可以處理比 SQLite 更多的寫入併發性。
大數據？→ 選擇客戶端/伺服器
如果您的資料將增長到您不願意或無法放入單個磁碟檔案的大小，那麼您應該選擇 SQLite 以外的解決方案。SQLite 支援最大 281 TB 的資料庫，前提是您可以找到支援 281 TB 檔案的磁碟機和檔案系統。即便如此，當內容大小看起來可能會達到 TB 級別時，最好考慮使用集中式的客戶端/伺服器資料庫。
否則 → 選擇 SQLite！
對於寫入器併發性低且內容少於 1 TB 的裝置本地儲存，SQLite 幾乎總是更好的解決方案。SQLite 快速可靠，不需要任何配置或維護。它讓事情保持簡單。SQLite「就是好用」。
本頁面最後修改時間：2024 年 4 月 3 日 17:48:26 UTC