用SQLite和FMDB而不用Core Data的原因分析

這篇文章主要講解了“用SQLite和FMDB而不用Core Data的原因分析”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“用SQLite和FMDB而不用Core Data的原因分析”吧！

為什么我不使用Core Data

Mike Ash寫到：就我自己而言，我不是個(gè)狂熱粉絲。我發(fā)現(xiàn)API是笨拙的，并且框架本身對(duì)于大量的數(shù)據(jù)是極其緩慢的。

一個(gè)實(shí)際的例子：10,000條目

想象一個(gè)RSS閱讀器，一個(gè)用戶可以在一個(gè)feed上點(diǎn)擊右鍵，并且選擇標(biāo)記所有為已讀。

引擎下，有一個(gè)帶有read屬性的Article實(shí)體。把所有條目標(biāo)記為已讀，程序需要加載這個(gè)feed的所有文章(可能通過一對(duì)多的關(guān)系)，然后設(shè)置read屬性為YES。

大部分情況下這樣沒關(guān)系。但是設(shè)想那個(gè)feed里有200個(gè)文章，為了避免阻塞主線程，你可能考慮在后臺(tái)線程里做這個(gè)工作(特別當(dāng)你的程序是一個(gè)iPhone應(yīng)用)。當(dāng)你一開始使用Core Data多線程，事情就開始變的不好處理了。

這可能還湊合，至少不值得切換走Core Data。

但是接下來加同步。

我用過兩種不同的獲取已讀文章ID列表的RSS同步接口。其中一個(gè)返回近10,000個(gè)ID。

你不會(huì)打算在主線程中加載10,000個(gè)文章，然后設(shè)置read為NO。你甚至不想在后臺(tái)線程里加載10,000個(gè)文章，即使很小心的管理內(nèi)存，這有太多的工作（如果你頻繁的這么做，想一下對(duì)電池壽命的影響）。

你真正想要做的是，讓數(shù)據(jù)庫(kù)給在ID列表里的每一個(gè)文章設(shè)置read為YES。

SQLite可以做到這個(gè)，只用一次調(diào)用。假設(shè)uniqueID上有索引，這會(huì)很快。而且你可以在后臺(tái)線程執(zhí)行像在主線程執(zhí)行一樣容易。

另一個(gè)例子：快速啟動(dòng)

我想減少我的另一個(gè)程序的啟動(dòng)時(shí)間，不只是開始的時(shí)間，而是在數(shù)據(jù)顯示之前的所有時(shí)間。

那是個(gè)類似Twitter的應(yīng)用(雖然它不是)，它顯示消息的時(shí)間軸。顯示時(shí)間軸意味著獲取消息，加載相關(guān)用戶。它很快，但是在啟動(dòng)的時(shí)候，會(huì)填充UI，然后填充數(shù)據(jù)。

關(guān)于iPhone的應(yīng)用（或者所有應(yīng)用）我的理論是，啟動(dòng)時(shí)間很重要，比其他大部分開發(fā)者想的都要重要。應(yīng)用的啟動(dòng)很慢看起來不像是要啟動(dòng)一樣，因 為人們潛意識(shí)里記得，并且會(huì)產(chǎn)生阻止啟動(dòng)應(yīng)用的想法。減少啟動(dòng)時(shí)間就減少了摩擦，讓用戶更有可能繼續(xù)使用你的應(yīng)用，并且推薦給其他人。這是你讓你的應(yīng)用成 功的一部分。

因?yàn)槲也皇褂肅ore Data，我手邊有一個(gè)簡(jiǎn)單的，保守的解決方案。我把timeline（消息和人物對(duì)象）通過NSCoding保存到一個(gè)plist文件中。啟動(dòng)的時(shí)候它讀這個(gè)文件，創(chuàng)建消息和人物對(duì)象，UI一出現(xiàn)就顯示時(shí)間軸。

這明顯的減少了延遲。

