微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等

本文由微信客户端技术团队工程师“Jon”分享，原题“Windows微信：消息数据库架构演进”，有较多修订。

1、引言

本文分享的是，微信客户端团队基于对微信用户日常使用场景和数据分析，通过分离重要和非重要数据、采用可靠的分库策略等，对微信Windows端IM本地数据库的架构进行的优化和改造，并最终得到一个具备良好实践效果的技术改造方案。

 

以下是相关技术文章，有兴趣的读者可以一并阅读：

1. 微信客户端SQLite数据库损坏修复实践
2. 微信移动端的全文检索优化之路
3. 微信移动端的全文检索多音字问题解决方案
4. 微信iOS端的最新全文检索技术优化实践
5. 微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]

学习交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4034-1-1.html）

2、背景说明

微信的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）经过对测试帐号消息类型的分析：网页卡片类消息是公众号消息的主要类型，其平均消息体大小是文本消息的几十倍。

4.3 分析2：日常应用场景分析

众所周知，我们日常使用微信，都是收发消息，或者浏览最近的消息。对于更早的消息，我们一般很少会主动去浏览。

越早的消息，浏览的概率越低。

所以：在大多数场景下，我们要让最常访问的消息，不受老数据的影响。

5、解决方案

5.1 概述

针对前述问题并结合上述分析，我们从以下方面对微信Windows端本地SQLite数据库的架构进行了演进和优化。

涉及的主要优化内容和手段有：

• 1）分库改造；
• 2）建立消息索引；
• 3）消息体积优化；
• 4）提高数据库健壮性。

下面我们将逐一详细介绍。

5.2 分库改造

基于以上分析，首先把公众号消息划分出去，存到单独的一个数据库，跟用户的普通消息隔离，同时也可以大幅减少普通消息数据库的体积。

基于日常使用场景的分析，大部分老数据读取的频率很低，所以应该提高最近一段时间的读写效率。

对于上述这种情况，我们采取了以时间和空间动态划分数据库的方案。初始默认值是每个数据库存放半年的消息，超过时间之后新建一个数据库存放。对于大部分使用场景，我们只需要读写最新的数据库就可以满足需求，如果需要浏览更早的消息，可以再打开之前的数据库进行读取。

除了时间维度，我们还考虑了空间维度的划分：如果半年内消息普通消息规模超过阈值，也会新建一个数据库进行存储，让每个数据库大小和数据规模不至于太大，能提升最近一段时间消息的读写效率。

5.3 建立消息索引

对于最广泛的使用场景——查看每一个聊天的消息，这种场景需要对每一个聊天会话建立一个索引。

这里的索引方案我们参考了安卓端：即将每一个聊天转换成一个数值型的ID，从而减少每条索引的长度，提高索引的读写效率。（关于微信的移动端SQLite完整数据库结构，可以参考：《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》）

除此之外，我们还对一些经常访问的内容，单独提取成为一个字段，并且增加索引。比如消息的子类型（这个在老数据库中是一个序列化字段），它没有索引，但这个字段经常需要用到，所以单独提出成为一列，并且加上索引，为消息按类型查找提供方便。

5.4 消息体积优化

IM中消息显然总是会越来越多的，但如何能够在不影响读写效率的同时，减少/压缩消息数据的体积，也是我们的优化方向。

从上面的数据看，部分消息体积较大，已经超过了数据库每页的大小（Page Size）。

数据库是按页存储数据的，Page Size是数据库一页能够容纳的数据。如果一条数据，一个页放不下，就需要用到溢出页，把多出来放不下的数据放到溢出页中，溢出页可以有多个。

这时候，如果读取这条数据，就需要把溢出页也全部读出来，会增加IO的消耗。

如果压缩数据，能够把消息体压缩到一个页能放得下，减少溢出页的使用，是可以增加IO性能的。

SQLite数据库溢出页结构：

(上图引用自书籍《The Definitive Guide to SQLite》第308页)

PS：《The Definitive Guide to SQLite》这本书的电子版我也给你找到了，请从下面附件处下载：

 The Definitive Guide to SQLite (2nd edition, 2010)-52im.net.pdf.zip (3.61 MB)

但是压缩需要占用CPU资源，这里选择一种能够平衡性能和压缩率的算法是关键。

经过对比压缩算法的Benchmark，并且对消息体压缩性进行实测，最终选择了一个高性能压缩算法：lz4。

经过对测试帐号的数据分析，不同类型的消息体大小差异较大。

一般来说：文本消息的长度不会特别大，但是网页卡片类型的消息，体积会较大。由于不同的消息长度，获得的压缩率不一样，太短的文本长度，压缩起来并没有意义。

所以经过消息体长度、压缩、，压缩性能的分析，最终确定对网页卡片等进行压缩，在较低性能消耗的前提下，综合压缩率可达到40%，减少了IO次数 。

5.5 提高健壮性

如果数据库文件由于外部原因发生损坏，则会对体验造成较大影响。降低损坏率和减少损坏带来的数据损失，也是我们改进的方向。

按照时间维度划分数据库之后，相当于把消息按时间分散存储。最新的数据库负责读写最近的消息，其余的数据库只需要根据需求支持浏览查看消息。

