写在前面：discuz!作为首屈一指的社区系统，为广大站长提供了一站式网站解决方案，而且是开源的（虽然部分代码是加密的），它为这个垂直领域的行业发展作出了巨大贡献。尽管如此，discuz!系统源码中，还是或多或少有些坑。其中最著名的就是默认采用MyISAM引擎，以及基于MyISAM引擎的抢楼功能，session表采用memory引擎等，可以参考后面几篇历史文章。本次我们要说说discuz!在应对热们帖子翻页逻辑功能中的另一个问题。
在我们的环境中，使用的是 MySQL-5.6.6 版本。
在查看帖子并翻页过程中，会产生类似下面这样的SQL：
| mysql> desc SELECT * FROM pre_forum_post WHERE tid=8201301 AND `invisible` IN('0','-2') ORDER BY dateline DESC LIMIT 15/G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: pre_forum_post type: ref possible_keys: tid,displayorder,first key: displayorder key_len: 3 ref: const rows: 593371 Extra: Using index condition; Using where; Using filesort |
这个SQL执行的代价是：
-- 根据索引访问行记录次数，总体而言算是比较好的状态
| | Handler_read_key | 16 | |
-- 根据索引顺序访问下一行记录的次数，通常是因为根据索引的范围扫描，或者全索引扫描，总体而言也算是比较好的状态
| | Handler_read_next | 329881 | |
-- 按照一定顺序读取行记录的总次数。如果需要对结果进行排序，该值通常会比较大。当发生全表扫描或者多表join无法使用索引时，该值也会比较大
| | Handler_read_rnd | 15 | |
而当遇到热帖需要往后翻很多页时，例如：
| mysql> desc SELECT * FROM pre_forum_post WHERE tid=8201301 AND `invisible` IN('0','-2') ORDER BY dateline LIMIT 129860, 15/G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: pre_forum_post type: ref possible_keys: displayorder key: displayorder key_len: 3 ref: const rows: 593371 Extra: Using where; Using filesort |
这个SQL执行的代价则变成了（可以看到Handler_read_key、Handler_read_rnd大了很多）：
| Handler_read_key | 129876 | -- 因为前面需要跳过很多行记录
| Handler_read_next | 329881 | -- 同上
| Handler_read_rnd | 129875 | -- 因为需要先对很大一个结果集进行排序
可见，遇到热帖时，这个SQL的代价会非常高。如果该热帖被大量的访问历史回复，或者被搜素引擎一直反复请求并且历史回复页时，很容易把数据库服务器直接压垮。
新闻热点
疑难解答