把消息和人物對(duì)象作為NSManagedObject的實(shí)例對(duì)象，這是不可能的。（假設(shè)我有編碼的并且存儲(chǔ)的IDs對(duì)象，但是那意味著讀plist然后觸及數(shù)據(jù)庫(kù)。這種方式我完全避免了數(shù)據(jù)庫(kù)）。

在更新更快的機(jī)器出來后, 我去掉了那些代碼?；仡欉^去，我希望我可以把它留下來。

我怎么考慮這個(gè)問題

當(dāng)考慮是否使用Core Data時(shí)，我考慮下面這些事情：

會(huì)有難以置信數(shù)量的數(shù)據(jù)嗎？

對(duì)于一個(gè)RSS閱讀器或者Twitter應(yīng)用，答案顯而易見：是的。有些人關(guān)注上百個(gè)人。一個(gè)人可能訂閱了上千個(gè)feeds。

即使你的應(yīng)用不從網(wǎng)絡(luò)獲取數(shù)據(jù)，仍然有可能讓用戶自動(dòng)添加數(shù)據(jù)。如果你用一個(gè)支持AppleScript的Mac，有些人會(huì)寫腳本去加載非常多的數(shù)據(jù)。如果通過web API去加數(shù)據(jù)也是一樣的。

會(huì)有一個(gè)Web API包含類似于數(shù)據(jù)庫(kù)的終端嗎（對(duì)比類對(duì)象終端）？

一個(gè)RSS同步API能夠返回一個(gè)已讀文章的uniquelIDs列表。一個(gè)記筆記的應(yīng)用的一個(gè)同步API可能返回已存檔的和已刪除的筆記的uniquelIDs。

用戶可能通過操作處理大量對(duì)象嗎？

在底層，需要考慮和之前一樣的問題。當(dāng)有人刪除所有下載的5，000個(gè)面食食譜，你的食譜應(yīng)用可以多好的完成這個(gè)功能（在iPhone上？）？

當(dāng)我決定使用Core Data（我已經(jīng)發(fā)布過使用Core Data的應(yīng)用），我會(huì)小心留意我怎么使用它。為了得到好的性能，我發(fā)現(xiàn)我把它當(dāng)做一個(gè)SQL數(shù)據(jù)庫(kù)的一個(gè)奇怪接口來使用，然后我知道我應(yīng)該舍棄Core Data，直接使用SQLite。

我怎么使用SQLite

我通過FMDB Wrapper來使用SQLite，F(xiàn)MDB來自Flying Meat Software，由Gus Mueller提供。

基本操作

我在iPhone以前，Core Data以前就使用過SQLite。這是它怎么工作的的要點(diǎn)：

• 所有數(shù)據(jù)庫(kù)訪問-讀和寫-發(fā)生在連續(xù)的隊(duì)列里，在一個(gè)后臺(tái)線程。在主線程中觸及數(shù)據(jù)庫(kù)是從來不被允許的。使用一個(gè)連續(xù)隊(duì)列來保證每一件事是按順序發(fā)生的。
  

• 我大量使用blocks來讓異步程序容易點(diǎn)。

• 模型對(duì)象只存在在主線程（但有兩個(gè)重要的例外），改變會(huì)觸發(fā)一個(gè)后臺(tái)保存。

• 模型對(duì)象列出來他們?cè)跀?shù)據(jù)庫(kù)中存儲(chǔ)的屬性?？赡茉诖a里或者在plist文件里。

• 一些模型對(duì)象是唯一的，一些不是。取決于應(yīng)用的需要（大部分情況是唯一的）。

• 對(duì)關(guān)系型數(shù)據(jù)，我盡可能避免連表查詢。

• 一些對(duì)象類型在啟動(dòng)的時(shí)候就完全讀入內(nèi)存，另一些對(duì)象類型可能只需要?jiǎng)?chuàng)建并維護(hù)一個(gè)他們的uniqueIDs的。NSMutableSet，所以不需要去觸及數(shù)據(jù)庫(kù)，我就知道已經(jīng)有什么。

