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

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

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

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

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

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

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

最新評(píng)論