Greendao中like與eq的差異

好久沒更博了，主要是懶，一直在過養老閒散生活，對什麼都沒什麼激情；然而最近跟一個以前的學生小妹妹聊天，發現小妹妹現在進步很大，涉及的領域已經遠超於我這個曾經的半吊子老師，於是內心泛起了漣漪，覺得必須得試着改變目前的這種現狀；於是就有了繼續更博的想法。

最近在做一個人臉領包的項目，即通過刷臉判斷是否在賽事報名表中，如果在打印小票，用戶拿着小票去對應窗口領取賽事物品，參加過馬拉松的應該很容易理解；由於是多終端運行的一個項目，故其中有一個功能是需要同步服務器的領包數據到本地，以此判斷選手是否重複領包；需求簡單明確，對於稍微寫過幾年代碼的應該都會做；然而對於數據量小的可能看不出差距，然而坑爹的是我們數據量很大，而且應用場景網絡不能保證，這就出現了一個很尷尬的問題，同步時間過長，忍受不了。

同步功能主要涉及兩個表，一選手名單表，包含每位報名選手的基本信息；二領包記錄表，選手每領一次記錄領取的類型，時間等；小型賽事選手錶至少4、5千，大型賽事選手錶會過萬；而領包數據理論上會超過選手錶，因爲這之中可能存在重複或者出錯的記錄，領包表中的數據只有插入，沒有刪除和更新，每次都是一條新的記錄，爲了方便跟蹤。
選手錶和領包記錄表是通過號碼牌進行關聯對應的，而這個號碼牌是由字母和數字組成，之前爲了方便搜索，選手錶中號碼牌的搜索查詢是直接用的like模糊匹配，即不區分字母的大小寫。
同步服務器領包記錄時對於本設備沒有的數據除了基礎的領包記錄信息以外還需要選手錶中的一些其他信息，即領包記錄在插入領包記錄表時需要去選手錶中查詢選手信息。這就意味着有兩次查詢，一是查詢領包記錄表中是否已經有某個時間點的領包記錄，二是查詢選手錶獲取選手信息；兩個表的數據都過萬，以下是我最開始的查詢語句。

選手錶的查詢完全是偷懶行爲，尋思直接可以複用，就直接調用了。

此番操作，你都想不到執行時間有多麼的慢。淚崩啊。

同步數據8202條，其中耗費的時間如下：
開始處理時間—>>2019-12-26 10:51:00.589
結束處理時間—>>2019-12-26 10:57:03.951

以上的同步時間肯定是不能接受的，於是開始想法優化，剛開始以爲是for循環的引起的時間消耗，但是實驗之後發現不是還是數據庫查詢引起的，優化數據庫成了重點；兩種方式，一建立索引，二是優化查詢語句。

同步數據還是8202條，其中耗費的時間如下：
開始處理時間—>>2019-12-26 11:38:23.370
結束處理時間—>>2019-12-26 11:40:57.640
like與eq的差別
以下是greendao中的eq和like的封裝方法：

LIKE：全表搜索，未使用索引，效率低；
EQ：全表搜索，使用索引，效率較LIKE高；
對於沒有建索引的表，like和eq的搜索效率基本沒太大的差異，但是對於使用了索引的表，eq的效率就會明顯比like的高。