5.3.性能與效率
5.3.1. 定長與變長表
包含任何varchar、text等變長字段的數據表，即為變長表，反之則為定長表。
l 對于變長表，由于記錄大小不同，在其上進行許多刪除和更改將會使表中的碎片更多。需要定期運行OPTIMIZE TABLE以保持性能。而定長表就沒有這個問題；
l 如果表中有可變長的字段，將它們轉換為定長字段能夠改進性能，因為定長記錄易于處理。但在試圖這樣做之前，應該考慮下列問題：
l 使用定長列涉及某種折衷。它們更快，但占用的空間更多。char(n) 類型列的每個值總要占用n 個字節(jié)(即使空串也是如此)，因為在表中存儲時，值的長度不夠將在右邊補空格；
l 而varchar(n)類型的列所占空間較少，因為只給它們分配存儲每個值所需要的空間，每個值再加一個字節(jié)用于記錄其長度。因此，如果在char和varchar類型之間進行選擇，需要對時間與空間作出折衷；
l 變長表到定長表的轉換，不能只轉換一個可變長字段，必須對它們全部進行轉換。而且必須使用一個ALTER TABLE語句同時全部轉換，否則轉換將不起作用；
l 有時不能使用定長類型，即使想這樣做也不行。例如對于比255字符更長的串，沒有定長類型；
l 在設計表結構時如果能夠使用定長數據類型盡量用定長的，因為定長表的查詢、檢索、更新速度都很快。必要時可以把部分關鍵的、承擔頻繁訪問的表拆分，例如定長數據一個表，非定長數據一個表。例如phpcms的phpcms_member表等。因此規(guī)劃數據結構時需要進行全局考慮；
進行表結構設計時，應當做到恰到好處，反復推敲，從而實現最優(yōu)的數據存儲體系。
5.3.2. 運算與檢索
數值運算一般比字符串運算更快。例如比較運算，可在單一運算中對數進行比較。而串運算涉及幾個逐字節(jié)的比較，如果串更長的話，這種比較還要多。
如果串列的值數目有限，應該利用普通整型或emum類型來獲得數值運算的優(yōu)越性。
更小的字段類型永遠比更大的字段類型處理要快得多。對于字符串，其處理時間與串長度直接相關。一般情況下，較小的表處理更快。對于定長表，應該選擇最小的類型，只要能存儲所需范圍的值即可。例如，如果mediumint夠用，就不要選擇bigint。對于可變長類型，也仍然能夠節(jié)省空間。一個TEXT 類型的值用2 字節(jié)記錄值的長度，而一個LONGTEXT 則用4字節(jié)記錄其值的長度。如果存儲的值長度永遠不會超過64KB，使用TEXT 將使每個值節(jié)省2字節(jié)。
5.3.3. 結構優(yōu)化與索引優(yōu)化
索引能加快查詢速度，而索引優(yōu)化和查詢優(yōu)化是相輔相成的，既可以依據查詢對索引進行優(yōu)化，也可以依據現有索引對查詢進行優(yōu)化，這取決于修改查詢或索引，哪個對現有產品架構和效率的影響最小。
索引優(yōu)化與查詢優(yōu)化是多年經驗積累的結晶，在此無法詳述，但仍然給出幾條最基本的準則。
首先，根據產品的實際運行和被訪問情況，找出哪些SQL語句是最常被執(zhí)行的。最常被執(zhí)行和最常出現在程序中是完全不同的概念。最常被執(zhí)行的SQL語句，又可被劃分為對大表(數據條目多的)和對小表(數據條目少的)的操作。無論大表或小表，有可分為讀(SELECT)多、寫(UPDATE/INSERT)多或讀寫都多的操作。
對常被執(zhí)行的SQL語句而言，對大表操作需要尤其注意：
l 寫操作多的，通?？墒褂脤懭刖彺娴姆椒ǎ葘⑿枰獙懟蛐枰碌臄祿彺嬷廖募蚱渌?，定期對大表進行批量寫操作。同時，應盡量使得常被讀寫的大表為定長類型，即便原本的結構中大表并非定長。大表定長化，可以通過改變數據存儲結構和數據讀取方式，將一個大表拆成一個讀寫多的定長表，和一個讀多寫少的變長表來實現；
l 讀操作多的，需要依據SQL查詢頻率設置專門針對高頻SQL語句的索引和聯合索引。
而小表就相對簡單，加入符合查詢要求的特定索引，通常效果比較明顯。同時，定長化小表也有益于效率和負載能力的提高。字段比較少的小定長表，甚至可以不需要索引。
其次，看SQL語句的條件和排序字段是否動態(tài)性很高(即根據不同功能開關或屬性，SQL查詢條件和排序字段的變化很大的情況)，動態(tài)性過高的SQL語句是無法通過索引進行優(yōu)化的。惟一的辦法只有將數據緩存起來，定期更新，適用于結果對實效性要求不高的場合。
MySQL索引，常用的有PRIMARY KEY、INDEX、UNIQUE幾種，詳情請查閱MySQL文檔。通常，在單表數據值不重復的情況下，PRIMARY KEY和UNIQUE索引比INDEX更快，請酌情使用。
事實上，索引是將條件查詢、排序的讀操作資源消耗，分布到了寫操作中，索引越多，耗費磁盤空間越大，寫操作越慢。因此，索引決不能盲目添加。對字段索引與否，最根本的出發(fā)點，依次仍然是SQL語句執(zhí)行的概率、表的大小和寫操作的頻繁程度。
5.3.4. 查詢優(yōu)化
MySQL中并沒有提供針對查詢條件的優(yōu)化功能，因此需要開發(fā)者在程序中對查詢條件的先后順序人工進行優(yōu)化。例如如下的SQL語句：
SELECT * FROM table WHERE a>'0' AND b<'1' ORDER BY c LIMIT 10; 

