大话discuz性能优化
11-27
接此篇 http://www.sunboyu.cn/2009/11/05/discuz%E8%AE%BA%E5%9D%9B%E4%BC%98%E5%8C%96.shtml
最近一直在修改discuz，看到了很多问题，在跟系统工程部门合作的时候，也看到了很多比较优秀的解决方案，可以引入到系统中。
底下粗略讲述下已经做过的优化和可以着手进行的优化。
对于一个数据量比较大的论坛，首先是分表。posts表，threads表是必须要分的。可以按照forum表的fid进行分，也可以使用tid进行hash散列分布。分表带来的问题，显然是分页。我们进行排序的时候不可能去进行union查询，否则就失去了分表的意义。在这里，我们使用了一个支持排序的key-value型存储的小型数据库-Tokyo Tyrant（http://1978th.net/tokyotyrant/），用此数据库去同步threads表和posts表的数据，达到高速分页。（附：典型应用可以参见此文章 http://blog.s135.com/tcsql/ ）
随着数据表的膨胀，很多join联查必须进行拆分。分表可能强制我们去拆分联查，另外一些很变动不大的表，比如用户信息表的数据，使用率明显很高，变动不会太大，而使用key-value存储再合适不过。这时候，bdb和memcached是首选，我推荐使用bdb，可以持久存储于硬盘上，由用户更新资料触发更新，不必考虑过期和服务器重启的问题。这样可以减少太多的join联查，而节约数据库服务器的缓存。
随着静态文件的增长和访问量的增长，带宽浪费是一个值得考虑的问题。我们打开discuz的首页，静态文件要比php文件多好几倍，而每个文件都夹带了长长的cookie信息，因此，把这些cookie去掉显然会节约大量的带宽。discuz的文件结构还是很不错的，通常通过一个参数的配置或者全文替换就能完成这项工作。此应用，可以在新浪所有的图片上有所体现。
全文检索是mysql所不擅长的，因此附加一个好的全文检索方案很必须，我熟悉的方案：Lucene，sphinx，whoosh是我喜欢的几个全文检索的工具，对于discuz的负载，我感觉任何一个都能满足应用。在此方案上，设计一个完美的同步触发机制很重要。
还有很多问题，都在待发现中，部分问题已经解决，部分问题可以优化。discuz优化好，其实是个不错的产品。
