Typecho博客数据库真实占用大揭秘：我的站点跑了3年后数据长这样

52JinY 助手

最近整理了一下自己几个Typecho站点的数据库使用情况，顺便把一些心得分享出来，希望对同样在跑小博客的朋友有点参考价值。

先说一下我的基本情况。我有三个Typecho站点，分别运行了大约两年、四年和快六年。文章数量差异挺大，最少的那个只有一百多篇，最多的积累了将近八百篇。评论方面参差不齐，有的站开了Akismet，垃圾评论拦截得比较干净，有的早期没装插件，数据库里留了一堆垃圾数据。

从实际数据来看，Typecho本身的数据库占用真的非常轻量，这一点一直让我很满意。运行两年、文章一百多篇的那个站，数据库文件才不到3MB，完全在我意料之内。跑了四年的那个中等规模站，数据库大概在12MB左右，平时备份起来轻松得很。但跑了六年的老站就有点意思了，数据库文件膨胀到将近80MB，起初我以为是文章多导致的，后来仔细一查，发现根本原因是typecho_log表和未清理的垃圾评论。

那个老站早期用过一款统计类插件，它会把每次访问记录写进数据库的日志表里，几年下来日志记录条数突破了百万，这部分数据占了整个数据库体积的大头。后来我直接TRUNCATE了那张表，数据库体积立刻降回到不到15MB，瘦身效果相当明显。这个经历让我意识到，Typecho本身的表结构其实相当精简，撑大数据库的往往是插件留下的"副产品"。

垃圾评论的问题也值得单独说一下。那个没装防垃圾插件的站，typecho_comments表里躺着将近两万条状态为spam的记录，清掉之后数据库直接减小了好几MB。Typecho后台的评论管理页面虽然可以批量删除，但如果数量特别大，建议直接在数据库层面操作，用SQL语句DELETE WHERE status='spam'，速度会快很多，不然前台页面容易超时。

另外聊一下表结构本身。Typecho默认的表就那么几张：contents、comments、users、metas、relationships、options、fields，加上可能存在的log表。核心内容都集中在contents和comments里，其余几张表的数据量本来就很小。我见过有人问"Typecho数据库会不会越来越卡"，其实以正常博客的体量来说，几百甚至上千篇文章、数千条评论，对MySQL或者MariaDB来说根本不算什么压力，索引跑得很顺，查询速度完全感受不到瓶颈。

备份频率这个话题也顺带讲一讲。因为Typecho数据库普遍轻量，我现在都是设置每天自动备份一次，压缩后的SQL文件通常也就几MB，存在对象存储上几乎不花什么钱。相比WordPress动辄几十上百MB的数据库，Typecho在这方面的优势还是挺明显的，尤其对预算有限的个人站长来说很友好。

总结一下我的体会：Typecho数据库本身非常克制，真正需要注意的是定期清理垃圾评论、审查插件是否有疯狂写库的行为，以及定期做一次OPTIMIZE TABLE来整理碎片。只要养成这几个习惯，数据库的健康状况基本不用太操心。有类似经历或者数据的朋友也欢迎贴出来对比一下，看看不同规模站点之间的差异。