SQLite 效能最佳化執行個體分享，sqlite效能最佳化執行個體

SQLite 效能最佳化執行個體分享，sqlite效能最佳化執行個體

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

大致應用情境是這樣：

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

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

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

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

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

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

beginTransactionfor 1000 : {Select -> Update Or InsertSelect -> Update Or Insert}commit

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

總結：

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

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

您可能感興趣的文章:

• SQLite最佳化方法
• android建立資料庫(SQLite)儲存圖片樣本
• SQLite3中的日期時間函數使用小結
• SQLite3中自增主鍵相關知識總結
• C#操作SQLite方法執行個體詳解