Drupal7 非常強大，其強大核心之一是entity field模式，比如node/taxonomy term/ user 都是一種entity, 并且支持field模式，也就是用戶可以隨意的添加新的field給node/taxonomy term/user；

強大的背后是性能的擔憂；加入node有10個field,那么就對應10個表來裝載field數據，而不是一個列，這就導致了至少10個join 去查詢一個node. 這對數據庫的性能影響是巨大，甚至是致命的；試想，如果一個頁面有10個block, 每個block包含10個node, 每個node有10個field, 那么查詢表的次數就是10次（使用entity_load_multiple），join的次數是100次;

我們幾乎沒有直接的辦法解決這個問題，畢竟這就是Drupal.

在這里我們提供一個小的性能優化辦法，即使用drupal_static函數，這個優化方法是PHP級別的，需要了解基本的PHP知識。

這個函數可以緩存函數執行結果，保證在函數執行退出后，結果存在內存中，但是又不同于memcache，它在一個請求結束后就自動釋放。

這里舉個例子：

現在有這樣子的需求，頁面上有2個block: last_news block, last_comment block，內容要求是last_comment 需要10條，首先取last_news 的comment, 如果不足，則按照時間先后順序取出除了和last_news comment 匹配的項；

分析下，last_news block保護了last_news 數據，在last_comment 也需要這個數據，假設有方法叫: news_last_news_data() 返回這個last_news,

函數原型:

則需要調用2次，那么數據庫也需要查詢2次，相對的JOIN問題也會凸顯，在并發量情況下，比如20，那么數據庫來說就有20次查詢，壓力還是有點的怕，在1G內存下VPS應該是撐不住這個并發了；

怎么辦？我們要減少數據庫的請求，分析，我們看到news_last_news_data()不需要參數，功能也就是查詢而已，我們斷定每次調用返回的結果都是一樣。那么我們有沒有辦法緩存查詢結果？

有！ drupal_static來了.

看下面偽代碼:

分析如下：

第一行，我調用了drupal_static()方法，第一個參數是一個key, key是唯一鍵，這里使用魔法常量__FUNCTION__表示, 代表著使用方法名作為key, 第二個參數是默認值，當緩存不存在的時候使用一個空的數組替代

第二行，我加了一個判斷，如果$last_news緩存已經存在，則不執行查詢，這樣就減少了這個查詢的一半的壓力，運行一下，速度是不是很塊！

后面的代碼你應該懂了吧！

此處還要注意：在php5.1.13有一個BUG, 也是我使用過程中遇到的，意思是當在匿名方法里面使用use關鍵字調用匿名方法上層的變量，且這個變量是來自drupal_static的返回值，那么匿名方法執行完后，會修改上層的變量的引用，也就是在后面引用到這個變量，那么這個變量以及不是drupal_static的返回值，所以緩存會失效。這個BUG說的很復雜，遇到后就看看是否使用了匿名方法吧。