最早接觸 iOS 開發了解到的第一個緩存數據庫就是 SQLite，后面一直也以 SQLite 作為中堅力量使用，以前沒有接觸到比較大量數據的讀寫，所以在性能優化方面關注不多，這次對一個特定場景的較多數據批量讀寫做了一個性能優化，使性能提高了十倍。
大致應用場景是這樣：
每次程序啟動會從服務器拉取一些數據，對本地數據庫兩個表進行同步更新，不存在就寫入，存在就更新其字段。數據少的時候幾十條，多的上千條。
由于緩存的數據可能會存在異步同時讀寫，所以做了一個后臺同步隊列，所有的緩存數據庫操作都在這個隊列里面，然后我監控了一下寫數據庫的關鍵代碼執行耗時，一千條數據更新到數據庫就能耗時 30 秒之久，磁盤寫入在 1.5M/s 浮動， 雖然沒有卡主線程，這個消耗即使在后臺也是不可容忍的。
核心的數據庫操作大概是這樣的
|
1
2
3
4
5
6
7
|
for 1000 : {Select -> Update Or InsertSelect -> Update Or Insert} |
由于牽涉到兩張表，所以會有兩次，經過測試，Select 一次幾乎沒有多少消息，可是 Update 或者 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗大了，因為會寫入磁盤，然后想到是不是可以把所有的 SQL 語句拼接起來，最后只想一次；再后來想到 SQLite 不是有事務 ( Transaction ) 嘛，于是嘗試了一下利用 FMDB 的事務操作，在循環開始前 [db beginTransaction] ，循環結束 [db commit]，包起來就行了。
增加事務之后的大概邏輯：
|
1
2
3
4
5
6
7
8
9
10
11
|
beginTransactionfor 1000 : {Select -> Update Or InsertSelect -> Update Or Insert}commit |
測試效果非常好，整個耗時從 30 秒下降到了2.8 秒左右，僅僅增加了兩行代碼。
總結：
踩過的坑，走過的坎，都是以后的經驗
雖然利用事務取巧來提高了性能，但是這樣做其實并不安全，好在所屬場景對這部分數據絕對一致要求不是太高。
模擬器和真機有時候測試并不能重現同一個問題，因為所屬架構、CPU、硬盤都不一樣，所以性能測試最好還是以真機為準。該問題測試的時候在模擬器上很多問題都沒有，因為硬盤比真機讀寫速度要高，所以避免了很多問題，測試的時候也就沒有發現。
數據庫設計設計的時候得多考慮考慮，多想想以后怎么擴展，怎么升級，讀寫的時候性能怎么樣
