一、 是否支持多線程？ SQLite官網上的“Is SQLite threadsafe?”這個問答。 簡單來說，從3.3.1版本開始，它就是線程安全的了。而iOS的SQLite版本沒有低於這個版本的，當然，你也可以自己編譯最新版本。 不過這個線程安全仍然是有限制的，在這篇《Is SQLite thr ...
一、 是否支持多線程？ SQLite官網上的“Is SQLite threadsafe?”這個問答。 簡單來說，從3.3.1版本開始，它就是線程安全的了。而iOS的SQLite版本沒有低於這個版本的，當然，你也可以自己編譯最新版本。
不過這個線程安全仍然是有限制的，在這篇《Is SQLite thread-safe?》里有詳細的解釋。
另一篇重要的文檔就是《SQLite And Multiple Threads》。它指出SQLite支持3種線程模式：
- 單線程：禁用所有的mutex鎖，併發使用時會出錯。當SQLite編譯時加了SQLITE_THREADSAFE=0參數，或者在初始化SQLite前調用sqlite3_config(SQLITE_CONFIG_SINGLETHREAD)時啟用。
- 多線程：只要一個資料庫連接不被多個線程同時使用就是安全的。源碼中是啟用bCoreMutex，禁用bFullMutex。實際上就是禁用資料庫連接和prepared statement（準備好的語句）上的鎖，因此不能在多個線程中併發使用同一個資料庫連接或prepared statement。當SQLite編譯時加了SQLITE_THREADSAFE=2參數時預設啟用。若SQLITE_THREADSAFE不為0，可以在初始化SQLite前，調用sqlite3_config(SQLITE_CONFIG_MULTITHREAD)啟用；或者在創建資料庫連接時，設置SQLITE_OPEN_NOMUTEX flag。
- 串列：啟用所有的鎖，包括bCoreMutex和bFullMutex。因為資料庫連接和prepared statement都已加鎖，所以多線程使用這些對象時沒法併發，也就變成串列了。當SQLite編譯時加了SQLITE_THREADSAFE=1參數時預設啟用。若SQLITE_THREADSAFE不為0，可以在初始化SQLite前，調用sqlite3_config(SQLITE_CONFIG_SERIALIZED)啟用；或者在創建資料庫連接時，設置SQLITE_OPEN_FULLMUTEX flag。
現在3種模式都有所瞭解了，清楚SQLite並不是對多線程無能為力後，接下來就瞭解下事務吧。 二、事務
資料庫只有在事務中才能被更改。所有更改資料庫的命令（除SELECT以外的所有SQL命令）都會自動開啟一個新事務，並且當最後一個查詢完成時自動提交。
而BEGIN命令可以手動開始事務，並關閉自動提交。當下一條COMMIT命令執行時，自動提交再次打開，事務中所做的更改也被寫入資料庫。當COMMIT失敗時，自動提交仍然關閉，以便讓用戶嘗試再次提交。若執行的是ROLLBACK命令，則也打開自動提交，但不保存事務中的更改。關閉資料庫或遇到錯誤時，也會自動回滾事務。
經常有人抱怨SQLite的插入太慢，實際上它可以做到每秒插入幾萬次，但是每秒只能提交幾十次事務。因此在插入大批數據時，可以通過禁用自動提交來提速。 還有一個很重要的知識點需要強調：事務是和資料庫連接相關的，每個資料庫連接（使用pager來）維護自己的事務，且同時只能有一個事務（但是可以用SAVEPOINT來實現內嵌事務）。也就是說，事務與線程無關，一個線程里可以同時用多個資料庫連接來完成多個事務，而多個線程也可以同時（非併發）使用一個資料庫連接來共同完成一個事務。 而要實現事務，就不得不用到鎖。
一個SQLite資料庫文件有5種鎖的狀態：
- UNLOCKED：表示資料庫此時並未被讀寫。
- SHARED：表示資料庫可以被讀取。SHARED鎖可以同時被多個線程擁有。一旦某個線程持有SHARED鎖，就沒有任何線程可以進行寫操作。
- RESERVED：表示準備寫入資料庫。RESERVED鎖最多只能被一個線程擁有，此後它可以進入PENDING狀態。
- PENDING：表示即將寫入資料庫，正在等待其他讀線程釋放SHARED鎖。一旦某個線程持有PENDING鎖，其他線程就不能獲取SHARED鎖。這樣一來，只要等所有讀線程完成，釋放SHARED鎖後，它就可以進入EXCLUSIVE狀態了。
- EXCLUSIVE：表示它可以寫入資料庫了。進入這個狀態後，其他任何線程都不能訪問資料庫文件。因此為了併發性，它的持有時間越短越好。
另外，read-uncommitted和WAL模式會影響這個鎖的機制。在這2種模式下，讀線程不會被寫線程阻塞，即使寫線程持有PENDING或EXCLUSIVE鎖。
提到鎖就不得不說到死鎖的問題，而SQLite也可能出現死鎖。
下麵舉個例子：
連接1：BEGIN （UNLOCKED）現在2個連接都在等待對方釋放鎖，於是就死鎖了。當然，實際情況並沒那麼糟糕，任何一方選擇不繼續等待，回滾事務就行了。
連接1：SELECT ... （SHARED）
連接1：INSERT ... （RESERVED）
連接2：BEGIN （UNLOCKED）
連接2：SELECT ... （SHARED）
連接1：COMMIT （PENDING，嘗試獲取EXCLUSIVE鎖，但還有SHARED鎖未釋放，返回SQLITE_BUSY）
連接2：INSERT ... （嘗試獲取RESERVED鎖，但已有PENDING鎖未釋放，返回SQLITE_BUSY）
不過要更好地解決這個問題，就必須更深入地瞭解事務了。
實際上BEGIN語句可以有3種起始狀態：
- DEFERRED：預設值，開始事務時不獲取任何鎖。進行第一次讀操作時獲取SHARED鎖，進行第一次寫操作時獲取RESERVED鎖。
- IMMEDIATE：開始事務時獲取RESERVED鎖。
- EXCLUSIVE：開始事務時獲取EXCLUSIVE鎖。
現在考慮2個事務在開始時都使用IMMEDIATE方式：
連接1：BEGIN IMMEDIATE （RESERVED）這樣死鎖就被避免了。
連接1：SELECT ... （RESERVED）
連接1：INSERT ... （RESERVED）
連接2：BEGIN IMMEDIATE （嘗試獲取RESERVED鎖，但已有RESERVED鎖未釋放，因此事務開始失敗，返回SQLITE_BUSY，等待用戶重試）
連接1：COMMIT （EXCLUSIVE，寫入完成後釋放）
連接2：BEGIN IMMEDIATE （RESERVED）
連接2：SELECT ... （RESERVED）
連接2：INSERT ... （RESERVED）
連接2：COMMIT （EXCLUSIVE，寫入完成後釋放）
而EXCLUSIVE方式則更為嚴苛，即使其他連接以DEFERRED方式開啟事務也不會死鎖：
連接1：BEGIN EXCLUSIVE （EXCLUSIVE）不過在併發很高的情況下，直接獲取EXCLUSIVE鎖的難度比較大；而且為了避免EXCLUSIVE狀態長期阻塞其他請求，最好的方式還是讓所有寫事務都以IMMEDIATE方式開始。
連接1：SELECT ... （EXCLUSIVE）
連接1：INSERT ... （EXCLUSIVE）
連接2：BEGIN （UNLOCKED）
連接2：SELECT ... （嘗試獲取SHARED鎖，但已有EXCLUSIVE鎖未釋放，返回SQLITE_BUSY，等待用戶重試）
連接1：COMMIT （EXCLUSIVE，寫入完成後釋放）
連接2：SELECT ... （SHARED）
連接2：INSERT ... （RESERVED）
連接2：COMMIT （EXCLUSIVE，寫入完成後釋放）
順帶一提，要實現重試的話，可以使用sqlite3_busy_timeout()或sqlite3_busy_handler()函數。
由此可見，要想保證線程安全的話，可以有這4種方式：
- SQLite使用單線程模式，用一個專門的線程訪問資料庫。
- SQLite使用單線程模式，用一個線程隊列來訪問資料庫，隊列一次只允許一個線程執行，隊列里的線程共用一個資料庫連接。
- SQLite使用多線程模式，每個線程創建自己的資料庫連接。
- SQLite使用串列模式，所有線程共用全局的資料庫連接。
解決辦法是，在調用sqlite3_open函數後添加下麵一行代碼： sqlite3_exec(db, "PRAGMA synchronous = OFF; ", 0,0,0); 上面的解決辦法貌似治標不治本，為什麼加上上面的代碼行，速度會提高那麼多？ 磁碟同步 1.如何設置： PRAGMA synchronous = FULL; (2) PRAGMA synchronous = NORMAL; (1) PRAGMA synchronous = OFF; (0)
2.參數含義： 當synchronous設置為FULL (2), SQLite資料庫引擎在緊急時刻會暫停以確定數據已經寫入磁碟。這使系統崩潰或電源出問題時能確保資料庫在重起後不會損壞。FULL synchronous很安全但很慢。
當synchronous設置為NORMAL(1), SQLite資料庫引擎在大部分緊急時刻會暫停，但不像FULL模式下那麼頻繁。 NORMAL模式下有很小的幾率(但不是不存在)發生電源故障導致資料庫損壞的情況。但實際上，在這種情況 下很可能你的硬碟已經不能使用，或者發生了其他的不可恢復的硬體錯誤。
設置為synchronous OFF (0)時，SQLite在傳遞數據給系統以後直接繼續而不暫停。若運行SQLite的應用程式崩潰， 數據不會損傷，但在系統崩潰或寫入數據時意外斷電的情況下資料庫可能會損壞。另一方面，在synchronous OFF時 一些操作可能會快50倍甚至更多。在SQLite 2中，預設值為NORMAL.而在3中修改為FULL。 www.2cto.com
3.建議： 如果有定期備份的機制，而且少量數據丟失可接受，用OFF。 註意上面紅色加粗的字樣。總結：如果你的數據對安全性完整性等要求不是太高，可以採用設置為0的方法，畢竟只是“資料庫可能會損壞”，至於損壞幾率為多大，筆者也暫不知曉。。。。。。還沒遇到過損壞，不知什麼時候才會發生。 四、性能優化（可參考http://blog.csdn.net/tietao/article/details/6890350）
很多人直接就使用了，並未註意到SQLite也有配置參數，可以對性能進行調整。有時候，產生的結果會有很大影響。
主要通過pragma指令來實現。
比如： 空間釋放、磁碟同步、Cache大小等。
1 auto_vacuum
最好不要打開auto_vacuum, Vacuum的效率非常低！
PRAGMA auto_vacuum;
PRAGMA auto_vacuum = 0 | 1;
查詢或設置資料庫的auto-vacuum標記。
正常情況下，當提交一個從資料庫中刪除數據的事務時，資料庫文件不改變大小。未使用的文件頁被標記併在以後的添加操作中再次使用。這種情況下使用VACUUM命令釋放刪除得到的空間。
當開啟auto-vacuum，當提交一個從資料庫中刪除數據的事務時，資料庫文件自動收縮， (VACUUM命令在auto-vacuum開啟的資料庫中不起作用)。資料庫會在內部存儲一些信息以便支持這一功能，這使得資料庫文件比不開啟該選項時稍微大一些。
只有在資料庫中未建任何表時才能改變auto-vacuum標記。試圖在已有表的情況下修改不會導致報錯。
2 cache_size
建議改為8000
PRAGMA cache_size;
PRAGMA cache_size = Number-of-pages;
查詢或修改SQLite一次存儲在記憶體中的資料庫文件頁數。每頁使用約1.5K記憶體，預設的緩存大小是2000. 若需要使用改變大量多行的UPDATE或DELETE命令，並且不介意SQLite使用更多的記憶體的話，可以增大緩存以提高性能。
當使用cache_size pragma改變緩存大小時，改變僅對當前對話有效，當資料庫關閉重新打開時緩存大小恢復到預設大小。 要想永久改變緩存大小，使用default_cache_size pragma.
3 case_sensitive_like
打開。不然搜索中文字串會出錯。
PRAGMA case_sensitive_like;
PRAGMA case_sensitive_like = 0 | 1;
LIKE運算符的預設行為是忽略latin1字元的大小寫。因此在預設情況下'a' LIKE 'A'的值為真。可以通過打開case_sensitive_like pragma來改變這一預設行為。當啟用case_sensitive_like，'a' LIKE 'A'為假而 'a' LIKE 'a'依然為真。
4 count_changes
打開。便於調試
PRAGMA count_changes;
PRAGMA count_changes = 0 | 1;
查詢或更改count-changes標記。正常情況下INSERT, UPDATE和DELETE語句不返回數據。 當開啟count-changes，以上語句返回一行含一個整數值的數據——該語句插入，修改或刪除的行數。
註意：返回的行數不包括由（觸發器產生的插入，修改或刪除等改變的行數）。
5 page_size
PRAGMA page_size;
PRAGMA page_size = bytes;
查詢或設置page-size值。只有在未創建資料庫時才能設置page-size。頁面大小必須是2的整數倍且大於等於512小於等於8192。 上限可以通過在編譯時修改巨集定義SQLITE_MAX_PAGE_SIZE的值來改變。上限的上限是32768.
6 synchronous
如果有定期備份的機制，而且少量數據丟失可接受，用OFF
PRAGMA synchronous;
PRAGMA synchronous = FULL; (2)
PRAGMA synchronous = NORMAL; (1)
PRAGMA synchronous = OFF; (0)
查詢或更改"synchronous"標記的設定。第一種形式(查詢)返回整數值。 當synchronous設置為FULL (2), SQLite資料庫引擎在緊急時刻會暫停以確定數據已經寫入磁碟。 這使系統崩潰或電源出問題時能確保資料庫在重起後不會損壞。FULL synchronous很安全但很慢。 當synchronous設置為NORMAL, SQLite資料庫引擎在大部分緊急時刻會暫停，但不像FULL模式下那麼頻繁。 NORMAL模式下有很小的幾率(但不是不存在)發生電源故障導致資料庫損壞的情況。但實際上，在這種情況下很可能你的硬碟已經不能使用，或者發生了其他的不可恢復的硬體錯誤。 設置為synchronous OFF (0)時，SQLite在傳遞數據給系統以後直接繼續而不暫停。若運行SQLite的應用程式崩潰， 數據不會損傷，但在系統崩潰或寫入數據時意外斷電的情況下資料庫可能會損壞。另一方面，在synchronous OFF時 一些操作可能會快50倍甚至更多。
在SQLite 2中，預設值為NORMAL.而在3中修改為FULL.
7 temp_store
使用2，記憶體模式。
PRAGMA temp_store;
PRAGMA temp_store = DEFAULT; (0)
PRAGMA temp_store = FILE; (1)
PRAGMA temp_store = MEMORY; (2)
查詢或更改"temp_store"參數的設置。當temp_store設置為DEFAULT (0),使用編譯時的C預處理巨集 TEMP_STORE來定義儲存臨時表和臨時索引的位置。當設置為MEMORY (2)臨時表和索引存放於記憶體中。 當設置為FILE (1)則存放於文件中。temp_store_directorypragma 可用於指定存放該文件的目錄。當改變temp_store設置，所有已存在的臨時表，索引，觸發器及視圖將被立即刪除。
經測試，在類BBS應用上，通過以上調整，效率可以提高2倍以上。
附指令表集：
|
序號 |
指令 |
含義 |
預設值 |
|
1 |
auto_vacuum |
空間釋放 |
0 |
|
2 |
cache_size |
緩存大小 |
2000 |
|
3 |
case_sensitive_like |
LIKE大小寫敏感 |
（註意：SQLite3.6.22不支持） |
|
4 |
count_changes |
變更行數 |
0 |
|
5 |
page_size |
頁面大小 |
1024 |
|
6 |
synchronous |
硬碟大小 |
2 |
|
7 |
temp_store; |
記憶體模式 |
0 |
