之前分别在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在国内的普及范围也相当广，觉得有必要帮助大家做些优化，仅此而已 :)
--------------------------------------分割线--------------------------------------
知数堂 （http://zhishuedu.com）培训是由资深MySQL专家叶金荣、吴炳锡联合推出的专业优质培训品牌，主要有MySQL DBA实战优化和Python运维开发课程，是业内最有良心、最有品质的培训课程。