Discuz论坛优化之MySQL优化

2012年09月23日 Linux服务器 评论 10 条 阅读 13,146 views 次

今日帮朋友优化号称日均500PV,100UV的论坛,后台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数据库默认引擎修改为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. 将所有数据表引擎修改为InnoDB;
2. 给DB配备的内存稍微大一些,起码也要8GB;

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

转自:http://imysql.com/2012/09/22/mysql-optimize-around-discuz.html

10 条留言  访客:7 条  博主:3 条

  1. 数据库水太深了要学习了东西还有很多。

  2. 日均500PV,100UV的论坛
    这里是写错了 还是怎么的

  3. 数据库还是有点难懂,对于我这样一个人做网络方向的来说,确实有点搞不清楚。向你多多学习数据库知识。

  4. 雨飞兄,加个友链吧,你的我已经加好了。

  5. 博主 流量些错了

给我留言

Copyright © 羽飞博客 保留所有权利.   Ality主题 皖ICP备14013844号-1

用户登录