SQLite是否支持O(1)时间复杂度获取表的总行数？

SQLite 没有内置O(1)行数查询的核心原因 #

SQLite 设计阶段就没有选择持久化存储每张表的精确行计数，核心是为了避免引入额外的事务锁开销：如果全局存储行数值，所有写入、删除操作都要同步更新这个计数，多事务并发场景下会严重拖慢普通读写性能，不符合其嵌入式轻量数据库的定位，属于功能取舍的结果。

针对你的场景的可行方案 #

• 如果可以接受近似值，除你提到的dbstat方案外，也可以用SELECT max(ROWID) FROM 表名，只要表没有过删除ROWID中间区间数据的操作，误差极低，复杂度为O(1)，你如果明确不希望依赖ROWID可以跳过该方案。
• 如果必须要精确值且不依赖索引，目前没有原生的O(1)实现，只能使用SELECT COUNT(*) FROM 表名，它的O(n)耗时在百万行以内的表中完全可以满足普通业务需求。
• 如果可以接受少量额外维护成本，可自行实现精确的O(1)计数：
  1. 单独建计数表：CREATE TABLE table_row_counts(table_name TEXT PRIMARY KEY, row_count INTEGER NOT NULL DEFAULT 0)
  2. 为目标表创建INSERT/DELETE/UPDATE触发器，每次数据变更时同步更新计数表中对应表的行数值
  3. 后续查行数直接读取计数表对应记录即可，复杂度为O(1)且结果完全精确

现有方案的补充说明 #

• 传入索引列的COUNT(索引列)更快的本质是索引体积远小于全表数据，扫描IO开销更低，仍然是O(n)复杂度，只是常数项更小。
• dbstat的sum(ncell)统计的是B树的页单元总数，包含未被VACUUM回收的已删除数据空位，所以结果是近似值，仅适合做规模估算使用。

内容的提问来源于stack exchange，提问作者Enter Display Name Here