SQLITE深入
SQLITE深入------常見問題
如何建立自動增長字段?
簡短回答：聲明為 INTEGER PRIMARY KEY 的列將會自動增長。
長一點的答案： 如果你聲明表的一列為 INTEGER PRIMARY KEY，那么， 每當(dāng)你在該列上插入一NULL值時， NULL自動被轉(zhuǎn)換為一個比該列中最大值大1的一個整數(shù)，如果表是空的， 將會是1。 (如果是最大可能的主鍵 9223372036854775807，那個，將鍵值將是隨機(jī)未使用的數(shù)。） 如，有下列表：
CREATE TABLE t1(
a INTEGER PRIMARY KEY,
b INTEGER
);
在該表上，下列語句
INSERT INTO t1 VALUES(NULL,123);
在邏輯上等價于：
INSERT INTO t1 VALUES((SELECT max(a) FROM t1)+1,123);
有一個新的API叫做 sqlite3_last_insert_rowid()， 它將返回最近插入的整數(shù)值。注 意該整數(shù)會比表中該列上的插入之前的最大值大1。 該鍵值在當(dāng)前的表中是唯一的。但有可能與已從表中刪除的值重疊。 要想建立在整個表的生命周期中唯一的鍵值，需要在 INTEGER PRIMARY KEY 上增加AUTOINCREMENT聲明。那么，新的鍵值將會比該表中曾能存在過的最大值大1。 如果最大可能的整數(shù)值在數(shù)據(jù)表中曾經(jīng)存在過，INSERT將會失敗， 并返回SQLITE_FULL錯誤代碼。
多個應(yīng)用程序或一個應(yīng)用程序的多個實例可以同時訪問同一個數(shù)據(jù)庫文件嗎？
多個進(jìn)程可同時打開同一個數(shù)據(jù)庫。多個進(jìn)程可以同時進(jìn)行SELECT 操作，但在任一時刻，只能有一個進(jìn)程對數(shù)據(jù)庫進(jìn)行更改。
SQLite使用讀、寫鎖控制對數(shù)據(jù)庫的訪問。（在Win95/98/ME等不支持讀、 寫鎖的系統(tǒng)下，使用一個概率性的模擬來代替。）但使用時要注意： 如果數(shù)據(jù)庫文件存放于一個NFS文件系統(tǒng)上，這種鎖機(jī)制可能不能正常工作。 這是因為 fcntl() 文件鎖在很多NFS上沒有正確的實現(xiàn)。 在可能有多個進(jìn)程同時訪問數(shù)據(jù)庫的時候，應(yīng)該避免將數(shù)據(jù)庫文件放到NFS上。 在Windows上，Microsoft的文檔中說：如果使用 FAT 文件系統(tǒng)而沒有運(yùn)行 share.exe 守護(hù)進(jìn)程，那么鎖可能是不能正常使用的。那些在Windows上有很多經(jīng)驗的人告訴我： 對于網(wǎng)絡(luò)文件，文件鎖的實現(xiàn)有好多Bug，是靠不住的。如果他們說的是對的， 那么在兩臺或多臺Windows機(jī)器間共享數(shù)據(jù)庫可能會引起不期望的問題。
我們意識到，沒有其它嵌入式的 SQL 數(shù)據(jù)庫引擎能象 SQLite 這樣處理如此多的并發(fā)。SQLite允許多個進(jìn)程同時打開一個數(shù)據(jù)庫， 同時讀一個數(shù)據(jù)庫。當(dāng)有任何進(jìn)程想要寫時，它必須在更新過程中鎖住數(shù)據(jù)庫文件。 但那通常只是幾毫秒的時間。其它進(jìn)程只需等待寫進(jìn)程干完活結(jié)束。 典型地，其它嵌入式的SQL數(shù)據(jù)庫引擎同時只允許一個進(jìn)程連接到數(shù)據(jù)庫。
但是，Client/Server數(shù)據(jù)庫引擎（如 PostgreSQL, MySQL, 或 Oracle） 通常支持更高級別的并發(fā)，并且允許多個進(jìn)程同時寫同一個數(shù)據(jù)庫。 這種機(jī)制在Client/Server結(jié)構(gòu)的數(shù)據(jù)庫上是可能的， 因為總是有一個單一的服務(wù)器進(jìn)程很好地控制、協(xié)調(diào)對數(shù)據(jù)庫的訪問。 如果你的應(yīng)用程序需要很多的并發(fā)，那么你應(yīng)該考慮使用一個Client/Server 結(jié)構(gòu)的數(shù)據(jù)庫。但經(jīng)驗表明，很多應(yīng)用程序需要的并發(fā)，往往比其設(shè)計者所想象的少得多。
當(dāng)SQLite試圖訪問一個被其它進(jìn)程鎖住的文件時，缺省的行為是返回 SQLITE_BUSY。 可以在C代碼中使用 sqlite3_busy_handler() 或 sqlite3_busy_timeout() API 函數(shù)調(diào)整這一行為。
在SQLite數(shù)據(jù)庫中如何列出所有的表和索引？
如果你運(yùn)行 sqlite3 命令行來訪問你的數(shù)據(jù)庫，可以鍵入 “.tables”來獲得所有表的列表。或者，你可以輸入 “.schema” 來看整個數(shù)據(jù)庫模式，包括所有的表的索引。 輸入這些命令，后面跟一個LIKE模式匹配可以限制顯示的表。
在一個 C/C++ 程序中（或者腳本語言使用 Tcl/Ruby/Perl/Python 等） 你可以在一個特殊的名叫 SQLITE_MASTER 上執(zhí)行一個SELECT查詢以獲得所有 表的索引。每一個 SQLite 數(shù)據(jù)庫都有一個叫 SQLITE_MASTER 的表， 它定義數(shù)據(jù)庫的模式。 SQLITE_MASTER 表看起來如下：
CREATE TABLE sqlite_master (
type TEXT,
name TEXT,
tbl_name TEXT,
rootpage INTEGER,
sql TEXT
);
對于表來說，type 字段永遠(yuǎn)是 'table'，name 字段永遠(yuǎn)是表的名字。所以，要獲得數(shù)據(jù)庫中所有表的列表， 使用下列SELECT語句：
SELECT name FROM sqlite_master
WHERE type='table'
ORDER BY name;
對于索引，type 等于 'index', name 則是索引的名字，tbl_name 是該索引所屬的表的名字。 不管是表還是索引，sql 字段是原先用 CREATE TABLE 或 CREATE INDEX 語句創(chuàng)建它們時的命令文本。對于自動創(chuàng)建的索引（用來實現(xiàn) PRIMARY KEY 或 UNIQUE 約束），sql字段為NULL。
SQLITE_MASTER 表是只讀的。不能對它使用 UPDATE、INSERT 或 DELETE。 它會被 CREATE TABLE、CREATE INDEX、DROP TABLE 和 DROP INDEX 命令自動更新。
臨時表不會出現(xiàn)在 SQLITE_MASTER 表中。臨時表及其索引和觸發(fā)器存放在另外一個叫 SQLITE_TEMP_MASTER 的表中。SQLITE_TEMP_MASTER 跟 SQLITE_MASTER 差不多， 但它只是對于創(chuàng)建那些臨時表的應(yīng)用可見。如果要獲得所有表的列表， 不管是永久的還是臨時的，可以使用類似下面的命令：
SELECT name FROM
(SELECT * FROM sqlite_master UNION ALL
SELECT * FROM sqlite_temp_master)
WHERE type='table'
ORDER BY name
在SQLite中，VARCHAR字段最長是多少？
SQLite 不強(qiáng)制 VARCHAR 的長度。 你可以在 SQLITE 中聲明一個 VARCHAR(10)，SQLite還是可以很高興地允許你放入500個字符。 并且這500個字符是原封不動的，它永遠(yuǎn)不會被截斷。
SQLite支持二進(jìn)制大對象嗎？
SQLite 3.0 及以后版本允許你在任何列中存儲 BLOB 數(shù)據(jù)。 即使該列被聲明為其它類型也可以。
在SQLite中，如何在一個表上添加或刪除一列？
SQLite 有有限地 ALTER TABLE 支持。你可以使用它來在表的末尾增加一列，可更改表的名稱。 如果需要對表結(jié)構(gòu)做更復(fù)雜的改變，則必須重新建表。 重建時可以先將已存在的數(shù)據(jù)放到一個臨時表中，刪除原表， 創(chuàng)建新表，然后將數(shù)據(jù)從臨時表中復(fù)制回來。
如，假設(shè)有一個 t1 表，其中有 "a", "b", "c" 三列， 如果要刪除列 c ，以下過程描述如何做:
BEGIN TRANSACTION;
CREATE TEMPORARY TABLE t1_backup(a,b);
INSERT INTO t1_backup SELECT a,b FROM t1;
DROP TABLE t1;
CREATE TABLE t1(a,b);
INSERT INTO t1 SELECT a,b FROM t1_backup;
DROP TABLE t1_backup;
COMMIT;
在數(shù)據(jù)庫中刪除了很多數(shù)據(jù)，但數(shù)據(jù)庫文件沒有變小，是Bug嗎？
不是。當(dāng)你從SQLite數(shù)據(jù)庫中刪除數(shù)據(jù)時， 未用的磁盤空間將會加入一個內(nèi)部的“自由列表”中。 當(dāng)你下次插入數(shù)據(jù)時，這部分空間可以重用。磁盤空間不會丟失， 但也不會返還給操作系統(tǒng)。
如果刪除了大量數(shù)據(jù)，而又想縮小數(shù)據(jù)庫文件占用的空間，執(zhí)行 VACUUM 命令。 VACUUM 將會從頭重新組織數(shù)據(jù)庫。這將會使用數(shù)據(jù)庫有一個空的“自由鏈表”， 數(shù)據(jù)庫文件也會最小。但要注意的是，VACUUM 的執(zhí)行會需要一些時間 （在SQLite開發(fā)時，在Linux上，大約每M字節(jié)需要半秒種），并且， 執(zhí)行過程中需要原數(shù)據(jù)庫文件至多兩倍的臨時磁盤空間。
對于 SQLite 3.1版本，一個 auto-vacumm 模式可以替代 VACUUM 命令。 可以使用 auto_vacuum pragma 打開。
SQLITE_SCHEMA error是什么錯誤？為什么會出現(xiàn)該錯誤？
當(dāng)一個準(zhǔn)備好的（prepared）SQL語句不再有效或者無法執(zhí)行時， 將返回一個 SQLITE_SCHEMA 錯誤。發(fā)生該錯誤時，SQL語句必須使用 sqlite3_prepare() API來重新編譯. 在 SQLite 3 中, 一個 SQLITE_SCHEMA 錯誤只會發(fā)生在用 sqlite3_prepare()/sqlite3_step()/sqlite3_finalize() API 執(zhí)行 SQL 時。而不會發(fā)生在使用 sqlite3_exec()時。 在版本2中不是這樣。
準(zhǔn)備好的語句失效的最通常原因是：在語句準(zhǔn)備好后， 數(shù)據(jù)庫的模式又被修改了。另外的原因會發(fā)生在：
數(shù)據(jù)庫離線：DETACHed.
數(shù)據(jù)庫被 VACUUMed
一個用戶存儲過程定義被刪除或改變。
一個 collation 序列定義被刪除或改變。
認(rèn)證函數(shù)被改變。
在所有情況下，解決方法是重新編譯并執(zhí)行該SQL語句。 因為一個已準(zhǔn)備好的語句可以由于其它進(jìn)程改變數(shù)據(jù)庫模式而失效， 所有使用 sqlite3_prepare()/sqlite3_step()/sqlite3_finalize() API 的代碼都應(yīng)準(zhǔn)備處理 SQLITE_SCHEMA 錯誤。下面給出一個例子：
int rc;
sqlite3_stmt *pStmt;
char zSql[] = "SELECT .....";
??? do {
/* Compile the statement from SQL. Assume success. */
sqlite3_prepare(pDb, zSql, -1, &pStmt, 0);
????? while( SQLITE_ROW==sqlite3_step(pStmt) ){
/* Do something with the row of available data */
}
????? /* Finalize the statement. If an SQLITE_SCHEMA error has
** occured, then the above call to sqlite3_step() will have
** returned SQLITE_ERROR. sqlite3_finalize() will return
** SQLITE_SCHEMA. In this case the loop will execute again.
*/
rc = sqlite3_finalize(pStmt);
} while( rc==SQLITE_SCHEMA );
?
如何在字符串中使用單引號(')？
SQL 標(biāo)準(zhǔn)規(guī)定，在字符串中，單引號需要使用逃逸字符，即在一行中使用兩個單引號。在這方面 SQL 用起來類似 Pascal 語言。 SQLite 尊循標(biāo)準(zhǔn)。如：
??? INSERT INTO xyz VALUES('5 O''clock');
Sqlite中如何返回本地化當(dāng)前時間？
在做ClinicOS的時候遇到一個問題，在保存病歷登記時間時，我使用了“CURRENT_TIMESTAMP”，但這有個問題，它返回的是UTC Time，這對我們中國人沒啥用，一直希望能想辦法將它轉(zhuǎn)為localtime。今天剛好有空，所以去查了查Sqlite的Mail List，果然也有人遇到了這個問題，我從一篇名為《translate time comparison statement》（http://www.mail-archive.com/sqlite-users@sqlite.org /msg12350.html）中看到這樣的回復(fù)：
WHERE julianday(date('now')) - julianday(date(arrival_date)) > 7Mark,
You should still use the 'localtime' modifier on the 'now' value if your timestamps are local time since 'now' always returns UTC times.
WHERE julianday(date('now', 'localtime')) - julianday(date(arrival_date)) > 7嘿嘿，看來如果想得到一個符合本機(jī)區(qū)域設(shè)置的當(dāng)前時間，必須用date函數(shù)來轉(zhuǎn)換，
但date只函數(shù)只返回當(dāng)前日期，而我需要的是返回當(dāng)前日期及時間，所以這里把它換成datetime函數(shù)，即：
datetime(CURRENT_TIMESTAMP,'localtime')
以下是sqlite下測試的輸出信息：
sqlite> select CURRENT_TIMESTAMP;
2006-06-18 09:23:36
sqlite> select datetime(CURRENT_TIMESTAMP,'localtime');
2006-06-18 17:23:44
sqlite>
SQLITE分頁
剛開始的時候沒注意語法
后來才發(fā)現(xiàn)，原來用SQLite分頁是世界上最簡單的。
如果我要去11-20的Account表的數(shù)據(jù)
Select * From Account Limit?9 Offset 10;
以上語句表示從Account表獲取數(shù)據(jù)，跳過10行，取9行
嗯，我覺得這個特性足夠讓很多的web中型網(wǎng)站使用這個了。
也可以這樣寫 select * from account limit10,9和上面的的效果一樣。
這種寫法MySQL也支持。
?
SQLite不同于其他大部分的SQL數(shù)據(jù)庫引擎,因為它的首要設(shè)計目標(biāo)就是簡單化:
易于管理
易于使用
易于嵌入其他大型程序
易于維護(hù)和配置
許多人喜歡SQLite因為它的小巧和快速. 但是這些特性只是它的部分優(yōu)點, 使用者還會發(fā)現(xiàn)SQLite是非常穩(wěn)定的. 出色的穩(wěn)定性源于它的簡單, 越簡單就越不容易出錯. 除了上述的簡單、小巧和穩(wěn)定性外, 最重要的在于SQLite力爭做到簡單化.
簡單化在一個數(shù)據(jù)庫引擎中可以說是一個優(yōu)點, 但也可能是個缺點, 主要決定于你想要做什么. 為了達(dá)到簡單化, SQLite省略了一些人們認(rèn)為比較有用的特性, 例如高并發(fā)性、 嚴(yán)格的存取控制、 豐富的內(nèi)置功能、 存儲過程、復(fù)雜的SQL語言特性、 XML以及Java的擴(kuò)展, 超大的萬億級別的數(shù)據(jù)測量等等. 如果你需要使用上述的這些特性并且不介意它們的復(fù)雜性, 那么SQLite也許就不適合你了. SQLite沒有打算作為一個企業(yè)級的數(shù)據(jù)庫引擎, 也并不打算和Oracle或者PostgreSQL競爭.
僅憑經(jīng)驗來說SQLite適用于以下場合: 當(dāng)你更看中簡單的管理、使用和維護(hù)數(shù)據(jù)庫, 而不是那些企業(yè)級數(shù)據(jù)庫提供的不計其數(shù)的復(fù)雜功能的時候，使用SQLite是一個比較明智的選擇. 事實也證明, 人們在許多情況下已經(jīng)清楚的認(rèn)識到簡單就是最好的選擇.
SQLite最佳試用場合
網(wǎng)站
作為數(shù)據(jù)庫引擎SQLite適用于中小規(guī)模流量的網(wǎng)站(也 就是說, 99.9%的網(wǎng)站). SQLite可以處理多少網(wǎng)站流量在于網(wǎng)站的數(shù)據(jù)庫有多大的壓力. 通常來說, 如果一個網(wǎng)站的點擊率少于100000次/天的話, SQLite是可以正常運(yùn)行的. 100000次/天是一個保守的估計, 不是一個準(zhǔn)確的上限. 事實證明, 即使是10倍的上述流量的情況下SQLite依然可以正常運(yùn)行.
嵌入式設(shè)備和應(yīng)用軟件
因為SQLite數(shù)據(jù)庫幾乎不需要管理, 因此對于那些無人值守運(yùn)行或無人工技術(shù)支持的設(shè)備或服務(wù), SQLite是一個很好的選擇. SQLite能很好的適用于手機(jī), PDA, 機(jī)頂盒, 以及其他儀器. 作為一個嵌入式數(shù)據(jù)庫它也能夠很好的應(yīng)用于客戶端程序.
應(yīng)用程序文件格式
SQLite作為桌面應(yīng)用程序的本地磁盤文件格式取得了巨 大成功.例如金融分析工具、CAD 包、檔案管理程序等等. 一般的數(shù)據(jù)庫打開操作需要調(diào)用sqlite3_open()函數(shù)，并且標(biāo)記一個顯式本地事務(wù)的起始點（BEGIN TRANSACTION）來保證以獨(dú)占的方式得到文件的內(nèi)容. 文件保存將執(zhí)行一個提交（COMMIT）同時標(biāo)記另一個顯式本地事務(wù)起始點. 這種事務(wù)處理的作用就是保證對于應(yīng)用程序數(shù)據(jù)文件的更新是原子的、持久的、獨(dú)立的和一致的.
數(shù)據(jù)庫里可以加入一些臨時的觸發(fā)器,用來把所有的改變記錄在一張臨時的取消/重做日志表中. 當(dāng)用戶按下取消/重做按鈕的時候這些改變將可以被回滾. 應(yīng)用這項技術(shù)實現(xiàn)一個無限級的取消/重做功能只需要編寫很少的代碼.
替代某些特別的文件格式
許多程序使用fopen(), fread(), 或 fwrite()函數(shù)創(chuàng)建和管理一些自定義的文件用來保存數(shù)據(jù). 使用SQLite替代這些自定義的文件格式將是一種很好的選擇.
內(nèi)部的或臨時的數(shù)據(jù)庫
對于那些有大量的數(shù)據(jù)需要用不同的方式篩選分類的程序, 相對于編寫同樣功能的代碼, 如果你把數(shù)據(jù)讀入一個內(nèi)存中的SQLite數(shù)據(jù)庫, 然后使用連接查詢和ORDER BY子句按一定的順序和排列提取需要的數(shù)據(jù), 通常會更簡單和快速. 按照上述的方法使用內(nèi)嵌的SQLite數(shù)據(jù)庫將會使程序更富有靈活性, 因為添加新的列或索引不用重寫任何查詢語句.
命令行數(shù)據(jù)集分析工具
有經(jīng)驗的SQL用戶可以使用SQLite命令行程序去分析各種混雜的數(shù)據(jù)集. 原是數(shù)據(jù)可以從CSV（逗號分隔值文件）文件中導(dǎo)入, 然后被切分產(chǎn)生無數(shù)的綜合數(shù)據(jù)報告. 可能得用法包括網(wǎng)站日志分析, 運(yùn)動統(tǒng)計分析, 編輯規(guī)劃標(biāo)準(zhǔn), 分析試驗結(jié)果.
當(dāng)然你也可以用企業(yè)級的客戶端/服務(wù)器數(shù)據(jù)庫來做同樣的事情. 在這種情況下使用SQLite的好處是: SQLite的部署更為簡單并且結(jié)果數(shù)據(jù)庫是一個單獨(dú)的文件, 你可以把它存儲在軟盤或者優(yōu)盤或者直接通過email發(fā)給同事.
在Demo或測試版的時候作為企業(yè)級數(shù)據(jù)庫的替代品
如果你正在編寫一個使用企業(yè)級數(shù)據(jù)庫引擎的客戶端程序, 使用一個允許你連接不同SQL數(shù)據(jù)庫引擎的通用型數(shù)據(jù)庫后臺將是很有意義的. 其更大的意義在于將SQLite數(shù)據(jù)庫引擎靜態(tài)的連接到客戶端程序當(dāng)中，從而內(nèi)嵌SQLite作為混合的數(shù)據(jù)庫支持. 這樣客戶端程序就可以使用SQLite數(shù)據(jù)庫文件做獨(dú)立的測試或者驗證.
本文來自: (www.91linux.com) 詳細(xì)出處參考：http://www.91linux.com/html/article/database/sqlite/200812/12-14611.html
?
數(shù)據(jù)庫教學(xué)
因為SQLite的安裝和使用非常的簡單(安裝過程幾乎忽略不計, 只需要拷貝SQLite源代碼或sqlite.exe可執(zhí)行文件到目標(biāo)主機(jī), 然后直接運(yùn)行就可以) 所以它非常適合用來講解SQL語句. 同學(xué)們可以非常簡單的創(chuàng)建他們喜歡的數(shù)據(jù)庫, 然后通過電子郵件發(fā)給老師批注或打分. 對于那些感興趣怎樣實現(xiàn)一個關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）的高層次的學(xué)生, 按照模塊化設(shè)計且擁有很好的注釋和文檔的SQLite源代碼, 將為他們打下良好的基礎(chǔ). 這并不是說SQLite就是如何實現(xiàn)其他數(shù)據(jù)庫引擎的精確模型, 但是很適合學(xué)生們了解SQLite是如何快速工作的, 從而掌握其他數(shù)據(jù)庫系統(tǒng)的設(shè)計實現(xiàn)原則.
試驗SQL語言的擴(kuò)展
SQLite簡單且模塊化的設(shè)計使得它可以成為一個用來測試數(shù)據(jù)庫語言特性或新想法的優(yōu)秀的原型平臺.
哪些場合適合使用其他的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）
客戶端/服務(wù)器程序
?
如果你有許多的客戶端程序要通過網(wǎng)絡(luò)訪問一個共享的數(shù)據(jù)庫, 你應(yīng)當(dāng)考慮用一個客戶端/服務(wù)器數(shù)據(jù)庫來替代SQLite. SQLite可以通過網(wǎng)絡(luò)文件系統(tǒng)工作, 但是因為和大多數(shù)網(wǎng)絡(luò)文件系統(tǒng)都存在延時, 因此執(zhí)行效率不會很高. 此外大多數(shù)網(wǎng)絡(luò)文件系統(tǒng)在實現(xiàn)文件邏輯鎖的方面都存在著bug(包括Unix 和windows). 如果文件鎖沒有正常的工作, 就可能出現(xiàn)在同一時間兩個或更多的客戶端程序更改同一個數(shù)據(jù)庫的同一部分, 從而導(dǎo)致數(shù)據(jù)庫出錯. 因為這些問題是文件系統(tǒng)執(zhí)行的時候本質(zhì)上存在的bug, 因此SQLite沒有辦法避免它們.
好的經(jīng)驗告訴我們, 應(yīng)該避免在許多計算機(jī)需要通過一個網(wǎng)絡(luò)文件系統(tǒng)同時訪問同一個數(shù)據(jù)庫的情況下使用SQLite.
高流量網(wǎng)站
SQLite通常情況下用作一個網(wǎng)站的后臺數(shù)據(jù)庫可以很好的工作. 但是如果你的網(wǎng)站的訪問量大到你開始考慮采取分布式的數(shù)據(jù)庫部署, 那么你應(yīng)當(dāng)毫不猶豫的考慮用一個企業(yè)級的客戶端/服務(wù)器數(shù)據(jù)庫來替代SQLite.
超大的數(shù)據(jù)集
當(dāng)你在SQLite中開始一個事務(wù)處理的時候(事務(wù)處理會在任何寫操作發(fā)生之前產(chǎn)生, 而不是必須要顯示的調(diào)用BEGIN...COMMIT), 數(shù)據(jù)庫引擎將不得不分配一小塊臟頁(文件緩沖頁面)來幫助它自己管理回滾操作. 每1MB的數(shù)據(jù)庫文件SQLite需要256字節(jié). 對于小型的數(shù)據(jù)庫這些空間不算什么, 但是當(dāng)數(shù)據(jù)庫增長到數(shù)十億字節(jié)的時候, 緩沖頁面的尺寸就會相當(dāng)?shù)拇罅? 如果你需要存儲或修改幾十GB的數(shù)據(jù), 你應(yīng)該考慮用其他的數(shù)據(jù)庫引擎.
高并發(fā)訪問
SQLite對于整個數(shù)據(jù)庫文件進(jìn)行讀取/寫入鎖定. 這意味著如果任何進(jìn)程讀取了數(shù)據(jù)庫中的某一部分, 其他所有進(jìn)程都不能再對該數(shù)據(jù)庫的任何部分進(jìn)行寫入操作. 同樣的, 如果任何一個進(jìn)程在對數(shù)據(jù)庫進(jìn)行寫入操作, 其他所有進(jìn)程都不能再讀取該數(shù)據(jù)庫的任何部分. 對于大多數(shù)情況這不算是什么問題. 在這些情況下每個程序使用數(shù)據(jù)庫的時間都很短暫, 并且不會獨(dú)占, 這樣鎖定至多會存在十幾毫秒. 但是如果有些程序需要高并發(fā), 那么這些程序就需要尋找其他的解決方案了。
轉(zhuǎn)載于:https://www.cnblogs.com/zzzili/archive/2012/12/06/6662793.html
總結(jié)
- 上一篇： sql每一个join都要加on
- 下一篇： 滴水穿石--MYSQL导入导出常用命令