最早接觸 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、硬盤都不一樣，所以性能測試最好還是以真機為准。該問題測試的時候在模擬器上很多問題都沒有，因為硬盤比真機讀寫速度要高，所以避免了很多問題，測試的時候也就沒有發現。
數據庫設計設計的時候得多考慮考慮，多想想以後怎麼擴展，怎麼升級，讀寫的時候性能怎麼樣
