一个程序猿

最近发现玩游戏有点堕落，大量时间用在了游戏上，突然有一天，登陆服务器，发现好多命令居然手生了，又发现博客很久没有更新，又发现，几乎没有代码量了。

痛定思痛，本月剑三不再充值。待恢复学习后再考虑充值。

接此篇 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优化好，其实是个不错的产品。

很久没写点自己的小代码了，感觉手生。

刚配了一套轮组，升级一下上班车，放到办公桌上搞个造型。

最近一直在修改系统，并无太多原创的代码。其中修改了ucenterhome和discuz两套代码。

ucenterhome原来的队伍进行优化后，我又改进了分享功能。此功能虽然上线，功能也无大碍，但UE方面差强人意，主要是因为年前项目紧张，此项目投入人力并不多的原因。此功能修改，无详细的需求文档，也未进行详细的需求分析和业务逻辑设计，就匆匆开始了编码过程，结果就是：代码比较混乱，结构性比较差，升级和改进的潜力小。如果要改进，面临的结果就是重写。又因为uchome本身的设计结构，无论改写和重写成本都比较高。

因此，前期的规划是比较重要的，前期多想一点，后期就能节约更多的时间和精力。

这种做法马上应用到下一个项目中：discuz论坛的优化和功能改造。

前期对需求做了详细的分析，在中间不断的需求细化和明确，因此，功能和业务逻辑清晰，代码在修改的时候，保留了原来功能，只做了功能的分支。虽然前期的需求交流花费了较多的时间，但编码过程所花费的时间就很小了。

后者的流程才是以后要继续发扬的流程。

版权所有，欢迎转载

clean

用phpmyadmin写触发器的朋友，不知道有没有碰见这个问题：用pma导出的语句，死活倒不进去，mysqldump导出的，也不能用pma倒入。

反正问题多多，很令人头疼。

今天再次碰到这个问题后，偶然发现个问题，就是sql输入框下的一个小的内容：语句定界符。

平时导出sql，语句定界符默认是分号，而编辑触发器的时候，是两个斜杠//。

蹊跷就在这里，导入的时候使用的定界符必须跟倒出时候的定界符保持一致，否则就会出现错误。

问题发现后，老王是相当的高兴啊。

discuz论坛在国内非常流行，用户众多。优秀的用户体验和超强的负载，也赢得了众多的好评。

但discuz毕竟是为中小型网站设计，很容易达到性能的瓶颈。在最近对discuz的改造和表结构的分析，做了以下的探讨，来提升论坛的性能。

第一步，当然就是分表。
技术实力不太强的用户（严重依赖mysql的用户），分表是最直接的做法（当然，有些功能会损失）。

分析一个运营两年的discuz数据库，库表大概是十几个G左右，posts数据表已经几个千万。

首先可以拆分的，就是post表了。根据情况，post表可以分10张，百张，规则可以哈希，也可以阶段自增（分表主键使用tid（帖子id））。分完表，可以看到一排post_**的表，每个表的数据量降到百万以下，速度就无太大影响。

第二个可以拆分的，是threads表，此表分表，可以水平分割方式水平的分割，可以根据论坛版块id进行分表，这样可以使每个表的数据量减小，但这样也损失了一个功能：全站标题检索。

通过以上两个表的改造论坛的承载能力能迅速见长。

底下会讨论高级优化改造得方法，且听下次分解。