• Web API的調(diào)用發(fā)生在后臺(tái)線程，他們使用分開的模型對(duì)象。

我會(huì)通過我現(xiàn)在的應(yīng)用的代碼來詳細(xì)描述。

數(shù)據(jù)庫(kù)更新

在我最近的應(yīng)用中，有一個(gè)單一的數(shù)據(jù)庫(kù)控制器-VSDatabaseController，它通過FMDB來與SQLite對(duì)話。

FMDB區(qū)分更新和查詢。更新數(shù)據(jù)庫(kù)，app調(diào)用：

-[VSDatabaseController runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock]

VSDatabaseUpdateBlock很簡(jiǎn)單：

typedef void (^VSDatabaseUpdateBlock)(FMDatabase *database);

runDatabaseBlockInTransaction也很簡(jiǎn)單：

- (void)runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock {     dispatch_async(self.serialDispatchQueue, ^{         @autoreleasepool {             [self beginTransaction];             databaseBlock(self.database);             [self endTransaction];         }     }); }

（注意我用自己的連續(xù)調(diào)度隊(duì)列。Gus建議看一下FMDatabaseQueue，也是一個(gè)連續(xù)調(diào)度隊(duì)列。我還沒能去看一下，因?yàn)樗菷MDB的其他東西都要新。）

beginTransaction和endTransaction的調(diào)用是可嵌套的（在我的數(shù)據(jù)庫(kù)控制器里）。在合適的時(shí)候他們會(huì)調(diào)用-[FMDatabase beginTransaction] 和 -[FMDatabase commit]。（使用事務(wù)是讓SQLite變快的關(guān)鍵。）提示：我把當(dāng)前事務(wù)存儲(chǔ)在-[NSThread threadDictionary]。它很好獲取每一個(gè)線程的數(shù)據(jù)，我?guī)缀鯊牟挥闷渌摹?/p>

這兒有個(gè)調(diào)用更新數(shù)據(jù)庫(kù)的簡(jiǎn)單例子：

- (void)emptyTagsLookupTableForNote:(VSNote *)note {     NSString *uniqueID = note.uniqueID;     [self runDatabaseBlockInTransaction:^(FMDatabase *database) {         [database executeUpdate:             @"delete from tagsNotesLookup where noteUniqueID = ?;", uniqueID];     }]; }

這說明一些事情。首先SQL不可怕。即使你從沒見過它，你也知道這行代碼做了什么。

像VSDatabaseController的所有其他公共接口，emptyTagsLookupTableForNote應(yīng)該在主線程中被調(diào)用。模型對(duì)象只能在主線程中被引用，所以在block中用uniqueID，而不是VSNote對(duì)象。

注意在這種情況下，我更新了一個(gè)查找表。Notes和tags是多對(duì)多關(guān)系，一種表現(xiàn)方式是用一個(gè)數(shù)據(jù)庫(kù)表映射note uniqueIDs和tag uniqueIDs。這些表不會(huì)很難維護(hù)，但是如果可能，我確實(shí)嘗試避免他們的使用。

注意在更新字符串中的?。-[FMDatabase executeUpdate:] 是一個(gè)可變參數(shù)函數(shù)。SQLite支持使用占位符?，所以你不需要把正真的值放入字符串。這兒有一個(gè)安全問題：它幫助守護(hù)程序反對(duì)SQL插入。如果你需要避開某些值，它也為你省了麻煩。

***，在tagsNotesLookup表中，有一個(gè)noteUniquelID的索引（索引是SQLite性能的又一個(gè)關(guān)鍵）。這行代碼在每次啟動(dòng)時(shí)都調(diào)用：

[self.database executeUpdate:     @"CREATE INDEX if not exists noteUniqueIDIndex on tagsNotesLookup (noteUniqueID);"];

數(shù)據(jù)庫(kù)獲取

要獲取對(duì)象，app調(diào)用：

-[VSDatabaseController runFetchForClass:(Class)databaseObjectClass                              fetchBlock:(VSDatabaseFetchBlock)fetchBlock                       fetchResultsBlock:(VSDatabaseFetchResultsBlock)fetchResultsBlock];

