MySQL优化 之 Discuz论坛MySQL通用优化

之前分别在2006和2009年写过两篇关于discuz优化的文章:MySQL优化 之 Discuz论坛优化MySQL优化 之 Discuz论坛优化 -- 续,没想到都6年过去了,discuz还在坚挺的使用MyISAM引擎,堪比罚改委...
今日帮朋友优化号称日均数百万PV,数百万UV的论坛,后台DB采用R710(16G Ram,PERC 6/i 256MB BBU,4块 15K RPM SAS盘做raid 1+0,ext3文件系统,E5620 * 2),这个配置看似也不错了,不过压力仍然较大,大量的请求处于:sending data和statistics状态。
经过分析,确认瓶颈主要在:

1. IO读,IO写倒还好,不算高;因为数据表都是MyISAM,需要产生较高的物理读,不能通过内存有效缓冲;
2. 使用的MySQL是官方5.1版本,InnoDB队列请求排队较严重(部分表已经先转成InnoDB了);
3. 部分未转换成InnoDB的表MyISAM表级锁比较严重;

综上,建议做以下改进工作:

1. 参考上一篇博文:[MySQL FAQ]系列 -- 新手必看:一步到位之InnoDB,将MySQL数据库默认引擎修改为InnoDB;
2. 除转换所有数据表引擎为InnoDB(除了 forum_postposition 和 common_session 两个表,后面再说原因);
3. 原则上,所有表都应创建一个自增ID列作为主键,该列可和业务完全无关,避免频繁更新导致重新排序。

下面来说说 forum_postposition 和 common_session 表的改造方案。

1. 先说下 forum_postposition 表。
该表用来存储论坛帖子的排序(帖子排楼顺序),存储内容类似:(1 1), (1 2), (2 1), (2 2), (2 3)。
官方号称因为这种特殊的业务原因,不变修改成InnoDB表,其实可以尝试用下面的方案:
(1 1 1), (2 1 2), (3 2 1), (4 2 2), (5 2 3)。
和之前的区别在于新增了一列自增ID做主键,该主键和业务完全没有任何关系,仅用做自增主键。
原表则采用 (tid, position) 两个字段联合做自增主键,在高并发情况下,效率自然不高。

2. 再来说说 common_session 表。
该表顾名思义,用于存储账号登陆session,和 forum_post 类似,都属于高并发请求表。
该表未定义自增ID列主键,仅用一个 CHAR(6) 类型的 sid 做唯一索引。转成InnoDB后,在高并发的情况下,该表的效率会非常低。
因此在转换之前,应先确认如果新增一个自增ID列主键,是否会影响论坛正常逻辑。

总结一下:
对于discuz官方及二次开发者,建议:

1. 所有数据表均转换成InnoDB引擎,并针对InnoDB特点做相应设计上的优化;
2. 所有数据表均应创建自增ID列做为主键,如果没有的话;
3. 类似 common_session 表,可考虑采用 NOSQL 存储,当然了,如果为了实现DB高可用,还是继续放在MySQL中;
4. 开发翻页限制功能,防止搜索引擎抓取 N 多页帖子列表,这个功能会导致数据库的物理读较大。

对于discuz普通用户,建议:

1. 参考我的博文:[MySQL FAQ]系列 -- 新手必看:一步到位之InnoDB,将所有数据表引擎修改为InnoDB;
2. 给DB配备的内存稍微大一些,起码也要8GB;
3. 使用xfs文件系统,会比默认的ext3甚至ext4好很多,详细查看:XFS设计 -- 转载;
4. 不是cron任务,定期删除session表中过期记录,保持该表足够"瘦身";
5. 有问题可以来本站留言交流,或者在新浪微博(@金荣叶)上给我留言。

最后,也许有朋友问,你怎么这么热衷优化discuz,是不是在做这方面的第三方服务?其实不然,只是因为discuz内部不少人都和我的大学有着较深渊源,另外discuz在国内的普及范围也相当广,觉得有必要帮助大家做些优化,仅此而已 :)

技术相关:

评论

日均500PV,100UV的论坛。是少打个W字吧?不然这样也用innodb?还谈优化?

哈哈,是啊,少了个万字,已经修改,多谢。

金荣,关于这个session表,我们给关闭了,官方建议20000用户以上就关闭该功能了。
而关于pre_forum_threaddisablepos这个表,本身官方做的是一个memory表,其中只有一个主键tid字段(主题ID),这个表我认为放在内存中也是不合理的,不知官方为什么这么做哈。

下面说说我的顾虑:关于将forum_postposition增加一个自增ID做主键,从而将该表转换为innodb的方法太高明了,但这样做需要修改程序了,因为表中本来自带了一个自增ID,而且是联合主键的第二个字段,不知道您这里这么做,是否也是修改了程序来实现原本的那个自增ID的作用呢?

关于pre_forum_threaddisablepos这个内存表,金荣大神是怎么优化的呢?我的意思是放在内存中不合理了,这是个只有一个tid字段的内存表。
另外,forum_postposition 增加一个自增ID,那么程序就要去实现表中原来带的那个自增ID的功能了。您是否为了这个功能修改了discuz的代码呢?

抱歉,细节还没进行优化,这只是通用的,这个表是干嘛用的?