本文由微信客户端技术团队工程师“Jon”分享，原题“Windows*消息数据库架构演进”，有较多修订。
1、引言本文分享的是，微信客户端团队基于对微信用户日常使用场景和数据分析，通过分离重要和非重要数据、采用可靠的分库策略等，对微信Windows端IM本地数据库的架构进行的优化和改造，并最终得到一个具备良好实践效果的技术改造方案。
微信的Windows客户端自2014年上线以来，用户数稳步增长。随着时间的不断推移，很多用户本地积攒的消息量越来越大。
最初的本地IM数据库设计秉着遵循“简单易用、方便管理”的原则，把用户收到的所有消息都统一存放在用户当前客户端本地的“同一个SQLite数据文件中”。
(作者注：微信不会保存聊天记录，聊天内容只存储在用户手机、电脑等终端设备上。)
3、当前问题由于初期这套本地数据库设计方案的短板，随着目前微信使用越来越广泛、消息堆积越来越多，从而逐渐暴露出了许多技术问题。
3.1 问题1：数据查询慢随着使用时间的推移，数据也逐渐增多，当数据量越来越庞大：
- 1）数据库的查询和插入效率会受到影响；
- 2）即使消息数据库存在索引，索引的查询效率也随之下降。
从文件系统的角度，数据库文件是逐页增长的。因为长时间的使用微信会使得消息量的逐步累积，让数据库体积逐渐增长，也会导致碎片化更严重，这在机械硬盘下，也会进一步影响读写效率。
对用户最直观的影响就是——切换聊天变得很卡，这个问题对于重度用户尤甚，甚至会出现点击聊天就卡顿的情况。
3.2 问题2：存储文件大随着时间的推移，消息量的逐步累积，数据库存储文件的体积也是越来越大，显著占用用户存储空间。
3.3 问题3：磁盘文件损坏磁盘文件意外损坏也有可能导致数据丢失。
因为所有消息都放到一个数据库文件，就类似把所有鸡蛋放在一个篮子。
数据库文件也可能会因为存储坏道、电脑意外断电、sqlite自身bug等原因导致数据库文件发生损坏。如果发生损坏时，有可能导致用户丢失消息数据。即使有DB恢复机制，也无法保证能恢复出所有历史记录。
当这种情况发生时，对用户影响十分大，因为聊天记录可能没了！
PS：微信移动端也有类似困扰，有兴趣可以阅读《微信客户端SQLite数据库损坏修复实践》。
4、原因分析4.1 概述上述数据库存储文件变大和查询变慢的问题，都是由于消息数据的不断增多引起。
但消息数的增长是无法避免的，那么有没有办法控制增长速度，并且控制数据库的大小？
我们从两个方向进行分析：消息情况、日常使用场景
4.2 分析1：消息情况微信里的IM消息可分为三大类：
- 1）单人聊天消息；
- 2）群聊消息；
- 3）以及订阅号/服务号消息（统称为公众号消息）。
按消息的重要性来说：
- 1）单聊/群聊消息：这是用户的私人消息，被删除或者丢失无法恢复，对用户损失最大；
- 2）公众号的消息：因为只要关注了公众号，都可以拉取阅读，属于公共消息，所以对用户来说重要性稍低。
按消息的大小来说：
- 1）基于对测试帐号的消息大小数据分析，我们发现：占总条数比例不高的公众号消息，占用了超过一半的数据库空间；
- 2）经过对测试帐号消息类型的分析：网页卡片类消息是公众号消息的主要类型，其平均消息体大小是文本消息的几十倍。
众所周知，我们日常使用微信，都是收发消息，或者浏览最近的消息。对于更早的消息，我们一般很少会主动去浏览。
越早的消息，浏览的概率越低。
所以：在大多数场景下，我们要让最常访问的消息，不受老数据的影响。
5、解决方案5.1 概述针对前述问题并结合上述分析，我们从以下方面对微信Windows端本地SQLite数据库的架构进行了演进和优化。
涉及的主要优化内容和手段有：
- 1）分库改造；
- 2）建立消息索引；
- 3）消息体积优化；
- 4）提高数据库健壮性。
下面我们将逐一详细介绍。
5.2 分库改造基于以上分析，首先把公众号消息划分出去，存到单独的一个数据库，跟用户的普通消息隔离，同时也可以大幅减少普通消息数据库的体积。
基于日常使用场景的分析，大部分老数据读取的频率很低，所以应该提高最近一段时间的读写效率。
对于上述这种情况，我们采取了以时间和空间动态划分数据库的方案。初始默认值是每个数据库存放半年的消息，超过时间之后新建一个数据库存放。对于大部分使用场景，我们只需要读写最新的数据库就可以满足需求，如果需要浏览更早的消息，可以再打开之前的数据库进行读取。
除了时间维度，我们还考虑了空间维度的划分：如果半年内消息普通消息规模超过阈值，也会新建一个数据库进行存储，让每个数据库大小和数据规模不至于太大，能提升最近一段时间消息的读写效率。
对于最广泛的使用场景——查看每一个聊天的消息，这种场景需要对每一个聊天会话建立一个索引。
这里的索引方案我们参考了安卓端：即将每一个聊天转换成一个数值型的ID，从而减少每条索引的长度，提高索引的读写效率。（关于微信的移动端SQLite完整数据库结构，可以参考：《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》）
除此之外，我们还对一些经常访问的内容，单独提取成为一个字段，并且增加索引。比如消息的子类型（这个在老数据库中是一个序列化字段），它没有索引，但这个字段经常需要用到，所以单独提出成为一列，并且加上索引，为消息按类型查找提供方便。
5.4 消息体积优化IM中消息显然总是会越来越多的，但如何能够在不影响读写效率的同时，减少/压缩消息数据的体积，也是我们的优化方向。
从上面的数据看，部分消息体积较大，已经超过了数据库每页的大小（Page Size）。
数据库是按页存储数据的，Page Size是数据库一页能够容纳的数据。如果一条数据，一个页放不下，就需要用到溢出页，把多出来放不下的数据放到溢出页中，溢出页可以有多个。
这时候，如果读取这条数据，就需要把溢出页也全部读出来，会增加IO的消耗。
如果压缩数据，能够把消息体压缩到一个页能放得下，减少溢出页的使用，是可以增加IO性能的。
SQLite数据库溢出页结构：