对于老数据库而言：可以做到按需加载，从而减少了对数据库的读写，也减少了这些数据库损坏的几率。一旦有数据库出现损坏，即使无法恢复，也不会所有消息全部丢失，只会丢失该数据库对应时间段的消息，这也可以减少部分数据库损坏带来的损失。

在早期使用的单数据库架构中，由于数据会越攒越多，数据库体积会持续变大，很难去做备份。分库之后，每个数据库体积变小，因而数据库备份变得更为可行。因为最新的数据库存在频繁的消息读写，发生损坏的概率远高于老数据库，所以这里对最新的一个数据库做定期的备份。

默认配置下，我们每间隔一段时间会对最新的数据库进行一次备份，该备份是最新的一个数据库的完整拷贝。若最新的数据库在读写时发生损坏，会先尝试从备份数据恢复。若恢复成功，则最多丢失从备份到恢复这段时间的数据，进一步降低损坏造成的损失。

6、优化对比

经过对比，对于一个在测试帐号中原始的消息数据库，压缩后大小可以减少接近一半，同时溢出页数和需要使用溢出页的记录数减少也超过一半。

对于读写性能，对比压缩前，压缩后的读取和解压缩性能比之前有接近10%的提升。

7、未来展望

后续我们微信客户端团队将继续研究数据库修复相关的实践，持续关注数据库相关的性能数据，提升可靠性，打造更好的用户体验！

附录：更多大厂IM文章汇总

[1] 微信团队原创技术文章：

1. 《微信朋友圈千亿访问量背后的技术挑战和实践总结》
2. 《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》
3. 《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
4. 《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
5. 《微信团队原创分享：iOS版微信的内存监控系统技术实践》
6. 《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
7. 《微信团队分享：视频图像的超分辨率技术原理和应用场景》
8. 《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
9. 《微信团队分享：微信Android版小视频编码填过的那些坑》
10. 《IM全文检索技术专题(一)：微信移动端的全文检索优化之路》
11. 《企业微信客户端中组织架构数据的同步更新方案优化实战》
12. 《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
13. 《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
14. 《一篇文章get微信开源移动端数据库组件WCDB的一切！》
15. 《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
16. 《微信后台基于时间序的海量数据冷热分级架构设计实践》
17. 《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
18. 《微信后台团队：微信后台异步消息队列的优化升级实践分享》
19. 《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
20. 《微信Mars：微信内部正在使用的网络层封装库，即将开源》
21. 《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
22. 《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
23. 《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
24. 《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
25. 《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
26. 《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
27. 《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
28. 《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
29. 《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
30. 《如何解读《微信技术总监谈架构：微信之道——大道至简》》
31. 《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
32. 《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
33. 《微信朋友圈海量技术之道PPT [附件下载]》
34. 《微信对网络影响的技术试验及分析（论文全文）》
35. 《一份微信后台技术架构的总结性笔记》
36. 《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
37. 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
38. 《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
39. 《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
40. 《全面总结iOS版微信升级iOS9遇到的各种“坑”》
41. 《微信团队原创资源混淆工具：让你的APK立减1M》
42. 《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
43. 《Android版微信安装包“减肥”实战记录》
44. 《iOS版微信安装包“减肥”实战记录》
45. 《移动端IM实践：iOS版微信界面卡顿监测方案》
46. 《微信“红包照片”背后的技术难题》
47. 《移动端IM实践：iOS版微信小视频功能技术方案实录》
48. 《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
49. 《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
50. 《移动端IM实践：实现Android版微信的智能心跳机制》
51. 《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
52. 《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
53. 《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
54. 《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
55. 《腾讯技术分享：微信小程序音视频技术背后的故事》
56. 《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
57. 《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
58. 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
59. 《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
60. 《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
61. 《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
62. 《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
63. 《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
64. 《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
65. 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
66. 《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
67. 《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
68. 《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
69. 《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
70. 《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
71. 《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
72. 《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
73. 《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》
74. 《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》
75. 《微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等》
76. >> 更多同类文章 ……

[2] 微信背后的技术故事：

1. 《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
2. 《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
3. 《开发往事：深度讲述2010到2015，微信一路风雨的背后》
4. 《开发往事：微信千年不变的那张闪屏图片的由来》
5. 《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
6. 《一个微信实习生自述：我眼中的微信开发团队》
7. 《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
8. 《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
9. 《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
10. 《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
11. 《那些年微信开发过的鸡肋功能，及其带给我们的思考》
12. 《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
13. 《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》
14. 《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》
15. >> 更多同类文章 ……

[3] 阿里巴巴的技术分享：

1. 《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
2. 《现代IM系统中聊天消息的同步和存储方案探讨》
3. 《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
4. 《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
5. 《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
6. 《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》
7. 《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》
8. 《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》
9. 《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》
10. 《《阿里巴巴Android开发手册(规约)》背后的故事》
11. 《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》
12. 《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》
13. 《淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路》
14. 《难得干货，揭秘支付宝的2维码扫码技术优化实践之路》
15. 《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
16. 《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
17. 《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
18. 《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
19. 《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
20. 《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
21. 《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
22. 《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》
23. 《阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计》

（本文已同步发布于：http://www.52im.net/thread-4034-1-1.html）