之前生产环境有一个数据库需要做每日备份，当时 dump 了一下整个库，才八十多兆，觉得不需要做增量备份，全量备份也不会占用太多空间，半年下来也积攒了十几G了，整理备份数据看上去也快要排上日程，我们就拿这些数据试一下，看 7zip 能帮我们省下多少空间
生产环境下有一个定时任务，每天的固定时间会对数据库做 dump，这个 dump 文件大概八十多兆，半年下来，单个文件没怎么增长，但是总量也差不多十几G了，那么我们可以推断，dump 文件的主要内容应该是差不多的，只是每天会有些增长，那么这种情况下，7zip 会不会给我们带来惊喜呢
如果我们使用默认的配置，即使选择极限压缩，压缩后依然会有五六G，但是很明显这不是极限，因为我们以增量备份的思路来考察数据的话，所有数据的大小应该会在 100M 左右。我们知道 7zip 是基于字典来压缩文件的内容，所谓字典我可能不能给出一个完全正确的定义，但是我觉得可以完全从字面理解，比如我们假设 td1 为字典中的词汇，其代表的意思就是 tricks.one，那么如果 7zip 在文件中发现 tricks.one 字样，就可以用 td1 来取代，从而缩短了内容长度。
于是我们也可以推断，「压缩后依然会有五六G」是因为字典已达到设定大小无法再加入新的词汇，所以只能采用常规压缩。所以我们可以通过增大字典大小和单词长度来试探 7zip 的极限。顺带一提的是，如果增大字典会大幅增加内存的消耗量，如果没有充足的内存，一个折中的办法是减少同时运行的线程数，不过这样会延长很多执行时间，熊掌与鱼不可兼得，不过因为我们这次只考虑空间问题，如果内存不够就降低线程数，然后出去喝个茶等待结果吧。
我其实也没料到最终的压缩结果，自己都不能完全相信，十几G的文件压缩后只剩下四十几M，而且虽然压缩时间很长，但是解压缩依然还是很快，这样看来一年的全量备份完全保存下来也不会超过 100M，看来似乎完全不用考虑切换到增量备份的问题了。
对于压缩参数的经验我也有一些分享给大家，我第一次设字典大小 512M，压缩后大小就是四十几M了，改成 384M 后，还是四十几M，推测 512M 的字典没有用满，256M 压缩过程中就已经超出大小了，所以没有继续，因此看来只要内存够大，字典是越大越好的，如果综合考虑的话，我们可能应该先推测不同数据的大小，然后把这个数字乘四当成字典试一下，至于单词长度，这个参数似乎影响不大。