win7有多少慢-(win7很慢)

最初的本地IM数据库设计遵循简单易用、管理方便的原则，将用户收到的所有信息统一存储在当前客户端的本地同一SQLite数据文件中。

(作者注：微信不会保存聊天记录，聊天内容只存储在用户手机、电脑等终端设备上。)

由于早期本地数据库设计方案的不足，随着微信的广泛使用和消息的积累，许多技术问题逐渐暴露出来。

随着使用时间的推移，当数据量越来越大时，数据量逐渐增加：

从文件系统的角度来看，数据库文件逐页增长。因为长期使用微信会逐渐积累消息量，增加数据库体积，导致更严重的碎片化，进一步影响机械硬盘下的读写效率。

对用户最直观的影响是切换聊天变得非常卡住，尤其是对于重度用户，甚至点击聊天就卡住了。

随着时间的推移，消息量的逐渐积累，数据库存储文件的体积也越来越大，显著占用了用户存储空间。

意外损坏磁盘文件也可能导致数据丢失。

因为所有的消息都放在数据库文件中，就像把所有的鸡蛋放在篮子里一样。

数据库文件也可能会因文件也可能意外断电，计算机sqlite自身bug数据库文件损坏等原因。如果损坏，用户可能会丢失消息数据。即使有DB所有历史记录都不能保证恢复机制。

当这种情况发生时，它会对用户产生很大的影响，因为聊天记录可能会消失！

PS：微信移动终端也有类似的麻烦。如果您感兴趣，可以阅读微信客户端SQLite数据库损坏修复实践。

由于新闻数据的不断增加，上述数据库存储文件变大，查询变慢。

但是新闻数量的增长是不可避免的，那么有没有办法控制增长速度和数据库的大小呢？

我们从消息情况和日常使用场景两个方向进行分析

微信里的IM新闻可分为三类：

根据消息的重要性：

根据消息的大小：

众所周知，我们每天使用微信收发消息或浏览最新消息。我们通常很少主动浏览更早的消息。

新闻越早，浏览的概率就越低。

所以：在大多数情况下，我们应该让最常见的新闻不受旧数据的影响。

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

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

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

基于以上分析，首先将微信官方账号新闻划分出来，存储在单独的数据库中，与用户的普通信息隔离，也可以大大降低普通信息数据库的体积。

基于对日常使用场景的分析，大多数旧数据读取频率较低，因此应提高最近的读写效率。

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

除了时间维度外，我们还考虑了空间维度的划分：如果半年内普通模在半年内超过阈值，我们还将建立一个新的数据库来存储，这样每个数据库的大小和数据规模就不会太大，这可以提高新闻的读写效率。