sqlite3 多線程和鎖 ，優化插入速度及性能優化

一、 是否支持多線程？

 

SQLite官網上的 “Is SQLite threadsafe?”這個問答。 簡單來說，從3.3.1版本開始，它就是線程安全的了。而 iOS的SQLite版本沒有低於這個版本的，當然，你也可以自己編譯最新版本。

不過這個線程安全仍然是有限制的，在這篇 《Is SQLite thread-safe?》里有詳細的解釋。
另一篇重要的文檔就是 《SQLite And Multiple Threads》。它指出SQLite支持3種線程模式：

1. 單線程：禁用所有的mutex鎖，並發使用時會出錯。當SQLite編譯時加了SQLITE_THREADSAFE=0參數，或者在初始化SQLite前調用sqlite3_config(SQLITE_CONFIG_SINGLETHREAD)時啟用。
2. 多線程：只要一個數據庫連接不被多個線程同時使用就是安全的。源碼中是啟用bCoreMutex，禁用bFullMutex。實際上就是禁用數據庫連接和prepared statement（准備好的語句）上的鎖，因此不能在多個線程中並發使用同一個數據庫連接或prepared statement。當SQLite編譯時加了SQLITE_THREADSAFE=2參數時默認啟用。若SQLITE_THREADSAFE不為0，可以在初始化SQLite前，調用sqlite3_config(SQLITE_CONFIG_MULTITHREAD)啟用；或者在創建數據庫連接時，設置SQLITE_OPEN_NOMUTEX flag。
3. 串行：啟用所有的鎖，包括bCoreMutex和bFullMutex。因為數據庫連接和prepared statement都已加鎖，所以多線程使用這些對象時沒法並發，也就變成串行了。當SQLite編譯時加了SQLITE_THREADSAFE=1參數時默認啟用。若SQLITE_THREADSAFE不為0，可以在初始化SQLite前，調用sqlite3_config(SQLITE_CONFIG_SERIALIZED)啟用；或者在創建數據庫連接時，設置SQLITE_OPEN_FULLMUTEX flag。

　　而這里所說的初始化是指調用sqlite3_initialize()函數，這個函數在調用sqlite3_open()時會自動調用，且只有第一次調用是有效的。

　　調用sqlite3_threadsafe()可以獲得編譯期的SQLITE_THREADSAFE參數。標准發行版是1，也就是串行模式；而iOS上是2，也就是多線程模式；Python的sqlite3模塊也默認使用串行模式，可以用sqlite3.threadsafety來配置。

　　

　　另一個要說明的是prepared statement，它是由數據庫連接（的pager）來管理的，使用它也可看成使用這個數據庫連接。因此在多線程模式下，並發對同一個數據庫連接調用sqlite3_prepare_v2()來創建prepared statement，或者對同一個數據庫連接的任何prepared statement並發調用sqlite3_bind_*()和sqlite3_step()等函數都會出錯（在iOS上，該線程會出現EXC_BAD_ACCESS而中止）。這種錯誤無關讀寫，就是只讀也會出錯。文檔中給出的安全使用規則是：沒有事務正在等待執行，所有prepared statement都被 finalized。

　　但是默認情況下，一個線程只能使用當前線程打開的數據庫連接，除非在連接時設置了check_same_thread=False參數。如果是用不同的數據庫連接，每個連接都不能讀取其他連接中未提交的數據，除非使用 read-uncommitted模式。

現在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：表示它可以寫入數據庫了。進入這個狀態后，其他任何線程都不能訪問數據庫文件。因此為了並發性，它的持有時間越短越好。

一個線程只有在擁有低級別的鎖的時候，才能獲取更高一級的鎖。SQLite就是靠這5種類型的鎖，巧妙地實現了讀寫線程的互斥。同時也可看出，寫操作必須進入EXCLUSIVE狀態，此時並發數被降到1，這也是SQLite被認為並發插入性能不好的原因。
另外，read-uncommitted和WAL模式會影響這個鎖的機制。在這2種模式下，讀線程不會被寫線程阻塞，即使寫線程持有PENDING或EXCLUSIVE鎖。

提到鎖就不得不說到死鎖的問題，而SQLite也可能出現死鎖。
下面舉個例子：

連接1：BEGIN （UNLOCKED）
連接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）

現在2個連接都在等待對方釋放鎖，於是就死鎖了。當然，實際情況並沒那么糟糕，任何一方選擇不繼續等待，回滾事務就行了。

不過要更好地解決這個問題，就必須更深入地了解事務了。
實際上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）
連接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，寫入完成后釋放）

不過在並發很高的情況下，直接獲取EXCLUSIVE鎖的難度比較大；而且為了避免EXCLUSIVE狀態長期阻塞其他請求，最好的方式還是讓所有寫事務都以IMMEDIATE方式開始。
順帶一提，要實現重試的話，可以使用sqlite3_busy_timeout()或sqlite3_busy_handler()函數。

由此可見，要想保證線程安全的話，可以有這4種方式：

1. SQLite使用單線程模式，用一個專門的線程訪問數據庫。
2. SQLite使用單線程模式，用一個線程隊列來訪問數據庫，隊列一次只允許一個線程執行，隊列里的線程共用一個數據庫連接。
3. SQLite使用多線程模式，每個線程創建自己的數據庫連接。
4. SQLite使用串行模式，所有線程共用全局的數據庫連接。

 

三、sqlite3插入速度慢

 

1.像上述一樣顯示的給多個insert加上事務

　　sqlite在沒有顯式使用事務的時候會為每條insert都使用事務操作，而sqlite數據庫是以文件的形式存在磁盤中，就相當於每次訪問時都要打開一次文件，如果對數據進行大量的操作，時間都耗費在I/O操作上，所以很慢。

解決方法是顯式使用事務的形式提交：因為我們開始事務后，進行的大量操作的語句都保存在內存中，當提交時才全部寫入數據庫，此時，數據庫文件也就只用打開一次。

 

2.如果加上事務還是不行，可以嘗試修改同步模式

　　初用sqlite3插入數據時，插入每條數據大概需要100ms左右。如果是批量導入，可以引進事務提高速度。但是假設你的業務是每間隔幾秒插入幾條數據，顯然100ms是不能容許的。
解決辦法是，在調用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