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表中过期记录，保持该表足够"瘦身"；