這兩行代碼做了大部分工作：

FMResultSet *resultSet = fetchBlock(self.database); NSArray *fetchedObjects = [self databaseObjectsWithResultSet:resultSet                                                        class:databaseObjectClass];

用FMDB查找數(shù)據(jù)庫(kù)返回一個(gè)FMResultSet. 通過resultSet你可以逐句循環(huán)，創(chuàng)建模型對(duì)象。

我建議寫通用的代碼去轉(zhuǎn)換數(shù)據(jù)庫(kù)行到對(duì)象。一種我使用的方法是用一個(gè)plist，映射column名字到對(duì)象屬性。它也包含類型，所以你知道是否需要調(diào)用 -[FMResultSet dateForColumn:]， -[FMResultSet stringForColumn:]或其他。

在我的***應(yīng)用里我做了些簡(jiǎn)單的事情。數(shù)據(jù)庫(kù)行剛好對(duì)應(yīng)模型對(duì)象屬性的名字。所有屬性都是strings，除了那些名字以“Date”結(jié)尾的屬性。很簡(jiǎn)單，但是你可以看到需要一個(gè)清晰的對(duì)應(yīng)關(guān)系。

唯一對(duì)象

創(chuàng)建模型對(duì)象和從數(shù)據(jù)庫(kù)獲取數(shù)據(jù)在同一個(gè)后臺(tái)線程。一獲取到，程序會(huì)把他們轉(zhuǎn)到主線程。

通常我有uniqued對(duì)象。同一個(gè)數(shù)據(jù)庫(kù)行結(jié)果始終對(duì)應(yīng)同一個(gè)對(duì)象。

為了做到唯一，我創(chuàng)建了一個(gè)對(duì)象緩存，一個(gè)NSMapTable，在init函數(shù)里：_objectCache = [NSMapTable weakToWeakObjectsMapTable]。我來解釋一下：

例如，當(dāng)你做一個(gè)數(shù)據(jù)庫(kù)獲取并且把對(duì)象轉(zhuǎn)交給一個(gè)視圖控制器，你希望在視圖控制器使用完這些對(duì)象后，或者一個(gè)不一樣的視圖控制器顯示了，這些對(duì)象可以消失。

如果你的對(duì)象緩存是一個(gè)NSMutableDictionary，你將需要做一些額外的工作來清空緩存中的對(duì)象。確定它對(duì)應(yīng)的對(duì)象在別的地方是否有引用就變的很痛苦。NSMapTable是弱引用，就會(huì)自動(dòng)處理這個(gè)問題。

所以：我們?cè)谥骶€程中讓對(duì)象唯一。如果一個(gè)對(duì)象已經(jīng)在對(duì)象緩存中存在，我們就用那個(gè)存在的對(duì)象。（主線程勝出，因?yàn)樗赡苡行碌母淖儭＃┤绻麑?duì)象緩存中沒有，它會(huì)被加上。

保持對(duì)象在內(nèi)存中

有很多次，把整個(gè)對(duì)象類型保留在內(nèi)存中是有道理的。我***的app有一個(gè)VSTag對(duì)象。雖然可能有成百上千個(gè)筆記，但tags的數(shù)量很小，基本少于10。一個(gè)tag只有6個(gè)屬性：3個(gè)BOOL，兩個(gè)很小的NSstring，還有一個(gè)NSDate。

啟動(dòng)的時(shí)候，app獲取所有tags并且把他們保存在兩個(gè)字典里，一個(gè)主鍵是tag的uniqueID，另一個(gè)主鍵是tag名字的小寫。

這簡(jiǎn)化了很多事，不只是tag自動(dòng)補(bǔ)全系統(tǒng)，這個(gè)可以完全在內(nèi)存中操作，不需要數(shù)據(jù)庫(kù)獲取。

