最早接觸 ios 開發了解到的第乙個快取資料庫就是 sqlite，後面一直也以 sqlite 作為中堅力量使用，以前沒有接觸到比較大量資料的讀寫，所以在效能優化方面關注不多，這次對乙個特定場景的較多資料批量讀寫做了乙個效能優化，使效能提高了十倍。
大致應用場景是這樣：
每次程式啟動會從伺服器拉取一些資料，對本地資料庫兩個表進行同步更新，不存在就寫入，存在就更新其欄位。資料少的時候幾十條，多的上千條。smgolmr
由於快取的資料可能會存在非同步同時讀寫，所以做了乙個後台同步佇列，所有的快取資料庫操作都在這個佇列裡面，然後我監控了一下寫資料庫的關鍵**執行耗時，一千條資料更新到資料庫就能耗時 30 秒之久，磁碟寫入在 1.5m/s 浮動， 雖然沒有卡主線程，這個消耗即使在後台也是不可容忍的。
核心的資料庫操作大概是這樣的
for 1000 :
由於牽涉到兩張表，所以會有兩次，經過測試，select 一次幾乎沒有多少訊息，可是 update 或者 insert ( [fmdatabasequeue executeupdate:] ) 就消耗大了，因為會寫入磁碟，然後想到是不是可以把所有的 sql 語句拼接起來，最後只想一次；再後來想到 sqlite 不是有事務 ( transaction ) 嘛，於是嘗試了一下利用 fmdb 的事務操www.cppcns.com作，在迴圈開始前 [db begintransaction] ，迴圈結束 [db commit]，包起來就行了。
增加事務之後的大概邏輯：
begintransaction
for 10程式設計客棧00 :
commit
測試效果非常好，整個耗時從 30 秒下降到了2.8 秒左右，僅僅增加了兩行**。
總結：程式設計客棧
踩過的坑，走過的坎，都是以後的經驗
雖然利用事務取巧來提高了效能，但是這樣做其實並不安全，好在所屬場景對這部分資料絕對一致要求不是太高。
模擬器和真機有時候測試並不能重程式設計客棧現同乙個問題，因為所屬架構、cpu、硬碟都不一樣，所以效能測試最好還是以真機為準。該問題測試的時候在模擬器上很多問題都沒有，因為硬碟比真機讀寫速度要高，所以避免了很多問題，測試的時候也就沒有發現。
資料庫設計設計的時候得多考慮考慮，多想想以後怎麼擴充套件，怎麼公升級，讀寫的時候效能怎麼樣
本文標題: sqlite 效能優化例項分享
本文位址:
SQLite效能優化
最近做了乙個專案，在系統啟動時會更新幾千條資料，剛開始就使用最簡單的寫法，直接的insert，delete，導致這個更新過程進行了300多秒，後來經查得知在處理大量資料的時候新增上事務管理，會大大的提高效能，隨後就查閱資料如何來新增事務管理。這ios的sqlite和android上面的語法真是相差很...
sqlite 效能優化
比如 空間釋放 磁碟同步 cache大小等。不要開啟。前文提高了，vacuum的效率非常低！pragma auto vacuum pragma auto vacuum 0 1 查詢或設定資料庫的auto vacuum標記。正常情況下，當提交乙個從資料庫中刪除資料的事務時，資料庫檔案不改變大小。未使用...
sqlite效能優化1
建立索引的基本語法如下 create index index name on table name column name,間接索引 定義主鍵約束或者唯一性約束,可以間接建立索引,主鍵預設為唯一約束.所 有不需要再建立索引,以免造成浪費.注意事項 1.建立索引會增加資料庫的大小.2.對於insert...