事實上無論a>'0'還是b<'1'哪個條件在前，得到的結果都是一樣的，但查詢速度就大不相同，尤其在對大表進行操作時。
開發(fā)者需要牢記這個原則：最先出現的條件，一定是過濾和排除掉更多結果的條件；第二出現的次之；以此類推。因而，表中不同字段的值的分布，對查詢速度有著很大影響。而ORDER BY中的條件，只與索引有關，與條件順序無關。
除了條件順序優(yōu)化以外，針對固定或相對固定的SQL查詢語句，還可以通過對索引結構進行優(yōu)化，進而實現相當高的查詢速度。原則是：在大多數情況下，根據WHERE條件的先后順序和ORDER BY的排序字段的先后順序而建立的聯合索引，就是與這條SQL語句匹配的最優(yōu)索引結構。盡管，事實的產品中不能只考慮一條SQL語句，也不能不考慮空間占用而建立太多的索引。
同樣以上面的SQL語句為例，最優(yōu)的當table表的記錄達到百萬甚至千萬級后，可以明顯的看到索引優(yōu)化帶來的速度提升。
依據上面條件優(yōu)化和索引優(yōu)化的兩個原則，當table表的值為如下方案時，可以得出最優(yōu)的條件順序方案：
字段a 字段b 字段c
1 7 11
2 8 10
3 9 13
-1 0 12
最優(yōu)條件：b<'1' AND a>'0'
最優(yōu)索引：INDEX abc (b, a, c)
原因：b<'1'作為第一條件可以先過濾掉75%的結果。如果以a>'0'作為第一條件，則只能先過濾掉25%的結果
注意1：字段c由于未出現于條件中，故條件順序優(yōu)化與其無關
注意2：最優(yōu)索引由最優(yōu)條件順序得來，而非由例子中的SQL語句得來
注意3：索引并非修改數據存儲的物理順序，而是通過對應特定偏移量的物理數據而實現的虛擬指針 

EXPLAIN語句是檢測索引和查詢能否良好匹配的簡便方法。在phpMyAdmin或其他MySQL客戶端中運行EXPLAIN+查詢語句，例如EXPLAIN select * FROM table WHERE a>'0' AND b<'1' ORDER BY c;這種形式，即使得開發(fā)者無需模擬上百萬條數據，也可以驗證索引是否合理，相關細節(jié)請參考MySQL說明。
值得提出的是，Using filesort是最不應當出現的情況，如果EXPLAIN得出此結果，說明數據庫為這個查詢專門建立了一個用以緩存結果的臨時表文件，并在查詢結束后刪除。眾所周知，硬盤I/O速度始終是計算機存儲的瓶頸，因此，查詢中應當盡全力避免高執(zhí)行頻率的SQL語句使用filesort。盡管，開發(fā)者永遠都不可能保證產品中的全部SQL語句都不會使用filesort。
限于篇幅，本文檔遠遠沒有涵蓋數據庫優(yōu)化的方方面面，例如：聯合索引與普通索引的可重用性、JOIN連接的索引設計、MEMORY/HEAP表等。數據庫優(yōu)化實際上就是在很多因素和利弊間不斷權衡、修改，惟有在成功與失敗經驗中反復推敲才能得出的經驗，這種經驗往往就是最難能可貴和價值連城的。
5.3.5. 兼容性問題
由于MySQL 3.23至5.0的變化很大，因此程序中盡量不使用特殊的SQL語句，以免帶來兼容性問題，并給數據庫移植造成困難。
通常在MySQL 4.1以上版本，phpcms應使用相當的字符集來存儲，例如GBK/BIG5/UTF-8。傳統(tǒng)的latin1編碼雖然有一定的兼容性，但仍然不是推薦的選擇。使用相應非默認字符集時，程序每次運行時需要使用SET NAMES ‘character_set';來規(guī)定連接、傳輸和結果的字符集。
Mysql 5.0以上新增了數種SQL_MODE，默認的SQL_MODE依服務器安裝設置不同而不同，因此程序每次運行時需要使用SET SQL_MODE='';來規(guī)定當前的SQL模式。
6. 模板設計
6.1.代碼標記
HTML代碼標記一律采用小寫字母形式，杜絕任何使用大寫字母的方式

