辨析标准 SQLite 持久化统计表主要是sqlite_stat1sqlite_stat4在启用SQLITE_ENABLE_STAT4编译选项且运行 ANALYZE 时可能出现更细粒度样本。并无广泛意义上的sqlite_stat3作为通用第三张系统表——若文档仍写 stat3多为笔误或其它系统请以目标发行版的sqlite_master与官方 fileformat 文档为准。1 ANALYZE 在干什么扫描索引 B-Tree 叶节点采样键分布写入统计表ANALYZE全库ANALYZE tbl针对相关对象代价大表上可能耗时与 I/O 显著应在维护窗口或异步任务跑。2 sqlite_stat1 结构直觉存每个索引的近似摘要供优化器估计等值命中行数、范围扫描行数。可用谨慎查询SELECT*FROMsqlite_stat1LIMIT5;勿在生产手工乱改行除非你做科研正规路径是重新 ANALYZE。3 sqlite_stat4若可用提供更丰富样本利于高相关列、倾斜分布二进制构建未开 STAT4 时根本没有这张表。部署文档应写明是否启用 STAT4。4 统计过期的典型性能症状同样 SQL升级数据量后延迟突然线性变差EXPLAIN QUERY PLAN从索引扫描退化为全表扫描批量导入/大批量 DELETE 后未及时更新。5 手动更新策略场景建议日终批导导入结束ANALYZE affected_tables周期任务周/月全库ANALYZE视体量仅热点表ANALYZE hot_table缩短窗口与迁移同发schema 变更 新索引后必 ANALYZE6 批量维护与自动化Shell/cronsqlite3 app.db ANALYZE;失败告警不要把 ANALYZE 放在「静默脚本」里吞错误。PRAGMA optimize若版本支持可对需要分析的表做启发式维护——读官方说明再启用。7 与 VACUUM 的关系物理紧缩不自动等价于统计刷新大维护后常见组合拳VACUUM按需→ANALYZE。8 开源仓库实践CI生成测试库后ANALYZE让EQP 测试稳定。Release note若统计格式变提醒用户升级后跑一次 ANALYZE。9 批量窗口与「analyze 本身变慢」时的拆表策略大表全库ANALYZE若超过允许窗口可改为按表排队先对JOIN 最多的维度表、再事实表每段记录开始/结束时间与行数快照。若夜间仍不够考虑降低写入峰值合并批处理或读副本上 analyze 再决定是否主库执行谨慎副本统计不一定等同于主库仅作近似。嵌入式设备可把 ANALYZE 绑在充电Wi‑Fi场景避免用户前台卡顿。10 与查询计划的反馈闭环建议在应用侧对TOP N 慢 SQL自动归档「上次 ANALYZE 时间戳」若慢查询在大批量导入后集中爆发告警优先级应高于「CPU 飙高」。统计维护本质是让优化器与数据分布再对齐而不是运维日历上的装饰品。11 与「只读副本」统计的边界若你在工程上维护主从文件拷贝非 SQLite 内置复制在副本上ANALYZE得到的统计仅对副本有效主库若继续大量写入把统计文件抄回主库是错误操作。正确做法仍是在主库低峰或业务可接受窗口执行或接受基于主库采样的在线估算若自研统计中间件。总结统计是优化器的眼睛过期则计划瞎。把 ANALYZE 纳入数据生命周期导入后、删改后、索引变更后比事后集体救火便宜。