分享一個SQLite 效能優化例項

導讀	本文給大家分享的是個人在實際專案中對於sqlite的一次優化的記錄，非常簡單實用，希望對大家學習sqlite能夠有所幫助。

最早接觸 iOS 開發瞭解到的第一個快取資料庫就是 SQLite，後面一直也以 SQLite 作為中堅力量使用，以前沒有接觸到比較大量資料的讀寫，所以在效能優化方面關注不多，這次對一個特定場景的較多資料批量讀寫做了一個效能優化，使效能提高了十倍。

大致應用場景是這樣：

每次程式啟動會從伺服器拉取一些資料，對本地資料庫兩個表進行同步更新，不存在就寫入，存在就更新其欄位。資料少的時候幾十條，多的上千條。

由於快取的資料可能會存在非同步同時讀寫，所以做了一個後臺同步佇列，所有的快取資料庫操作都在這個佇列裡面，然後我監控了一下寫資料庫的關鍵程式碼執行耗時，一千條資料更新到資料庫就能耗時 30 秒之久，磁碟寫入在 1.5M/s 浮動， 雖然沒有卡主執行緒，這個消耗即使在後臺也是不可容忍的。

核心的資料庫操作大概是這樣的

for 1000 : {
 
Select -> Update Or Insert
 
Select -> Update Or Insert
 
}

由於牽涉到兩張表，所以會有兩次，經過測試，Select 一次幾乎沒有多少訊息，可是 Update 或者 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗大了，因為會寫入磁碟，然後想到是不是可以把所有的 SQL 語句拼接起來，最後只想一次；再後來想到 SQLite 不是有事務 ( Transaction ) 嘛，於是嘗試了一下利用 FMDB 的事務操作，在迴圈開始前 [db beginTransaction] ，迴圈結束 [db commit]，包起來就行了。

增加事務之後的大概邏輯：

beginTransaction
 
for 1000 : {
 
Select -> Update Or Insert
 
Select -> Update Or Insert
 
}
 
commit

測試效果非常好，整個耗時從 30 秒下降到了2.8 秒左右，僅僅增加了兩行程式碼。

踩過的坑，走過的坎，都是以後的經驗

雖然利用事務取巧來提高了效能，但是這樣做其實並不安全，好在所屬場景對這部分資料絕對一致要求不是太高。
模擬器和真機有時候測試並不能重現同一個問題，因為所屬架構、CPU、硬碟都不一樣，所以效能測試最好還是以真機為準。該問題測試的時候在模擬器上很多問題都沒有，因為硬碟比真機讀寫速度要高，所以避免了很多問題，測試的時候也就沒有發現。

資料庫設計設計的時候得多考慮考慮，多想想以後怎麼擴充套件，怎麼升級，讀寫的時候效能怎麼樣。

原文來自：