文件 vs SQLite：IM 存储对决

云风说「一个对话一个文件，grep 一下就够了」。10 万条真实消息，四个场景，数据说话。

数据集： — 条消息
JSONL文件： —
SQLite DB： —
「微信的开发人员根本就不懂该怎么储存数据。文本根本就不应该保存在什么数据库(sqlite)里，一个对话一个文本文件追加就可以了。需要搜索的时候 grep 一下性能完全符合需求。」
— 云风，2026.06.29

下面是一个已生成的 IM 消息数据集。选择场景，亲手操作，看两种方案谁更快。

场景一：搜索消息

输入关键词，Grep 全文扫描 vs SQLite 查询。服务端计时，排除网络延迟。

或点击预设词：

场景二：写入消息

发一条新消息，文件 append 一行 vs SQLite INSERT 一条记录。

或点击预设消息：

场景三：复杂查询

「最近 N 天的图片消息」— Grep 需要逐行解析 JSON 并过滤，SQLite 一条 WHERE 解决。

点击预设查询条件：

场景四：删除消息

撤回/删除消息 — 文件方案需要重写整个文件（去掉被删的行），SQLite 原地 DELETE。

或点击预设：

本次操作耗时对比

你刚才所有操作的耗时记录，红色=文件方案，绿色=SQLite。

结论：各有所长

文件方案赢
单次写入（append）
极简场景、纯追加日志
SQLite 赢
搜索、复杂查询、删除
多条件过滤、索引加速
多设备同步
文件 append 无法处理冲突
SQLite 有事务保证一致性
云风的场景
30MB 单文件 grep
在简单场景确实够用

云风说的没有「错」，但前提条件很苛刻：只有 append + 全文搜索两个操作，没有删除、没有按时间/类型过滤、没有多设备同步。一旦需求超出这个极简模型，文件方案的代码复杂度和性能都会急剧恶化。微信作为一个功能齐全的 IM 客户端，选择 SQLite 是工程上合理的决策。

数据集管理

可以重新生成不同规模的数据集来测试性能曲线。

条消息（1000 ~ 1,000,000）