但是很多次，把所有數(shù)據(jù)保留在內(nèi)存中是不實(shí)際的。比如我們不會(huì)在內(nèi)存中保留所有筆記。

但是也有很多次，當(dāng)不能在內(nèi)存中保留對(duì)象時(shí)，你希望在內(nèi)存中保留所有uniqueIDs。你會(huì)像這樣做一個(gè)獲取：

FMResultSet *resultSet = [self.database executeQuery:@"select uniqueID from some_table"];

resultSet只包含了uniqueIDs， 你可以存儲(chǔ)到一個(gè)NSMutableSet里。

我發(fā)現(xiàn)有時(shí)這個(gè)對(duì)web APIs很有用。想象一個(gè)API調(diào)用返回從某個(gè)確定的時(shí)間以后的，已創(chuàng)建筆記的uniqueIDs列表。如果我本地已經(jīng)有了一個(gè)包含所有筆記uniqueIDs的NSMutableSet，我可以快速檢查(通過 -[NSMutableSet minusSet])是否有漏掉的筆記，然后去調(diào)用另一個(gè)API下載那些漏掉的筆記。這些完全不需要觸及數(shù)據(jù)庫(kù)。

但是，像這樣的事情應(yīng)該小心處理。app可以提供足夠的內(nèi)存嗎？它真的簡(jiǎn)化編程并且提高性能了嗎？

用SQLite和FMDB而不是Core Data，給你帶來大量的靈活性和聰明解決辦法的空間。記住有的時(shí)候聰明是好的，也有的時(shí)候聰明是一個(gè)大錯(cuò)誤。

Web APIs

我的API調(diào)用在后臺(tái)進(jìn)程（經(jīng)常用一個(gè)NSOperationQueue，所以我可以取消操作）。模型對(duì)象只在主線程，但是我還傳遞模型對(duì)象給我的API調(diào)用。

是這樣的：一個(gè)數(shù)據(jù)庫(kù)對(duì)象有一個(gè)detachedCopy方法，可以復(fù)制數(shù)據(jù)庫(kù)對(duì)象。這個(gè)復(fù)制對(duì)象不是引用自我用來唯一化的對(duì)象緩存。唯一引用那個(gè)對(duì)象的地方是API調(diào)用，當(dāng)API調(diào)用結(jié)束，那個(gè)復(fù)制的對(duì)象就消失了。

這是一個(gè)好的系統(tǒng)，因?yàn)樗馕吨铱梢栽贏PI調(diào)用里使用模型對(duì)象。方法看起來像這樣：

- (void)uploadNote:(VSNote *)note {     VSNoteAPICall *apiCall = [[VSNoteAPICall alloc] initWithNote:[note detachedCopy]];     [self enqueueAPICall:apiCall]; }

VSNoteAPICall從復(fù)制的VSNote獲取值，并且創(chuàng)建HTTP請(qǐng)求，而不是一個(gè)字典或其他筆記的表現(xiàn)形式。

處理Web API返回值

我對(duì)web返回值做了一些類似的事情。我會(huì)對(duì)返回的JSON或者XML創(chuàng)建一個(gè)模型對(duì)象，這個(gè)模型對(duì)象也是分離的。它不是存儲(chǔ)在為了唯一性的模型緩存里。

這兒有些事情是不確定的。有時(shí)有必要用那個(gè)模型對(duì)象在兩個(gè)地方做本地修改：在內(nèi)存緩存和數(shù)據(jù)庫(kù)。

數(shù)據(jù)庫(kù)通常是容易的部分。比如：我的應(yīng)用已經(jīng)有一個(gè)方法來保存筆記對(duì)象。它用一個(gè)SQL insert或者replace字符串。我只需調(diào)用那個(gè)從web API返回值生成的筆記對(duì)象，數(shù)據(jù)庫(kù)就會(huì)更新。

但是可能那個(gè)對(duì)象有一個(gè)在內(nèi)存中的版本，幸運(yùn)的是我們很容易找到：

VSNote *cachedNote = [self.mapTable objectForKey:downloadedNote.uniqueID];

