在GreenDao中查询单个数据库对象，最直接且高效的方式是使用queryBuilder().where()配合唯一标识符（如ID）进行精确匹配，并调用.unique()方法获取结果，这能避免加载多余数据并自动处理空值异常。
很多开发者在初次接触GreenDao时，容易陷入“查出来是List还是Object”的困惑，或者因为忘记处理空指针导致应用崩溃，GreenDao的设计哲学就是让数据库操作像操作Java对象一样简单，我们不需要写复杂的SQL语句，也不需要手动解析Cursor，框架已经帮我们封装好了最核心的查询逻辑，下面我们将深入拆解如何精准、安全地查询单个实体,以及在不同场景下的最佳实践。
GreenDao的核心查询入口是DaoSession提供的queryBuilder()方法，当你需要查询单个对象时，第一步是构建查询条件，假设你有一个User实体，且id字段被标记为@Id,这是最典型的单条查询场景。
构建查询链通常遵循以下逻辑：
UserDao实例。queryBuilder()创建查询构建器。where()或whereEq()指定匹配条件。unique()执行查询并返回单个对象。代码实现如下：
这里的关键在于unique()方法，它告诉GreenDao：“我只期望返回一条记录”，如果数据库中没有匹配的记录，unique()会返回null，而不是抛出异常或返回空列表，这一点至关重要,因为它直接决定了你后续代码是否需要做空值判断。
由于unique()可能返回null，因此在实际业务代码中，必须对结果进行判空处理，业内专家指出,忽略空值检查是导致Android应用Crash的主要原因之一。
建议采用以下防御性编程模式：
这种写法不仅安全，而且符合GreenDao的设计预期，它避免了使用list().get(0)这种容易引发IndexOutOfBoundsException的错误做法。
在实际项目中，单一ID查询并不总是够用，有时你需要根据用户名和邮箱的组合来查找用户，或者根据状态和时间范围筛选最新的一条记录，GreenDao支持链式调用where()来组合多个条件。
查找状态为“活跃”且注册时间在最近7天的用户：
这里使用了and()方法来连接多个条件，需要注意的是，unique()在组合条件下依然有效，但如果匹配到多条记录，unique()会抛出DaoException，在设计数据库schema时，确保业务逻辑上的“唯一性”非常重要，如果业务允许存在多条记录，但只需要“最新”或“第一条”，则需要配合orderAsc()或orderDesc()使用。
当存在多条匹配记录时，如果你只想获取其中一条（例如最新创建的用户）,可以通过排序来限制结果。
limit(1)明确告诉数据库引擎，只需要返回第一行数据，这不仅提高了查询效率，还确保了
unique()不会因多条结果而报错，这种模式在处理“最新一条通知”、“最近一次登录记录”等场景时非常实用。
查询单个对象的速度，很大程度上取决于数据库索引，GreenDao允许你在实体类中通过注解定义索引，对于经常用于查询条件的字段,添加索引可以显著提升查询性能。
如果经常通过email字段查询用户，应在User实体中定义索引：
行业共识认为，对于高频查询的字段，建立索引是提升响应速度的关键手段，据工信部相关技术白皮书显示，合理的索引设计可使数据库查询响应时间降低一个数量级，索引并非越多越好，它会增加写入和更新数据的开销，需要根据实际业务场景，权衡读写比例,选择性地添加索引。
虽然GreenDao本身是线程安全的，但查询结果的使用往往涉及UI更新，务必确保数据库查询操作在后台线程执行,而UI更新在主线程进行。
推荐使用RxJava、Coroutine或AsyncTask等异步机制,使用Kotlin协程：
这种模式不仅保证了应用的流畅性，还避免了ANR（ApplicationNotResponding）问题，对于大型应用，数据库查询可能涉及磁盘IO,阻塞主线程会导致严重的用户体验问题。
当查询结果不符合预期时，如何快速定位问题？GreenDao提供了日志功能,可以打印生成的SQL语句。
在DaoMaster或DaoSession初始化时,开启日志：
这样，Logcat中会输出类似SELECTFROMUSERWHEREID=?的SQL语句，通过对比生成的SQL和你的预期条件，可以快速发现参数传递错误或条件拼接问题，使用SQLiteExpert或ADB命令直接查看数据库文件,也是验证数据是否真正写入的有效手段。
unique()方法在匹配到0条记录时返回null，这是正常行为，开发者需自行处理空值，当匹配到超过1条记录时，unique()会抛出DaoException，因为这与“单个对象”的语义冲突，若需处理多条记录但只取其一，应结合limit(1)使用，此时若有多条匹配，返回第一条；若无匹配，返回null。
在绝大多数场景下，使用queryBuilder()更高效且安全。queryBuilder()生成的SQL经过框架优化，且类型安全，避免了SQL注入风险。rawQuery()虽然灵活，但需要手动处理Cursor和类型转换，代码冗长且易出错，除非遇到极其复杂的SQL逻辑（如子查询、联合查询），否则不建议使用rawQuery()，据行业经验，对于常规CRUD操作，queryBuilder()的性能损耗几乎可以忽略不计。
GreenDao支持懒加载和急加载，默认情况下，查询单个User对象时，其关联的Address对象不会立即加载，除非显式调用user.getAddress()且配置了急加载，若需一次性加载关联对象，可在查询构建器中使用join()方法，或在实体配置中设置fetch策略，使用userDao.queryBuilder().join(AddressDao.class).where(...).unique()可获取包含关联数据的User对象，减少数据库往返次数,提升整体查询效率。
微信 
电话 
QQ