前段時間安裝Drupal 7的時候就遇到自動在MySQL中使用InnoDB的情況，而且好像是即使MySQL默認引擎為MyISAM也依舊使用InnoDB。雖然InnoDB有自己的特點，Drupal 7選用這個也正常，但對于我們來說，有多個子網站的時候，以前是将數據庫分散到多塊硬盤上的，就需要用MyISAM來讓每個子網站有獨立的目錄比較方便，所以還是需要能使用MyISAM。
按照網上找到的一篇文章，修改includes/database/mysql/shema.inc這個文件可以解決，雖然修改drupal core文件不是一個很好的辦法，先這樣用。
前一陣子找朋友在幫忙查看MySQL性能問題的時候，發現一些MySQL數據庫表的索引基數為0，這種時候索引是無效的。我後來檢查了多個庫，發現這種情況還比較普遍，可能由各種原因引起，隻需要将該表優化一遍就可以了，但每次需要人工檢查太麻煩，查了一下資料，可以定期運行以下命令來檢查、優化和自動修複整台MySQL服務器上所有庫中的表：
mysqlcheck -o -autorepaire --all-databases -uroot -ppassword
更多參數說明請看MySQL手冊中的mysql
前段時間在一些Drupal網站中設置了多種Views來方便浏覽者查看内容列表，但很快遇到服務器性能問題而被迫中止，在博文《Drupal網站添加Views後，MySQL服務器負載驟增》中有詳細記錄。
周末實驗成功了《為Drupal網站中的CCK字段在MySQL中添加添加索引來加速Views展示》，應該可以解決前面的問題，這兩天我将以前涉及到網站數據庫打開，在需要添加索引的字段上都添加了索引，然後把Squid和robots.txt中設置的屏蔽網址都解封了，也沒有再看到負載飙升的情況。
幾種添加索引的地方記錄一下：
前些天在Drupal網站中為了設法解決服務器性能的問題，實驗了将MySQL中的一些表合并，雖然最後證實這個效果不明顯，但花了好些時間就還是把代碼記錄下來，以備後用。
過程步驟：
- 備份數據庫
- 離線狀态
- 在4個表中創建字段
- 從3個公用的表複制相應字段内容到新創建的字段中
- 修改content_node_field、content_node_field_instance中内容
今年4、5月份在用Drupal搭建英文版中國郵編網站China Postal Code的過程中，為了讓浏覽者更方便、更習慣，采用了CCK字段+Views展示的擴展模塊，并進行一系列的比較複雜的設置，例如多個computed計算字段、Views查詢中嵌套多級查詢，算是基本上能實現所希望的功能。
但當時就發現在性能上有很多的問題，通過Devel模塊的開啟，可以查看到一些Views查詢數據庫所用的時間非常長，需要幾十甚至幾百秒，常常令服務器負載過高而影響網站訪問。後來找了一個自動檢測MySQL進程的小腳本，當發現超過限定值的進程時就自動kill掉，這個辦法确
用Drupal等CMS系統來搭建網站的主要好處就是不用太關心程序、數據庫等技術細節，把精力主要集中在網站内容本身。不過有些時候也不得不去關注這些技術問題，例如：無法用普通辦法實現的功能、遇到速度性能瓶頸等。
以前在用Drupal搭建網站的時候，就注意到添加新的内容類型(Content Type)後，用CCK設置的字段一般是放在同一個數據庫表中的，例如一個内容類型“名錄”就有一個表“minglu”，而compan, address, postcode這些字段就都在minglu這個表中，後來在一個網站中添加多
從7月初到10月底的4個月時間中，我們已經在服務器上導入了大量數據，建成了一批新的子網站，在接下來的一段時間内我們不準備繼續大增數據量了，而是對已經導入數據的網站進行精細優化調整，這個月已經開始了這方面的工作。
MediaWiki平台的網站都是去年以及以前建成的，這次基本沒有大的調整，隻是一部分網站對模闆進行了更新，以便嵌入microdata微數據标記，雖然也需要運行後台更新、重新生成緩存文件，不過這個對服務器的負載影響不算很大，是可以承受的。
而在對今年新做的Drupal平台的改進中，如果隻是修改内頁模闆、block以及me
前一陣子發現導入的郵編數據中，一些0開頭的6位數最前面一位不知道什麼時候搞丢了，隻剩下5位數了，這顯然是錯的，因為有379個，手工改起來很麻煩，隻有設法批量改了，在網上查了辦法，然後又找同事咨詢，最後一條SQL語句就解決了。
但當時沒有記錄下來，今天在新導入的另外一套郵編數據中又發現這個問題，隻有重新找資料、測試了，還好很快就弄好了，這次記錄下來這個語句：
UPDATE `content_field_postcode` SET `field_postcode_value`=CONCAT("
在用Node Import插件導入大量數據到Drupal網站的過程中，耗時可能是幾小時、幾天甚至幾周，不可避免會出現偶爾中斷、報錯的情況，絕大多數可以繼續導入不受影響，不過如果運氣不好的話，也會遇到數據庫中出現大量錯誤的情況。
有一個100多萬數據量的資料在導入Drupal網站的時候，在90多萬的地方中斷過，後來繼續的時候變得很慢，終于又過了好些天把剩下的導入完，但檢查發現根本就不對，Log中都是報錯。為了不重新導入所有數據，我嘗試直接對MySQL中的庫、表操作來修複，這兩天為了恢複該網站，做了下面這些工作：
- 将
在換用16核CPU、16G内存的服務器後，發現7200轉硬盤不給力，就增加了多塊10000轉的迅猛龍硬盤，一台服務器上的4塊硬盤分别放置系統及備份文件、Squid緩存文件、MySQL文件、Apache和HTML緩存文件，這樣一般訪問都不會有什麼壓力。
但在我們持續導入數據、批量修改模闆的過程中，發現放置Squid緩存文件的硬盤有時占用達到100%，影響正常訪問，于是我們修改Squid設置文件，隻使用幾個G内存作為Web反向加速的緩存，關閉了幾十G、上百G的Squid磁盤緩存，這樣可以避免大量小文件的尋道操作。
接下來又發現系統