条目没多少，数据库却越发地大了起来。两千条都不到的条目数量，数据库却膨胀到了265M。上一次手动备份的时候好像才50M左右，这才没隔多久。
MediaWiki数据库之所以大，是因为它保留了所有编辑的记录，即便是一个条目，你编辑修改个上千回同样会导致数据库容量增加（当然你的条目只有寥寥数语的话恐怕不会很明显），就像你把编辑一次文件就保存一个副本。另外，即便是你删除了某些条目或模板，但事实上它并未从数据库中消失，为的是你哪一天心血来潮又想恢复或者是其他人想让它恢复。其实这一点就更好理解了，就像文件放进回收站，磁盘空间并不会真正的释放出来。
还有就是，在MediaWiki中，默认是以未压缩的方式将文本保存到数据库中的，如果启用压缩那么体积也将大大缩小。
既然明白了这几点，那么要做的无非就是针对上述情况逐一进行处理。
首先来说说压缩的事，这一点在官方文档中有提到，我们可以通过在配置文件LocalSettings.php中启用[$wgCompressRevisions][1]的方式。不过副作用也很大，很多扩展将无法处理压缩后的文本，比如Replace Text扩展。
需要注意的是，$wgCompressRevisions的方式是需要PHP提供并启用了 zlib的支持。
当然这种“一劳永逸”的方法还是可以用手动方式来尽可能减少其副作用的。那就是使用维护脚本中的[compressOld.php][3]，它只会压缩老版本的内容而不会像$wgCompressRevisions那样一刀切。
使用方法很简单，在控制台中运行以下代码：

cd /path/to/wiki/maintenance/storage
php compressOld.php

该方法就算是你使用了$wgCompressRevisions进行基本压缩，还是可以应用“concat”或“diff”压缩模式来进一步压缩。
当然，官方还是提醒使用者，这些高级压缩模式可能与某些尝试直接读取或写入文本到数据库的非官方扩展不兼容，所以使用时还请务必小心。所以备份数据库非常重要！
与上述类似，但更加极端的方式就是通过将不需要的数据彻底删除，可以使用[deleteArchivedRevisions.php][4]脚本，具体如下：

php maintenance/deleteArchivedRevisions.php --delete 
Delete archived revisions
 
Deleting archived revisions... done. 45560 revisions deleted.
Searching for active text records in revisions table...done.
Searching for active text records in archive table...done.
Searching for inactive text records...done.
45560 inactive items found.
Deleting...done.

更详细的介绍可以参考本站文章《MediaWiki 日常维护——彻底删除旧文件（页面）或已删除文件（页面）》。
另外，官方提供了另外几项，包括压缩数据库行和截断对象缓存表。前者在数据库服务器上使用InnoDB行压缩(row FORMAT=COMPRESSED;)，可以透明地减少所有表的大小，而不会破坏数据，也不会影响依赖于明文数据库的扩展，唯一的缺点可能就是会对服务器的性能开销有影响。至于后者就更加专业，所以就暂时不考虑。

参考资料

https://www.mediawiki.org/wiki/Manual:Reduce_size_of_the_database