模板中所有的邏輯體，如{if}、{loop}等，必須前后使用HTML注釋(<!-- -->)，即類似<!--{if expr}-->的形式。事實上，phpcms模板編譯器是支持不加HTML注釋的邏輯體寫法的，但加入注釋可以使得模板可讀性更好，同時方便用戶使用DreamWeaver或FrontPage等對模板進行修改。
6.2.書寫規(guī)則
6.2.1. HTML
所有HTML標記參數賦值需使用雙引號包含，例如，應當使用 

<input type=”text” name=”test” value=”ok”>
而絕對不能使用 

<input type=text name=test value=ok>
。
在任何情況下，產品中的模板文件必須采用手寫HTML代碼的方式，而絕對不能使用DreamWeaver、FrontPage等自動網頁制作工具進行撰寫或修改。
6.2.2. 變量
模板中使用的變量，依據作用和出現位置不同，分為幾種方式：
l 邏輯體中，即被包圍起來的部分，例如這種形式，其中的變量書寫規(guī)范與PHP程序中完全一致；
開發(fā)者需要使用{}將變量括起來，以免出現模板編譯錯誤，可能的情況如下：
l 變量前后含有中括號的或其他敏感字符的(包括但不限于“$”、“'”等)，正確的寫法為descriptionnew[{$buddy[buddyid]}]；
l 數組的下標為變量的，正確的寫法為{$extcredits[$creditstrans][title]}；
l 其他變量十分復雜的情況。
6.2.3. 語言元素
6.2.4. 縮進
在phpcms的*.html模板文件中，由于具備邏輯結構，故不考慮任何HTML本身的縮進，所有縮進均意為著邏輯上的縮進結構?？s進采用TAB方式，不使用空格作為縮進符號，僅需適當斷行即可。例如：

<!--{loop $articles $article}-->
    <table cellspacing=”0” cellspadding=”0” border=”0”>
    <tr><td>{$article[‘title']}</tr></td>
    </table>
<!--{/loop}-->
7. 文件與目錄
7.1.文件命名
所有包含PHP代碼的程序文件或半程序文件，應以小寫.php作為擴展名，而不要使用.phtml、.php3、.inc、.class等作為擴展名。
普通程序
能夠被URL直接調用的程序，例如list.php、index.php，直接使用程序名+.php的方式命名
函數庫和類庫程序
分別以小寫.func.php和.class.php作為擴展名。函數庫和類庫程序只能被其他程序引用，而不能獨立運行。其中不能包含任何流程性的、不屬于任何函數或類的程序代碼。
流程性程序
以小寫.inc.php作為擴展名。只能被其他程序引用，而不能獨立運行。其中不能包含任何函數或類代碼的程序代碼。
模板源文件
以小寫.html作為擴展名。模板源文件按照phpcms模板編碼規(guī)則進行編寫，不是可以執(zhí)行的程序，而只能被phpcms模板編譯器所解析，放置于./templates/default或./templates下的其他模板目錄下。
模板目標文件
模板文件被編譯后自動生成的目標程序，以小寫. php作為擴展名，存放于./data/templates目錄下。
語言包文件
以小寫.lang.php作為擴展名，只能存放模板或程序使用的語言包信息。
緩存文件
此類文件為系統(tǒng)自動生成，以cache_xxx.php、usergroup_xxx.php、style_xxx.php等類似形式命名，存放于./data/cache目錄下。
7.2.目錄命名
phpcms目錄命名以前面《4.4命名原則》的約定為基本準則。在可能的情況下，多以復數形式出現，如./templates、./images等。
由于目錄數量較少，因此目錄命名大多是一些習慣和約定俗成，開發(fā)人員如需新建目錄，應與項目組成員進行磋商，達成一致后方可實施。
7.3.空目錄索引
請在所有不包含普通程序(即能夠被URL直接調用的程序)的目錄中放置一個1字節(jié)的index.htm文件，內容為一個空格。幾乎除phpcms根目錄以外，所有目錄都屬于這一類型，因此開發(fā)者需要在這些目錄全部放入空index.htm文件，以避免當http服務器的Directory Listing打開時，服務器文件被索引和列表。
附件目錄等敏感目錄，要在程序中實現相應功能，當新建下級目錄時，必須自動寫入一個空的index.htm文件，以避免新建目錄被索引的問題。 

最新評論