MySQL優化 之 Discuz論壇優化

discuz是很不錯的論壇，大站用他的話還得有針對性的優化下mysql，轉載開始。

，轉載請注明作/譯者和出處，并且不能用于商業用途，違者必究。

一. 前言

近日由于需要,對discuz論壇(簡稱dz)進行優化,當然了,隻是涉及到資料庫的優化.

先說一下伺服器及dz的資料量,2 * Intel(R) Xeon(TM) CPU 2.40GHz, 4GB mem, SCISC硬碟.

MySQL 版本為 4.0.23. 資料表情況:

cdb_attachments 2萬

cdb_members 10萬

cdb_posts 68萬

cdb_threads 7萬

二. 緩存優化

在 my.cnf 中添加/修改以下選項:

以上參數根據各自伺服器的配置差異進行調整,僅作為參考.

三. 索引優化

上面提到了,已經開啟了慢查詢,那麼接下來就要對慢查詢進行逐個優化了.

1. 搜尋優化

搜尋的查詢SQL大緻如下:

用 EXPLAIN 分析的結果如下:

隻用到了 <code>t.fid</code>

和 <code>p.tid</code>

,而 <code>p.author</code>

則沒有索引可用,總共需要掃描

<code>66160*10 = 661600</code>

次索引,夠誇張吧 :(

再分析 <code>cdb_threads</code>

和 <code>cdb_posts</code>

的索引情況:

以及

看到索引 <code>fid</code>

和 <code>enablehot</code>

基數太小,看來該索引完全沒必要,不過,對于fid基數較大的情況,則可能需要保留&gt;該索引.

所做修改如下:

在這裡, <code>p.author</code>

字段我設定的部分索引長度是 10, 是我經過分析後得出來的結果,不同的系統,這裡的長度也不同,最好自己先取一下平均值,然後再适當調整.

現在,再來執行一次上面的慢查詢,發現時間已經從 6s 變成 0.19s,提高了 30 倍.

這次先到這裡,下次繼續 ^_^

。

寫的時候是2006年，沒想到過了這麼久，discuz論壇的問題還是困擾着很多網友，其實從各論壇裡看到的問題總結出來，很關鍵的一點都是因為沒有将數

據表引擎轉成InnoDB導緻的，discuz在并發稍微高一點的環境下就表現的非常糟糕，産生大量的鎖等待，這時候如果把資料表引擎改成InnoDB的

話，我相信會好很多。這次就寫個掃盲貼吧。

1. 啟用innodb引擎，并配置相關參數

2. 修改表引擎為innodb

其他表類似上面，把表名換一下即可…

将表存儲引擎改成innodb後，不僅可以避免大量的鎖等待，還可以提升查詢的效率，因為innodb會把data和index都放在buffer pool中，效率更高。