用Drupal等CMS系統來搭建網站的主要好處就是不用太關心程序、數據庫等技術細節，把精力主要集中在網站内容本身。不過有些時候也不得不去關注這些技術問題，例如：無法用普通辦法實現的功能、遇到速度性能瓶頸等。
以前在用Drupal搭建網站的時候，就注意到添加新的内容類型(Content Type)後，用CCK設置的字段一般是放在同一個數據庫表中的，例如一個内容類型“名錄”就有一個表“minglu”，而compan, address, postcode這些字段就都在minglu這個表中，後來在一個網站中添加多個内容類型的時候，發現如果有相同名字的字段（例如postcode），就不存放在各自的表中，而是新建一個專門的表content_field_postcode，把各個内容類型中的postcode都集中放在這個表中，用nid, vid來對應頁面node。
不是很明白Drupal中這樣做的用意，可能在某些内容類型多的情況下，可以減少一些設置的工作量吧。隻要能正常使用，我也沒有特别深究。
但最近有幾個網站打開越來越慢，服務器越來越忙，導入保存數據超時報錯。今天和同事一起檢查，服務器上的MySQL資源占用明顯過多，在PHPMyAdmin中觀察進程，發現有很多帶有Left Join的進程運行時間超長，而這些進程都是Views為了從不同的表中讀取多個字段産生的。問了技術部同事，這種帶有Left Join的進程比單表查詢的效率肯定低了不少，但具體度量數據還不好說。
要是早知道會産生這樣的問題，我們在導入多種内容類型的時候就應該把字段都定義為不同的名稱，這樣同一種内容類型中的所有數據都放在單表中，查詢起來肯定快多了。但現在要想還原還很不容易，有個CCK Field Rename模塊，但不知道是否能解決問題，如果直接在MySQL中操作也是可能還原的，隻是更麻煩、複雜，有風險。
我們現在的辦法是從其他方面減少Views的負載（例如減少輸出字段、取消排序鍊接），并調整my.cnf中的一些參數，觀察看看能否有效降低負載，如果實在不行的話，還要通過幾個可能的辦法來解決：CCK Field Rename擴展模塊、直接MySQL中操作、還原成幾個月前的老數據并重新定義和導入新數據。
评论