在一条流水线被长期接入之后，经常会出现一类问题，就是SonarQube里面的历史分析记录，该怎么样去清理一下，还有它的数据库体积，要是变得太大了，又该怎么去处理，项目每天都在那跑扫描、分支被反反复复地创建、版本号也在不停地变化，这么一来，数据库就会慢慢地变大，SonarQube它自己，其实是有一套后台维护机制的，它会在新的分析被执行完了以后，去清理掉一部分旧的数据、旧的历史快照、PR的分析，还有分支的记录，靠着这个，来减缓数据库的膨胀，官方的文档里也说明了，那些旧的分析，是不会被完完整整地一直保留着的，不然的话，数据库就会变得臃肿不堪。

　　一、怎么清理历史分析记录

　　想要去清理SonarQube的历史分析记录，是不能直接进到数据库里面，去动手删表的，那个正确的做法是，先用页面上的功能，去把那些异常的快照给删掉，然后再通过后台维护机制，去控制好数据保留的策略，到了必要的时候，再去把那些长时间没人管的项目、分支，还有PR的记录，给清理掉。

　　1、把那些跑错了的分析快照给删掉

　　进到项目的页面里面，去把活动记录给打开，在左边那一列，历史的分析列表里面，去找到你想要删掉的那一条分析记录，然后去点一下那条记录前面的，那个带着三个点的小菜单，在里面，去选上删除分析的选项，按照官方文档的说明，去删掉一个项目的快照，是需要有这个项目的管理权限的，而且，最近的那一次分析，是不能被删掉的；那些被标记了要删除的快照，会等到下一次，再对这个项目做分析的时候，才会被真正地清理掉。

　　2、去调整一下后台维护的策略

　　进到系统管理的通用设置里面，去找到后台维护那一项，看一看历史快照的保留规则，都是怎么写的，默认的那套规则，是会按照不同的时间粒度，去保留快照的，就比如说，一天以前的那种，是每天都给留一条；一个月以前的，是每个礼拜给留一条；一年以前的呢，是每个月给留一条，另外，它还会去清理掉一部分旧的PR、旧的分支，还有那些已经被关掉了的问题，要是你项目扫描的频率很高，那是可以适当地去把保留的周期给缩短一些的，但是，在做这个之前，要先跟质量的负责人去确认一下，看看这么做，会不会影响到后面做趋势的分析。

　　3、去把那些已经废弃了的项目，还有分支给清理掉

　　那些长时间都没有人去管的测试项目、临时建起来的项目，还有已经下线了的分支，它们会一直占着数据库的空间不放，这个时候，可以进到项目管理的那个页面里面，去按照项目的负责人、上次分析的时间、还有分支的状态，来做一轮盘点，等确认了这些东西，是真的不再需要了以后，再通过SonarQube的页面去把它给删掉，可千万不要绕开应用本身，去直接操作数据库。

　　二、数据库体积过大了要怎么处理

　　当发现数据库变得过大的时候，要先分清楚，这到底是正常的业务增长，还是因为配置搞得不对，才导致了后台的维护机制失效了，要是只去做数据库的压缩，却不去管扫描的策略，那等过了一段时间以后，它还是会接着膨胀起来的。

　　1、去检查一下，版本号是不是在频繁地变动

　　有不少的团队，喜欢把构建的编号，给写进项目的版本号里面去，就比如，一天换一个流水线的号码，官方的文档里面，是特别提醒过的，不要拿构建的编号，去当项目的版本号来用，因为这么干了以后，那些带着版本事件标记的分析快照，就会躲开后台维护机制的清理，结果，就给数据库增加了很多不必要的负担，项目的版本号，它应该是对应着真正的发布版本才对，而不应该是每一次构建，都跟着变一次。

　　2、去检查一下，扫描的范围是不是开得太宽了

　　要是你把构建出来的产物、项目依赖的目录、压缩包、前端打包完的文件夹，还有自动生成出来的代码，全都给一股脑儿地圈进了扫描的范围里，那数据库自然就会变得很大，碰到这种情况，就应该去检查一下源码目录的设置、排除文件的规则、测试代码的目录，还有覆盖率报告的路径，要确保只把那些，真正需要拿来做质量分析的源码，给留在里面，等到扫描的范围被收窄了以后，后面再分析出来的数据，就会干净很多了。

　　3、去检查一下，分支和PR是不是被积压住了

　　在那种多分支一起开发的环境里头，短期的特性分支，还有PR的分析，是会留下很多很多记录的，这个时候，可以配合着后台维护的规则，去把那些已经过期的分支给清理掉，或者，也可以在研发的流程里面，去约定好，一旦分支被关闭了，就要及时地去把远端的那个分支，还有它在SonarQube里面对应的记录，都给删掉，这么做，就能避免那些老旧的分支，长期地挂在系统里面了。

　　三、在做清理的前后，有什么是需要留意的

　　给SonarQube做清理，这件事是会影响到历史的趋势、问题的追溯，还有审计的那些记录的，所以，不能一看到数据库大了，就马上动手去直接操作，特别是在生产环境里面，更是要先做好备份，然后再去分批次地处理。

　　1、要先去做一次数据库的备份

　　在动手去清理历史记录、删除项目，或者是调整后台维护策略之前，是要先给数据库做一次备份的，并且，还要把当前SonarQube的版本号、插件的版本，还有数据库自己的版本，都给记录下来，这样，等清理完了以后，要是发现趋势的数据，或者是项目的记录，不小心被误删掉了，那至少，还能有个回退的依据在手里。

　　2、不要用手工的方式，去直接删数据库里面的表

　　SonarQube里面数据与数据之间的关系，是比较复杂的，要是你直接去删掉了表里的记录，那是有可能会造成页面上出现异常、索引变得不一致，或者是往后在做系统升级的时候，失败的，就算是你要去清理那种体积很大的表，也应该优先去使用页面上的功能、API，或者是官方支持的那种维护方式。

　　3、等清理完了以后，要去观察一下空间的变化

　　当你把快照或者是项目给删掉了以后，应用层看到的数据是变少了，可这并不代表，数据库的文件，它也会立马就跟着变小，像PostgreSQL、Oracle、SQL Server这些数据库，它们还得按照各自的运行机制，去回收那些被释放出来的空间，在清理全都做完了以后，要去观察一下数据库的容量、索引的大小、跑一次分析要花多长时间，还有页面上响应的速度，而不是只去关心，刚刚那一次删除的动作，到底做完了没有。

　　总结

　　关于SonarQube的历史分析记录要怎么去清理，还有数据库的体积变得太大了又要怎么去处理，这里面比较关键的地方，就是先要靠着活动记录里的功能，去把那些异常的分析给删掉，然后再通过后台维护机制，去把历史数据的保留策略给控制好，在这同时，还要去把那些废弃的项目、分支，还有PR的记录，给一并清理掉，当数据库变得过大的时候，要重点去查一查，项目的版本号是不是被构建号给污染了、扫描的范围是不是开得太宽了，还有分支的记录，是不是全都在那积压着，所有跟清理有关的动作，在做之前，都要先去备份一下，而且，要尽可能地，去通过SonarQube它自己的功能来处理，不要去直接改动数据库的表。