Room中手动SQLite分页实现方案及性能疑问

一、实现复杂度仅依赖页大小S的分页+监听已加载范围的可行方案 #

可以通过**游标分页（Seek Pagination）**实现O(S)复杂度的分页，同时结合Flow监听已加载的所有行，具体实现如下：

1. 游标分页核心逻辑
   基于表中唯一且有序的字段（比如自增id、带索引的create_time）进行分页，每次查询以上一页最后一条记录的该字段值为起点，示例SQL：

   SELECT * FROM your_table 
   WHERE id > :lastLoadedId 
   ORDER BY id ASC 
   LIMIT :pageSize
   

   这种方式每次仅查询S条数据，复杂度完全依赖页大小S，避免了OFFSET方案的全表扫描问题（OFFSET会跳过前N*S条，实际扫描行数随页数增加而线性增长）。

2. 结合Flow监听已加载范围
   维护一个maxLoadedId变量（记录已加载的最后一条记录的id），通过Flow监听该范围内的所有记录：

   fun observeLoadedRows(maxLoadedId: Long): Flow<List<YourEntity>> {
       return yourDao.observeRowsUpToId(maxLoadedId)
   }
   
   // DAO层定义
   @Query("SELECT * FROM your_table WHERE id <= :maxId ORDER BY id ASC")
   fun observeRowsUpToId(maxId: Long): Flow<List<YourEntity>>
   

   加载下一页后，更新maxLoadedId为新页最后一条记录的id，Flow会自动监听扩大后的范围。若已加载范围内的记录有字段修改，或者有新记录插入到已加载范围之前（这种场景极少，自增id场景下几乎不会出现），Flow都会及时回调。

   若有序字段存在重复（比如create_time），需结合唯一字段保证排序唯一性，避免漏查或重复：

   SELECT * FROM your_table 
   WHERE (create_time > :lastLoadedTime) OR (create_time = :lastLoadedTime AND id > :lastLoadedId)
   ORDER BY create_time ASC, id ASC 
   LIMIT :pageSize
   

二、当前OFFSET+LIMIT方案的性能问题触发规模 #

你的当前方案（每次查询LIMIT S*(N+1)）会随着页数增加，扫描行数线性增长，性能问题的触发点取决于以下因素：

• 表数据量：当表数据超过1万条，且加载到第10页以上（单次扫描10*S条数据）时，会出现明显查询延迟；若表数据达到10万级，加载第5页就可能卡顿。
• 索引配置：如果查询没有对应排序索引，SQLite会进行全表扫描，性能下降会更早出现（比如几千条数据加载第3、4页就有延迟）。
• 设备性能：低端Android设备上阈值更低，几千条数据加载第5页就可能导致UI卡顿。

本质上，OFFSET的问题在于SQLite需要先扫描并跳过前OFFSET条数据，再取LIMIT条，扫描行数是OFFSET + LIMIT，OFFSET越大，IO和计算开销越高。

内容的提问来源于stack exchange，提问作者Calamity