(转)MySQL优化 之 Discuz论坛MySQL通用优化

http://www.imysql.cn/2012/09/22/mysql-optimize-around-discuz.html

  这里提到了关于discuz 中myql优化值得注意的几点,归纳如下:
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表中过期记录,保持该表足够"瘦身";

你可能感兴趣的:((转)MySQL优化 之 Discuz论坛MySQL通用优化)