寫在前面：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的代價會非常高。如果該熱帖被大量的訪問歷史回復，或者被搜素引擎一直反復請求并且歷史回復頁時，很容易把數據庫服務器直接壓垮。
新聞熱點
疑難解答