如果cachedNote存在，我會(huì)讓它從downloadedNote中獲取值，而不是替換它（這樣可能違反唯一性）。這可以共享detachedCopy方法的代碼。

一旦cachedNote更新了，觀察者會(huì)通過KVO通知筆記，或者我會(huì)發(fā)送一個(gè)NSNotification，或者兩者都做。

Web API調(diào)用也會(huì)返回一些其他值。我提到過RSS閱讀器可能獲得一個(gè)已讀條目的大列表。這種情況下，我用那個(gè)列表創(chuàng)建了一個(gè)NSSet，在內(nèi)存中更新每一個(gè)緩存文章的read屬性，然后調(diào)用-[FMDatabase executeUpdate:]。

讓它工作快速的關(guān)鍵是NSMapTable的查找是快速的。如果你找的對(duì)象在一個(gè)NSArray里，我們?cè)撝匦驴紤]。

數(shù)據(jù)庫(kù)遷移

Core Data的數(shù)據(jù)庫(kù)遷移很酷，當(dāng)它可行的時(shí)候。

但是不可避免的，它是代碼和數(shù)據(jù)庫(kù)中的一層。如果你越直接使用SQLite，你更新數(shù)據(jù)庫(kù)越直接。

你可以安全容易的做到這點(diǎn)。

比如加一個(gè)表：

[self.database executeUpdate:@"CREATE TABLE if not exists tags "     "(uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);"];

或者加一個(gè)索引：

[self.database executeUpdate:@"CREATE INDEX if not exists "     "archivedSortDateIndex on notes (archived, sortDate);"];

或者加一列：

[self.database executeUpdate:@"ALTER TABLE tags ADD deletedDate DATE"];

應(yīng)用應(yīng)該在代碼的***個(gè)地方用上面這些代碼設(shè)置數(shù)據(jù)庫(kù)。以后的改變只需加executeUpdate的調(diào)用 — 我讓他們按順序執(zhí)行。因?yàn)槲业臄?shù)據(jù)庫(kù)是我設(shè)計(jì)的，不會(huì)有什么問題（我從沒碰到性能問題，它很快）。

當(dāng)然大的改變需要更多代碼。如果你的數(shù)據(jù)通過web獲取，有時(shí)你可以從一個(gè)新數(shù)據(jù)庫(kù)模型開始，重新下載你需要的數(shù)據(jù)。

性能技巧

SQLite可以非常非?？?，它也可以非常慢。完全取決于你怎么使用它。

事務(wù)

把更新包裝在事務(wù)里。在更新前調(diào)用 -[FMDatabase beginTransaction] ，更新后調(diào)用-[FMDatabase commit]。

如果你不得不反規(guī)范化（ Denormalize）

反規(guī)范化讓人很不爽。這個(gè)方法是，為了加速檢索而添加冗余數(shù)據(jù)，但是它意味著你需要維護(hù)冗余數(shù)據(jù)。

我總是瘋狂避免它，直到這樣能有嚴(yán)重的性能區(qū)別。然后我會(huì)盡可能少得這么做。

使用索引

我的應(yīng)用中tags表的創(chuàng)建語(yǔ)句像這樣：

CREATE TABLE if not exists tags   (uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);

uniqueID列是自動(dòng)索引的，因?yàn)樗x為unique。但是如果我想用name來查詢表，我可能會(huì)在name上創(chuàng)建一個(gè)索引，像這樣：

CREATE INDEX if not exists tagNameIndex on tags (name);

你可以一次性在多列上創(chuàng)建索引，像這樣：

CREATE INDEX if not exists archivedSortDateIndex on notes (archived, sortDate);

但是注意太多索引會(huì)降低你的插入速度。你只需要足夠數(shù)量并且是對(duì)的那些。

使用命令行應(yīng)用

當(dāng)我的app在模擬器里運(yùn)行時(shí)，我會(huì)打印數(shù)據(jù)庫(kù)的路徑。我可以通過sqlite3的命令行來打開數(shù)據(jù)庫(kù)。（通過man sqlite3命令來了解這個(gè)應(yīng)用的更多信息）。

