邮件客户端的核心体验之一，是用户在没有网络的情况下依然能够浏览历史邮件、搜索内容和查看附件。要做到这一点，客户端必须把服务端的邮件数据缓存在本地，并且能够高效地增删改查。SQLite作为一个嵌入式数据库，不需要独立的服务进程，支持事务和丰富的索引类型，天然适合承担这个角色。Outlook、Thunderbird以及大量移动端邮件应用都在使用SQLite或其衍生方案来管理本地数据。
邮件数据的表结构设计思路
设计邮件缓存的第一步是弄清楚哪些数据需要落库。一封邮件通常包含唯一标识、主题、发件人、收件人列表、时间戳、标记状态、所属文件夹以及正文和附件等。如果把这些字段一股脑塞进一张表，列表查询时会把大字段也读出来，造成内存和IO的双重浪费。比较合理的做法是把邮件元数据和正文拆开存储。
典型的元数据表只保存列表展示需要的字段，正文单独放一张表，通过邮件ID关联。这样邮件列表滚动时只需要扫描小表，点开某封邮件时再按需读取正文，性能差异非常明显。下面给出一个简化的建表示例：
CREATE TABLE mail_meta (
id INTEGER PRIMARY KEY AUTOINCREMENT,
uid TEXT NOT NULL UNIQUE, -- 服务端唯一标识
folder_id INTEGER NOT NULL,
subject TEXT NOT NULL,
sender TEXT NOT NULL,
recipients TEXT,
sent_at INTEGER NOT NULL, -- 收信时间戳
is_read INTEGER DEFAULT 0,
is_starred INTEGER DEFAULT 0,
size INTEGER DEFAULT 0
);
CREATE TABLE mail_body (
mail_id INTEGER PRIMARY KEY,
body_html TEXT,
body_text TEXT
);
CREATE INDEX idx_meta_folder_time ON mail_meta(folder_id, sent_at DESC);附件信息同样建议独立成表，记录文件名、MIME类型、大小以及本地存储路径。会话功能则可以引入conversation表，通过主题归一化算法把同一串往来的邮件聚合起来。拆表带来的好处是各表都可以按自己的访问模式建立索引，避免一个巨大的宽表导致索引膨胀。
索引策略与列表查询性能优化
邮件客户端最高频的操作是按文件夹加载列表，并且通常按时间倒序排列。为folder_id和sent_at建立联合索引是基本要求，这样查询可以直接走索引顺序，避免filesort。需要注意的是，用户还经常按已读未读、星标状态筛选，如果筛选条件是高频操作，可以考虑把这些状态列并入索引或者使用部分索引。
另外一个容易被忽视的点是分页方式。用OFFSET分页在数据量大时会越来越慢，因为SQLite需要跳过前面的所有行。改用基于时间戳或ID的游标分页，每次只取上一页最后一条记录之前的数据，性能就能保持稳定：
-- 使用游标分页代替 OFFSET SELECT id, uid, subject, sender, sent_at, is_read FROM mail_meta WHERE folder_id = 3 AND sent_at < 1719000000 ORDER BY sent_at DESC LIMIT 50;
除了索引设计，还需要关注写操作的合并。新邮件批量同步时，逐条INSERT并各自提交事务会产生大量磁盘同步开销，把几百封邮件放进一个事务里提交，速度往往能提升一个数量级。对于已读状态这类频繁的小更新，可以使用WAL模式让读写并发互不阻塞，客户端在设置时执行PRAGMA journal_mode=WAL即可。配合合理的cache_size和mmap_size参数，SQLite在移动设备上也能轻松应对数万封邮件的缓存规模。
全文搜索与FTS5的落地实践
搜索是邮件客户端的刚需，LIKE模糊匹配在数据量大时性能很差，而且无法处理分词问题。SQLite自带的FTS5扩展提供了倒排索引能力，非常适合本地全文搜索场景。做法是创建一个FTS5虚拟表，把邮件的主题和正文文本写入其中，查询时用MATCH语法即可获得毫秒级响应。
CREATE VIRTUAL TABLE mail_fts USING fts5(
subject, body_text,
content='', -- 无内容表模式，文本由触发器同步
tokenize='unicode61'
);
-- 插入搜索索引，rowid与mail_meta的id对应
INSERT INTO mail_fts(rowid, subject, body_text)
VALUES (123, '季度报告', '本季度销售数据如下……');
-- 执行全文搜索
SELECT rowid FROM mail_fts
WHERE mail_fts MATCH '季度 报告'
ORDER BY rank LIMIT 20;FTS5支持外部内容表模式，可以避免正文数据存两份占用双倍空间，但配置相对复杂，需要用触发器保持索引与源表同步。中文用户还需要注意分词问题，unicode61分词器对中文的支持有限，若搜索质量要求高，可以在写入前先用分词库把中文文本切分成空格分隔的词再入索引。
增量同步与缓存淘汰机制
本地缓存不是一次性写入的静态数据，它必须与服务端保持增量同步。IMAP协议提供了UIDVALIDITY和UID机制，客户端记录每个文件夹已同步的最大UID，下次连接只拉取新增部分即可。已删除的邮件则通过标记或UID集合比对来清理。为了减少重复拉取，还可以把邮件头部的缓存有效期控制在合理范围内，避免每次打开客户端都全量刷新。
磁盘空间管理同样重要。邮件缓存会随时间无限增长，需要设计淘汰策略，比如正文缓存只保留最近N个月的邮件，更早的邮件只保留元数据，用户点开时再按需从服务端拉取正文。淘汰操作应放在事务里批量执行，并在执行后触发VACUUM或使用auto_vacuum参数回收空间。另外建议对附件本地文件做定期扫描，删除数据库中已不存在对应记录的孤儿文件，防止磁盘被无效数据慢慢占满。
综合来看，SQLite为邮件客户端本地缓存提供了完整的能力：用拆分表结构控制IO，用联合索引和游标分页保证列表流畅，用FTS5实现本地搜索，用增量同步和淘汰机制控制数据规模。把这些环节设计到位，客户端就能在离线场景下依然保持接近原生的使用体验。