Discuz X 系統：【效率機制】-【功能最佳化】 詳解

member 表最佳化

當一個資料表的資料量越來越大時，關於這個表的查詢和更新操作就會變數越來越慢，為了提高資料庫表的響應速度，應該時刻保持表資料的精簡。那麼如何既不影響正常功能又能保證表資料的精簡？我們在十幾個註冊會員數從幾十萬到幾百萬不等的網站進行了一項非活躍使用者數的統計，統計結果如下圖：

統計結果顯示非活躍使用者數和活躍使用者數的比例趨近於 82 規則，即非活躍使用者數佔大部分，因此只要我們將非活躍使用者進行存檔即可大大減少使用者表的資料量，提高訪問速度。

存檔的標準是：

90 天之內無訪問且帖子數小於 5，估算可最佳化 60% 以上使用者。

程式處理過程：

a 、使用者在回訪時將資料從存檔表中轉移到主表

b 、單使用者預設均不相容處理

加為好友、打招呼、發簡訊將提示使用者不存在或被凍結

使用者空間、檢視使用者資料頁可正常顯示

c 、多使用者操作預設相容處理

好友列表，帖子檢視頁可正常顯示

d 、後臺使用者管理時需要選表操作

post 表的最佳化

在站點運營過程中，常遇到高樓貼的效能問題，比如 limit 187460, 20 。為瞭解決高樓貼可能出現的問題，Discuz! X2.5 做了如下調整：

1 、增加 position 欄位記錄樓層，修改主鍵為：PRIMARY KEY (tid, `position`) 聯合主鍵，其中 position 為 auto_increment 。

2 、 pid 欄位保留，仍然是 auto_increment（單獨的一個表），保持唯一，其值在一個單獨的表中記錄， 保留此欄位的主要目的是可以讓原程式的基本不用做修改。

使用方法：

SELECT * FROM pre_forum_post WHERE tid=424 AND position>=$start AND position<$end ORDER BY position;

3 、搶樓貼和普通的蓋樓貼機制統一。

4 、刪除和稽核保留原來的機制，頁面顯示此樓層被刪除或稽核中。

點選數最佳化

在一個站點中，主題瀏覽量、文章檢視數等資料即時更新時，需要頻繁的寫表操作，從而導致鎖表問題。為瞭解決這一問題，Discuz! X2.5 做了如下調整：

1 、增加 forum_threadaddviews 表，記錄每一個 TID 的增量點選數。

2 、檢視帖子時，如果增量點選數到 100，則使用程式鎖將資料更新到 thread 表並更新增量點選數為 0 。

3 、回貼時將增量點選數和回覆數一起更新到 thread 表，並更新增量點選數為 0 。

4 、執行計劃任務：每天 3 點，5 分鐘一次，一次取 500 條資料更新到 thread 表， 並刪除此 500 條資料，以減少 forum_threadaddviews 表的大小。

DIY 模組更新資料最佳化

模組聚合資料的靈活性導致 SQL 語句的條件複雜且不使用索引，MYSQL 對資料表的全表掃描，使網站的整體效能急劇下降。為瞭解決這一問題，Discuz! X2.5 做了如下調整：

1 、在查詢語句的 WHERE 條件中增加 id > max(id) - $maxnum 。

2 、最多掃描 $maxnum 行資料，產品後臺可設定此值，最大是 65535 。

3 、主題、文章、日誌模組中新增此功能。

帖子點評和評分功能的最佳化

Discuz！X2.5 未最佳化前，檢視帖子內容頁時，需要分別到點評表和評分表中查詢資料，必然產生含有 IN 操作的兩條 SQL 查詢，影響了站點效能。為瞭解決這一問題，Discuz! X2.5 做了如下調整：

1 、增加 forum_postcache 表，記錄每一個 PID 的點評列表和評分列表的結果。

2 、檢視帖子時生成快取，點評和評分時刪除快取。

3 、執行計劃任務：每天刪除前一天的資料，以減少 forum_postcache 表的大小。