千万级数据量对SQLite来说已经不算小规模。很多人以为SQLite只适合移动端或小型桌面应用，实际上只要索引和查询写法得当，它也能扛住单机千万级记录。分页查询是这类数据量下最容易暴露性能问题的场景之一，尤其是当你还在用LIMIT pageSize OFFSET pageIndex这种写法时，初始页面可能很快，翻到几千页之后延迟会明显上升。这篇文章会结合一张千万行的用户表，把分页查询的优化路径拆开讲清楚。
SQLite深分页慢的根源：LIMIT OFFSET的扫描成本
先看一条最普通的分页SQL。假设用户表users有一千万条记录，主键是自增的id，现在要取第50001页，每页20条，写法通常是LIMIT 20 OFFSET 1000000。这条语句在SQLite中的执行逻辑并不是直接从第1000001行开始读，而是先按照排序规则读取前1000020行，再丢弃前1000000行，最后返回剩下的20行。即使id列上有主键索引，引擎也需要在索引B-tree中顺序遍历一百万个节点，这一步的CPU和I/O开销会随着OFFSET值线性增长。
更麻烦的是，如果查询返回的列没有完全被索引覆盖，SQLite还需要根据索引中的rowid回到表B-tree中取回完整行数据。深分页时这种回表操作会被放大成大量随机I/O，因为被丢弃的一百万行同样可能经历回表，而实际上那些数据根本不是最终结果。用EXPLAIN QUERY PLAN查看时，经常能看到SCAN users或者USING INDEX idx_users后面跟着大范围扫描，执行耗时随页数加深而明显增加。
这还只是单次查询。如果用户频繁点击页码，后端每次都执行一条深OFFSET查询，数据库连接会长时间被占用，CPU也会被大量无意义的跳行消耗掉。因此单纯给id加索引并不能根治问题，真正需要改变的是分页查询的定位方式。
用键集分页替代OFFSET
键集分页也叫Keyset Pagination或者Seek Method，核心思路是把上一页最后一条记录的排序键保存下来，作为下一页的游标。下一页查询不再告诉数据库跳过多少行，而是直接过滤出排序键大于游标的记录，SQLite就能从索引树的对应位置开始范围扫描，每次只读取页大小个记录，不会因为翻页越来越深而增加扫描量。
SELECT id, username, created_at FROM users WHERE id > 12345 ORDER BY id LIMIT 20;
上面这条例子的12345就是上一页最后一条记录的id。由于id是主键，查询计划会显示SEARCH users USING INTEGER PRIMARY KEY，SQLite直接根据主键索引定位到大于12345的第一条记录，再顺序读取20条，不会触碰之前的数据。无论你翻到第几页，只要游标正确，每次查询的成本基本保持一致。这也是很多移动端拉取列表时使用since_id参数的原因。
不过键集分页也有明显的约束：它只适合顺序翻页，不能随意跳到第100页。而且排序字段必须能唯一确定记录顺序，否则可能会漏掉数据。如果按created_at排序，同一秒可能有多条记录，仅靠时间游标无法保证稳定性。这种情况下可以将主键作为第二排序字段，游标也同时携带两个值，SQLite 3.15以上版本支持行值比较，写法如下：
SELECT id, username, created_at FROM users WHERE (created_at, id) > (:last_created_at, :last_id) ORDER BY created_at, id LIMIT 20;
这样即使两条记录的created_at相同，也会继续比较id，保证分页结果的稳定性和连续性。如果产品必须支持跳页，可以保留一小部分OFFSET分页给低频操作，同时限制最大可跳页数，把高频的上一页下一页全部走键集分页。真正显示总页数时，也不建议每次查询都执行COUNT(*)，可以通过缓存总数或者使用近似数量来降低开销。
索引设计、覆盖查询与参数调优
无论采用哪种分页方式，索引设计都是性能的基础。对于分页查询，索引列顺序要和ORDER BY保持一致，避免SQLite在读取结果后再做一次临时排序。如果查询需要返回username、created_at这些字段，而索引中又包含这些列，SQLite就能直接通过覆盖索引返回结果，不再回表。例如为列表页建立一个组合索引：
CREATE INDEX idx_users_list ON users(created_at, id, username);
这条索引可以支持按created_at排序、用created_at和id做游标的键集分页，同时覆盖username列。查询计划中出现USING COVERING INDEX idx_users_list时，说明SQLite只读取了索引B-tree，没有访问主表，I/O压力会低很多。如果排序方向是倒序，最好把索引也建成降序，SQLite 3.30之后支持DESC索引，例如CREATE INDEX idx_users_list_desc ON users(created_at DESC, id DESC);。
数据库层的一些参数也会影响千万级查询的表现。PRAGMA journal_mode=WAL;可以让读写并发更顺畅，PRAGMA cache_size=-200000;把页缓存扩到200MB，PRAGMA mmap_size=268435456;启用内存映射读取，都能减少磁盘I/O。但参数调优是锦上添花，不能替代正确的SQL写法和索引设计。
PRAGMA journal_mode=WAL; PRAGMA cache_size=-200000; PRAGMA mmap_size=268435456;
如果业务上仍然需要展示总记录数，不要每次分页请求都执行一次全表COUNT(*)。可以单独维护一张计数表，在数据变更时更新，或者使用定期统计的近似值。COUNT(*)在SQLite中如果走整数主键的单列统计可能较快，但如果涉及复杂条件或组合索引，仍可能要扫描大量索引页。把总数计算和分页查询分离，才能让列表接口的整体响应时间稳定下来。
最终回到分页方案本身：对千万级数据，键集分页配合覆盖索引是首选，OFFSET只适合前几十页的低频场景。写SQL前先想清楚排序字段的唯一性，根据查询模式建好索引，再结合WAL和缓存参数，SQLite可以稳定支撑单机大数据量的分页查询。调优过程中要持续用EXPLAIN QUERY PLAN观察执行计划，避免索引未命中或临时排序，这样比盲目增加硬件更有效。
SQLite分页查询千万级数据查询优化修改时间：2026-10-04 03:59:27