MediaWiki网站简化模板，减小MySQL数据库
--James Qi 2010年2月26日 (五) 10:36 (CST)
前些天向邮编库网站中导入了170万条数据，这个数量是原超过以前最多的IP树的38万条数据的，导入的速度比IP树要快，大约用了5天的时间，而IP树我记得是用了一个多月的时间，这主要与页面的内容复杂程度有关，越复杂需要处理的时间越长。
170万条数据导入完成后，数据库从几百万条记录、2G大小变成了几千万条记录、15G大小，好在搜索引擎爬虫还没有开始光临，否则怕是MySQL服务器又吃不消。为什么170万条数据会出现6000多万条记录呢？用phpMyAdmin看了一下：
| 表 | 记录数 | 类型 | 整理 | 大小 |
|---|---|---|---|---|
| jinglearchive | ~12,056 | InnoDB | utf8_general_ci | 3.5 MB |
| jinglecategory | ~63,237 | InnoDB | utf8_general_ci | 8.2 MB |
| jinglecategorylinks | ~13,184,169 | InnoDB | utf8_general_ci | 3.6 GB |
| jinglechange_tag | ~0 | InnoDB | utf8_general_ci | 80.0 KB |
| jingleexternallinks | ~3,576,385 | InnoDB | utf8_general_ci | 3.2 GB |
| jinglefilearchive | ~0 | InnoDB | utf8_general_ci | 80.0 KB |
| jinglehitcounter | 0 | MEMORY | utf8_general_ci | 0 字节 |
| jingleimage | ~261 | InnoDB | utf8_general_ci | 128.0 KB |
| jingleimagelinks | ~1,801 | InnoDB | utf8_general_ci | 192.0 KB |
| jingleinterwiki | ~195 | InnoDB | utf8_general_ci | 64.0 KB |
| jingleipblocks | ~6 | InnoDB | utf8_general_ci | 96.0 KB |
| jinglejob | ~0 | InnoDB | utf8_general_ci | 32.0 KB |
| jinglelanglinks | ~3,514,817 | InnoDB | utf8_general_ci | 660.8 MB |
| jinglelogging | ~21,012 | InnoDB | utf8_general_ci | 7.6 MB |
| jinglemath | ~0 | InnoDB | utf8_general_ci | 16.0 KB |
| jingleobjectcache | ~208,446 | InnoDB | utf8_general_ci | 2.0 GB |
| jingleoldimage | ~8 | InnoDB | utf8_general_ci | 80.0 KB |
| jinglepage | ~1,756,126 | InnoDB | utf8_general_ci | 477.5 MB |
| jinglepagelinks | ~17,490,561 | InnoDB | utf8_general_ci | 1.2 GB |
| jinglepage_props | ~0 | InnoDB | utf8_general_ci | 16.0 KB |
| jinglepage_restrictions | ~164 | InnoDB | utf8_general_ci | 96.0 KB |
| jingleprotected_titles | ~0 | InnoDB | utf8_general_ci | 32.0 KB |
| jinglequerycache | ~0 | InnoDB | utf8_general_ci | 32.0 KB |
| jinglequerycachetwo | ~0 | InnoDB | utf8_general_ci | 64.0 KB |
| jinglequerycache_info | ~0 | InnoDB | utf8_general_ci | 16.0 KB |
| jinglerecentchanges | ~13,510 | InnoDB | utf8_general_ci | 6.2 MB |
| jingleredirect | ~225 | InnoDB | utf8_general_ci | 32.0 KB |
| jinglerevision | ~1,875,145 | InnoDB | utf8_general_ci | 440.0 MB |
| jinglesearchindex | 10,509 | MyISAM | utf8_general_ci | 3.2 MB |
| jinglesite_stats | ~1 | InnoDB | utf8_general_ci | 16.0 KB |
| jingletag_summary | ~0 | InnoDB | utf8_general_ci | 64.0 KB |
| jingletemplatelinks | ~21,169,521 | InnoDB | utf8_general_ci | 3.3 GB |
| jingletext | ~2,327,131 | InnoDB | utf8_general_ci | 446.8 MB |
| jingletrackbacks | ~0 | InnoDB | utf8_general_ci | 32.0 KB |
| jingletranscache | ~134 | InnoDB | utf8_general_ci | 1.5 MB |
| jingleupdatelog | ~2 | InnoDB | utf8_general_ci | 16.0 KB |
| jingleuser | ~3 | InnoDB | utf8_general_ci | 48.0 KB |
| jingleuser_groups | ~6 | InnoDB | utf8_general_ci | 32.0 KB |
| jingleuser_newtalk | ~2 | InnoDB | utf8_general_ci | 48.0 KB |
| jinglevalid_tag | ~0 | InnoDB | utf8_general_ci | 16.0 KB |
| jinglewatchlist | ~6 | InnoDB | utf8_general_ci | 32.0 KB |
| 41 个表 总计 | ~65,225,439 | MyISAM | latin1_swedish_ci | 15.2 GB |
可以看出categorylinks、externallinks、langlinks、templatelinks这几个表的数量都是170万的好多倍，再查看170万条数据调用的模板，正是这个模板内有过多的分类、外部链接、语言链接、嵌套模板引起的！于是对该模板进行了简化，首先是不再调用多层模板，将需要调用的内容全部集中在这一个模板中，然后尽量简化不必要的分类、外部链接和语言链接，文字、结构、图片上也优化，再保存新的模板，经过较长时间（又是运行runJobs.php几天）的更新，现在总计记录数下降了一半，在3000万条左右，数据库缩小到12G左右。应该还有简化、压缩的空间，以后再尝试。
以前在做MediaWiki网站的时候不太注意这个数据库大小的问题，为了分类全、链接多、修改方便采用了多级嵌套的模板，有用无用的分类都多加，内部、外部链接也尽量多加。这对于数据量小、浏览量小的网站（一般都是人工来添加、编辑内容的网站）来说问题不大，多浪费一点数据库空间、磁盘空间、服务器CPU/MEM资源、网络带宽也无所谓。而对于用importDump来批量导入大量数据的网站来说，如果不优化处理，就可能造成服务器资源不足的情况。
压缩MySQL数据库还有一个办法，就是启用Manual:$wgCompressRevisions功能，让MySQL中新保存的数据都用压缩方式，对于已经存在的老数据还可以用CompressOld.php来压缩处理。这应该也可以大幅缩小MySQL的磁盘空间占用，不过不能减少记录数，压缩、解压对CPU的消耗有点增加，这个功能我还没有实际用过。（补充：刚刚试了一下CompressOld.php，无论用默认的-t concat还是全部压缩的-t gzip，数据库的大小变化都很小，几乎看不出来效果。--James Qi 2010年2月26日 (五) 14:18 (CST)）
在当前服务器CPU越来越强大、内存越来越便宜、磁盘越来越大的情况下，一般的MediaWiki网站也不需要太多考虑，还是重点放在内容提供、功能实现上，只是在数据量特别大、浏览量特别大的情况下需要注意这些模板简化之类的问题。
| 标签：MediaWiki、网站、模板、MySQL、数据库。 |
相关内容：
|