打開數(shù)據(jù)庫(kù)的命令：sqlite3 “數(shù)據(jù)庫(kù)的路徑”。

打開以后，你可以看schema: type .schema。

你可以更新和查詢，這是在使用你的app之前檢查SQL是否正確的很好的方式。

這里面最酷的一部分是，SQLite Explain Query Plan命令，你會(huì)希望確保你的語(yǔ)句執(zhí)行的盡可能快。

真實(shí)的例子

我的應(yīng)用顯示所有沒有歸檔筆記的標(biāo)簽列表。每當(dāng)筆記或者標(biāo)簽有變化，這個(gè)查詢就會(huì)重新執(zhí)行一次，所以它需要很快。

我可以用SQL join來查詢，但是很慢（joins都很慢）。

所以我放棄sqlite3并開始嘗試別的方法。我又看了一次我的schema，意識(shí)到我可以反規(guī)范化。一個(gè)筆記的歸檔狀態(tài)可以存儲(chǔ)在notes表里，它也可以存儲(chǔ)在tagsNotesLookup表。

然后我可以執(zhí)行一個(gè)查詢：

select distinct tagUniqueID from tagsNotesLookup where archived=0;

我已經(jīng)有了一個(gè)在tagUniqueID上的索引。所以我用explain query plan來告訴我當(dāng)我執(zhí)行這個(gè)查詢的時(shí)候會(huì)發(fā)生什么。

sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0; 0|0|0|SCAN TABLE tagsNotesLookup USING INDEX tagUniqueIDIndex (~100000 rows)

它用了一個(gè)索引，但是SCAN TABLE聽起來不太好，***是一個(gè)SEARCH TABLE并且覆蓋一個(gè)索引。

我在tagUniqueID和archive上建了索引：

CREATE INDEX archivedTagUniqueID on tagsNotesLookup(archived, tagUniqueID);

再次執(zhí)行explain query plan：

sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0; 0|0|0|SEARCH TABLE tagsNotesLookup USING COVERING INDEX archivedTagUniqueID (archived=?) (~10 rows)

好多了。

更多性能提示

FMDB的某處加了緩存statements的能力，所以當(dāng)創(chuàng)建或打開一個(gè)數(shù)據(jù)庫(kù)的時(shí)候，我總是調(diào)用[self.database setShouldCacheStatements:YES] 。這意味著對(duì)每個(gè)調(diào)用你不需要再次編譯每個(gè)statement。

我從來沒有找到使用vacuum的好的指引，如果數(shù)據(jù)庫(kù)沒有定期壓縮，它會(huì)越來越慢。我的應(yīng)用會(huì)跑一個(gè)vacuum，但只是每周一次（它在NSUserDefaults里存儲(chǔ)上次vacuum的時(shí)間，然后在開始的時(shí)候檢查是否過了一周）。

如果能auto_vacuum那更好，看pragma statements supported by SQLite列表。

其他酷的東西

Gus Mueller讓我涉及自定義SQLite方法的內(nèi)容。我并沒有真的使用這些東西，既然他指出了，我可以放心的說我能找到它的用處。因?yàn)樗芸帷?/p>

在Gus的帖子里，有一個(gè)查詢是這樣的：

select displayName, key from items where UTTypeConformsTo(uti, ?) order by 2;

SQLite完全不知道UITypes。但是你可以加核心方法，查看-[FMDatabase makeFunctionNamed:maximumArguments:withBlock:]。

你可以執(zhí)行一個(gè)大的查詢來替代，然后評(píng)估每個(gè)對(duì)象。但是那需要更多工作。***在SQL級(jí)就過濾，而不是在將表格行轉(zhuǎn)為對(duì)象以后。

感謝各位的閱讀，以上就是“用SQLite和FMDB而不用Core Data的原因分析”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)用SQLite和FMDB而不用Core Data的原因分析這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！