最早接觸 iOS 開(kāi)發(fā)了解到的第一個(gè)緩存數(shù)據(jù)庫(kù)就是 SQLite嗽上，后面一直也以 SQLite 作為中堅(jiān)力量使用喊暖，以前沒(méi)有接觸到比較大量數(shù)據(jù)的讀寫(xiě)帅涂，所以在性能優(yōu)化方面關(guān)注不多轻掩，這次對(duì)一個(gè)特定場(chǎng)景的較多數(shù)據(jù)批量讀寫(xiě)做了一個(gè)性能優(yōu)化幸乒，使性能提高了十倍。
大致應(yīng)用場(chǎng)景是這樣：
每次程序啟動(dòng)會(huì)從服務(wù)器拉取一些數(shù)據(jù)唇牧，對(duì)本地?cái)?shù)據(jù)庫(kù)兩個(gè)表進(jìn)行同步更新罕扎，不存在就寫(xiě)入，存在就更新其字段丐重。數(shù)據(jù)少的時(shí)候幾十條腔召，多的上千條。
由于緩存的數(shù)據(jù)可能會(huì)存在異步同時(shí)讀寫(xiě)扮惦，所以做了一個(gè)后臺(tái)同步隊(duì)列臀蛛，所有的緩存數(shù)據(jù)庫(kù)操作都在這個(gè)隊(duì)列里面，然后我監(jiān)控了一下寫(xiě)數(shù)據(jù)庫(kù)的關(guān)鍵代碼執(zhí)行耗時(shí)，一千條數(shù)據(jù)更新到數(shù)據(jù)庫(kù)就能耗時(shí) 30 秒之久浊仆，磁盤(pán)寫(xiě)入在 1.5M/s 浮動(dòng)客峭， 雖然沒(méi)有卡主線程，這個(gè)消耗即使在后臺(tái)也是不可容忍的抡柿。
核心的數(shù)據(jù)庫(kù)操作大概是這樣的
for 1000 : {
Select -> Update Or Insert
Select -> Update Or Insert
}
由于牽涉到兩張表舔琅，所以會(huì)有兩次，經(jīng)過(guò)測(cè)試洲劣，Select 一次幾乎沒(méi)有多少消息备蚓，可是 Update 或者 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗大了，因?yàn)闀?huì)寫(xiě)入磁盤(pán)囱稽，然后想到是不是可以把所有的 SQL 語(yǔ)句拼接起來(lái)郊尝，最后只想一次；再后來(lái)想到 SQLite 不是有事務(wù) ( Transaction ) 嘛战惊，于是嘗試了一下利用 FMDB 的事務(wù)操作流昏，在循環(huán)開(kāi)始前[db beginTransaction]，循環(huán)結(jié)束[db commit]吞获，包起來(lái)就行了横缔。
增加事務(wù)之后的大概邏輯：
beginTransaction
for 1000 : {
Select -> Update Or Insert
Select -> Update Or Insert
}
commit
測(cè)試效果非常好，整個(gè)耗時(shí)從 30 秒下降到了2.8 秒左右衫哥，僅僅增加了兩行代碼。
總結(jié)：
? ? ? ? ? 踩過(guò)的坑襟锐，走過(guò)的坎撤逢，都是以后的經(jīng)驗(yàn)
雖然利用事務(wù)取巧來(lái)提高了性能，但是這樣做其實(shí)并不安全粮坞，好在所屬場(chǎng)景對(duì)這部分?jǐn)?shù)據(jù)絕對(duì)一致要求不是太高蚊荣。
模擬器和真機(jī)有時(shí)候測(cè)試并不能重現(xiàn)同一個(gè)問(wèn)題，因?yàn)樗鶎偌軜?gòu)莫杈、CPU互例、硬盤(pán)都不一樣，所以性能測(cè)試最好還是以真機(jī)為準(zhǔn)筝闹。該問(wèn)題測(cè)試的時(shí)候在模擬器上很多問(wèn)題都沒(méi)有媳叨，因?yàn)橛脖P(pán)比真機(jī)讀寫(xiě)速度要高，所以避免了很多問(wèn)題关顷，測(cè)試的時(shí)候也就沒(méi)有發(fā)現(xiàn)糊秆。
數(shù)據(jù)庫(kù)設(shè)計(jì)設(shè)計(jì)的時(shí)候得多考慮考慮，多想想以后怎么擴(kuò)展议双，怎么升級(jí)痘番，讀寫(xiě)的時(shí)候性能怎么樣?
