SQLite的查询优化器在生成执行计划时，需要依赖表和索引的统计信息来判断各种查询方案的代价，比如决定是走索引还是全表扫描、多张表联接时采用什么顺序。如果统计信息不准确或长期没有更新，优化器就可能做出错误的判断，导致原本很快的查询变得异常缓慢。本文就来详细聊聊SQLite统计信息的更新机制，以及如何通过ANALYZE命令手动收集统计信息。
SQLite统计信息存储在哪里
与MySQL、PostgreSQL这类数据库服务器不同，SQLite并没有独立的后台进程来持续维护统计信息。当你对一张表执行ANALYZE命令后，SQLite会在当前数据库文件中创建一些特殊的内部表，用来存放收集到的统计数据。最核心的是sqlite_stat1表，如果编译时启用了SQLITE_ENABLE_STAT4选项，还会有sqlite_stat4表。
打开sqlite_stat1表可以看到，它只有三个字段：tbl表示表名或索引所属的表，idx表示索引名（如果值为NULL则表示统计的是表本身），stat字段则是一串用空格分隔的数字。第一个数字代表该表或索引的总行数估算值，后面的数字依次表示索引各前缀列的平均重复度。例如一条stat值为"10000 20 2"的记录，含义大致是这张表约有一万行数据，索引第一列平均每个值对应约20行，前两列组合平均对应约2行。
sqlite_stat4表则保存的是更精细的样本数据，它会从索引中抽样记录具体的数据分布情况，包括每个样本在各列上的实际值以及对应的rowid。这种基于样本的统计方式能让优化器对范围查询、不等值条件做出更精确的代价估算，但采样本身也有开销，所以默认的SQLite发行版通常不开启这个特性。
需要注意的一点是，sqlite_stat1这类内部表的名称以sqlite_开头，这是SQLite的保留前缀，开发者不能手动创建同名的表，也不能直接通过普通的DDL语句修改它们的结构，但可以用SELECT语句查看其内容，这对排查优化器的行为非常有帮助。
统计信息什么时候会自动更新
这是最容易产生误解的地方。很多从其他数据库转过来的开发者以为SQLite会在数据变更时自动维护统计信息，实际情况是：SQLite的统计信息一旦生成，除非你再次显式执行ANALYZE，否则它不会随着数据的增删改而自动刷新。哪怕表里的数据从一万行涨到了一千万行，优化器看到的可能还是当初那一万行的统计结果。
不过SQLite提供了一个折中机制：自动运行ANALYZE。通过调用C API中的sqlite3_analyzer相关接口，或者在连接上执行PRAGMA optimize语句，SQLite会根据内部记录的扫描计数来判断哪些表和索引的统计信息可能已经过期。每个 prepared statement 在执行时都会累计其使用索引的行数，PRAGMA optimize会检查这些计数，发现某个索引被扫描的次数远超统计信息中记录的预期值时，就认为统计信息失真了，从而自动对相关表重新执行ANALYZE。
推荐的做法是在关闭数据库连接之前调用一次PRAGMA optimize。官方文档建议应用在正常关闭数据库时执行这条语句，它只做必要的分析工作，开销通常很小。对应的C代码大致如下：
sqlite3 *db;
sqlite3_open("app.db", &db);
// ... 正常的业务操作 ...
// 关闭连接前优化统计信息
sqlite3_exec(db, "PRAGMA optimize;", NULL, NULL, NULL);
sqlite3_close(db);另外还有一种极端情况：如果数据库从未执行过任何ANALYZE，sqlite_stat1表根本不存在，此时优化器会采用非常保守的默认假设，比如认为每个索引查找大约会匹配10行数据。这种粗略估算在数据分布均匀的小型应用中问题不大，但在数据倾斜明显的场景下很容易选出糟糕的执行计划。
手动执行ANALYZE的最佳实践
当明确知道数据发生了大规模变化时，手动收集统计信息是更可靠的方式。ANALYZE命令支持几种不同粒度的写法：直接执行ANALYZE会分析整个数据库中所有表和索引；ANALYZE table_name只分析指定的表及其索引；而新版本SQLite还支持ANALYZE sqlite_schema这种形式，即分析schema本身。对于体量很大的库，全库分析可能耗时较长，按需分析单张表是更务实的选择。
下面的SQL演示了常见的用法：
-- 分析整库所有表 ANALYZE; -- 只分析orders表及其上的索引 ANALYZE orders; -- 查看收集到的统计结果 SELECT * FROM sqlite_stat1; -- 删除统计信息（重新开始统计） DELETE FROM sqlite_stat1; -- 删除后需要重新分析才能生效
执行ANALYZE的时机也有讲究。最好在数据批量导入或大规模删除完成之后再执行，而不是在导入过程中反复运行，因为每次分析都要完整扫描索引，频繁执行反而拖慢写入速度。对于每天都有大量数据变化的业务库，可以在夜间任务或应用启动时安排一次分析。还有一个实用技巧是先用DELETE清空sqlite_stat1再执行ANALYZE，这在某些升级场景下可以让统计信息完全重建，避免新旧数据混杂。
关于采样精度，ANALYZE命令支持指定采样的数量，例如ANALYZE orders WITH 32会为每个索引采样32个数据点（需要开启STAT4特性）。样本越多估算越准，但分析耗时和sqlite_stat4表的体积也会增加，一般默认值已经够用，只有在遇到明显的执行计划问题时才需要调整。
统计信息过期引发的典型问题
统计信息失真的危害在联接查询中体现得最明显。假设优化器根据旧的统计信息认为某张表只有几千行，于是选择它作为外层循环表；但实际上这张表已经增长到几百万行，导致内层循环被执行了数百万次，查询时间从毫秒级膨胀到分钟级。这类问题在应用上线初期往往没有征兆，随着数据积累逐渐暴露，而且由于执行计划是优化器自动选择的，开发者从业务代码层面很难定位原因。
排查这类问题时，EXPLAIN QUERY PLAN是第一工具。它会输出优化器实际选择的访问路径，如果发现明明有合适的索引却走了全表扫描，或者联接顺序明显不合理，就应该怀疑统计信息是否过期。此时对比sqlite_stat1中记录的行数与实际COUNT(*)的结果，往往能立刻发现问题。补充一句，COUNT(*)本身也是全表扫描，大表上执行要谨慎。
-- 查看优化器当前选择的执行计划 EXPLAIN QUERY PLAN SELECT o.id, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.amount > 100; -- 对比统计信息与真实行数 SELECT stat FROM sqlite_stat1 WHERE tbl = 'orders'; SELECT COUNT(*) FROM orders;
总结一下，SQLite统计信息的管理本质上是把主动权交给了开发者：它不会替你自动保持数据画像的准确，但提供了ANALYZE命令和PRAGMA optimize这两个轻量的手段。养成在批量数据变更后手动执行ANALYZE、在关闭连接前调用PRAGMA optimize的习惯，再配合EXPLAIN QUERY PLAN定期审查关键查询的执行计划，就能让SQLite的优化器始终基于准确的数据分布做出决策，避免那些莫名其妙慢下来的查询。
SQLite统计信息ANALYZE命令查询优化修改时间：2026-09-15 22:43:36