最佳化系列 | Discuz論壇MySQL通用最佳化

標籤：mysql最佳化   discuz   innodb   

之前分別在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營運開發課程，是業內最有良心、最有品質的培訓課程。

本文出自 “老葉茶館” 部落格，請務必保留此出處http://imysql.blog.51cto.com/1540006/1879744

最佳化系列 | Discuz論壇MySQL通用最佳化