消息记录管理不是"把消息存数据库"就完事。消息量涨起来之后，查询越来越慢、存储成本越来越高、老数据不敢删又占空间。要解决的是存储分层、检索设计、归档清理三个问题。
一、存储分层——热数据冷数据分开
最近的消息查询频繁，要快；历史消息偶尔查，便宜就行。所以消息存储要分层。热数据——最近7天或30天的消息，存数据库或高速缓存，保证查询速度。冷数据——更早的消息，存对象存储或归档表，压缩存储降低成本。
分层的工程要点是切分规则和查询路由。切分规则——按时间切分，超过阈值自动归档。查询路由——查最近消息走热库，查历史消息先查热库再查冷库。简单做法是按时间范围路由，查询区间落在冷区的自动走冷库。
二、检索设计——按什么查得快
消息记录的价值在于能查。查询维度通常有三个：按用户查（这个用户都聊了什么）、按时间查（某天有多少消息）、按内容查（哪些消息提到了退款）。
按用户和时间查，建索引就够了——用户ID加时间的联合索引。按内容查就麻烦，要全文检索或搜索引擎。消息量小用数据库全文索引，消息量大上搜索引擎。设计要点是索引不能建太多——每个索引都拖慢写入，写入频繁的场景要权衡。
三、归档与生命周期
消息不能无限存。生命周期管理要做三件事：归档、降采样、清理。归档——超期消息从主库移到归档库。降采样——部分消息只保留元数据（时间、发送者、类型），内容体删除。清理——超过合规保留期的彻底删除。
清理要按规则自动执行，不能靠人工。人工清理的现实是没人想起来清，磁盘一直涨。同时清理要留审计痕迹——删了什么、什么时候删的，要能追溯。
消息记录管理方案对照
数据层 | 存储介质 | 保留周期 | 查询方式 |
|---|---|---|---|
热数据 | 数据库/缓存 | 7-30天 | 索引直接查 |
冷数据 | 对象存储 | 半年-1年 | 归档表查询 |
元数据 | 主库 | 长期 | 轻量字段查询 |
消息记录分层存储实现
class MessageRepository: def __init__(self): self.hot_db = HotDB() # 热库 self.cold_store = ColdStore() # 冷库 self.archive_days = 30 # 归档阈值 def save(self, msg): # 写入：先落热库 self.hot_db.insert({ "msg_id": msg.msg_id, "wxid": msg.wxid, "type": msg.type, "content": msg.content, "created_at": msg.created_at }) def query(self, wxid, start, end, keyword=None): # 查询路由：按时间范围决定走哪层 results = [] if end >= time.time() - self.archive_days * 86400: results += self.hot_db.query(wxid, start, end) if start < time.time() - self.archive_days * 86400: results += self.cold_store.query(wxid, start, end) if keyword: results = [r for r in results if keyword in r.content] return results def archive(self): # 归档：超期消息移冷库 deadline = time.time() - self.archive_days * 86400 old_msgs = self.hot_db.query_before(deadline) for msg in old_msgs: self.cold_store.write(msg) # 写冷库 self.hot_db.delete(msg.msg_id) # 删热库 self.audit_log("archive", len(old_msgs)) def cleanup(self, retain_days=365): # 清理：超合规保留期彻底删 deadline = time.time() - retain_days * 86400 deleted = self.cold_store.delete_before(deadline) self.audit_log("cleanup", deleted) # 留审计痕迹落地建议
存储分层是必需的——热数据保查询速度，冷数据降成本，不分层迟早又慢又贵。检索按维度建索引——用户和时间建联合索引，内容检索量大要上搜索引擎。归档和清理自动化——靠人工清理等于不清理，磁盘只会一直涨。清理留审计痕迹——删了什么要能追溯。微信侧的消息接收和字段定义由Eyun这类个人微信API平台 提供，分层存储和归档策略在自建服务实现，接口字段以平台开发文档为准。
