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的高。