資料庫表字段設計效能和效率

3.效能與效率

5.3.

定長與變長表

包含任何varchar、text等變長字段的資料表，即為變長表，反之則為定長表。 l

對於變長表，由於記錄大小不同，在其上進行許多刪除和更改將會使表中的碎片更多。需要定期執行 optimize table以保持效能。而定長表就沒有這個問題； l

如果表中有可變長的字段，將它們轉換為定長欄位能夠改進效能，因為定長記錄易於處理。但在試圖這樣做之前，應該考慮下列問題： l

使用定長列涉及某種折衷。它們更快，但占用的空間更多。char(n) 型別列的每個值總要占用n 個位元組(即使空串也是如此)，因為在表中儲存時，值的長度不夠將在右邊補空格； l

而varchar(n)型別的列所佔空間較少，因為只給它們分配儲存每個值所需要的空間，每個值再加乙個位元組用於記錄其長度。因此，如果在char和varchar型別之間進行選擇，需要對時間與空間作出折衷； l

變長表到定長表的轉換，不能只轉換乙個可變長欄位，必須對它們全部進行轉換。而且必須使用乙個 alter table語句同時全部轉換，否則轉換將不起作用； l

有時不能使用定長型別，即使想這樣做也不行。例如對於比255字元更長的串，沒有定長型別； l

在設計表結構時如果能夠使用定長資料型別盡量用定長的，因為定長表的查詢、檢索、更新速度都很快。必要時可以把部分關鍵的、承擔頻繁訪問的表拆分，例如定長資料乙個表，非定長資料乙個表。例如phpcms的phpcms_member表等。因此規劃資料結構時需要進行全域性考慮；

進行表結構設計時，應當做到恰到好處，反覆推敲，從而實現最優的資料儲存體系。

5.3.2.

運算與檢索

數值運算一般比字串運算更快。例如比較運算，可在單一運算中對數進行比較。而串運算涉及幾個逐字節的比較，如果串更長的話，這種比較還要多。

如果串列的值數目有限，應該利用普通整型或emum型別來獲得數值運算的優越性。

更小的字段型別永遠比更大的字段型別處理要快得多。對於字串，其處理時間與串長度直接相關。一般情況下，較小的表處理更快。對於定長表，應該選擇最小的類型，只要能儲存所需範圍的值即可。例如，如果mediumint夠用，就不要選擇bigint。對於可變長型別，也仍然能夠節省空間。乙個text 型別的值用2 位元組記錄值的長度，而乙個longtext 則用4位元組記錄其值的長度。如果儲存的值長度永遠不會超過64kb，使用text 將使每個值節省 2位元組。

5.3.3.

結構優化與索引優化

索引能加快查詢速度，而索引優化和查詢優化是相輔相成的，既可以依據查詢對索引進行優化，也可以依據現有索引對查詢進行優化，這取決於修改查詢或索引，哪個對現有產品架構和效率的影響最小。

索引優化與查詢優化是多年經驗積累的結晶，在此無法詳述，但仍然給出幾條最基本的準則。

首先，根據產品的實際執行和被訪問情況，找出哪些sql語句是最常被執行的。最常被執行和最常出現在程式中是完全不同的概念。最常被執行的sql語句，又可被劃分為對大表(資料條目多的)和對小表(資料條目少的)的操作。無論大表或小表，有可分為讀(select)多、寫(update/insert)多或讀寫都多的操作。

對常被執行的sql語句而言，對大表操作需要尤其注意： l

寫操作多的，通常可使用寫入快取的方法，先將需要寫或需要更新的資料快取至檔案或其他表，定期對大表進行批量寫操作。同時，應盡量使得常被讀寫的大表為定長型別，即便原本的結構中大表並非定長。大表定長化，可以通過改變資料儲存結構和資料讀取方式，將乙個大表拆成乙個讀寫多的定長表，和乙個讀多寫少的變長表來實現； l

讀操作多的，需要依據sql查詢頻率設定專門針對高頻sql語句的索引和聯合索引。

而小表就相對簡單，加入符合查詢要求的特定索引，通常效果比較明顯。同時，定長化小表也有益於效率和負載能力的提高。字段比較少的小定長表，甚至可以不需要索引。

其次，看sql語句的條件和排序字段是否動態性很高(即根據不同功能開關或屬性，sql查詢條件和排序欄位的變化很大的情況)，動態性過高的sql語句是無法通過索引進行優化的。惟一的辦法只有將資料快取起來，定期更新，適用於結果對實效性要求不高的場合。

mysql

索引，常用的有primary key、index、unique幾種，詳情請查閱mysql

文件。通常，在單錶資料值不重複的情況下，primary key和unique索引比index更快，請酌情使用。

事實上，索引是將條件查詢、排序的讀操作資源消耗，分布到了寫操作中，索引越多，耗費磁碟空間越大，寫操作越慢。因此，索引決不能盲目新增。對欄位索引與否，最根本的出發點，依次仍然是sql語句執行的概率、表的大小和寫操作的頻繁程度。

5.3.4.

查詢優化

mysql

中並沒有提供針對查詢條件的優化功能，因此需要開發者在程式中對查詢條件的先後順序人工進行優化。例如如下的sql語句：

select * from table where a>』0』 and b<』1』 order by c limit 10;

事實上無論a>』0』還是b<』1』哪個條件在前，得到的結果都是一樣的，但查詢速度就大不相同，尤其在對大表進行操作時。

開發者需要牢記這個原則：最先出現的條件，一定是過濾和排除掉更多結果的條件；第二出現的次之；以此類推。因而，表中不同欄位的值的分布，對查詢速度有著很大影響。而order by中的條件，只與索引有關，與條件順序無關。

除了條件順序優化以外，針對固定或相對固定的sql查詢語句，還可以通過對索引結構進行優化，進而實現相當高的查詢速度。原則是：在大多數情況下，根據 where條件的先後順序和order by的排序欄位的先後順序而建立的聯合索引，就是與這條sql語句匹配的最優索引結構。儘管，事實的產品中不能只考慮一條sql語句，也不能不考慮空間占用而建立太多的索引。

同樣以上面的sql語句為例，最優的當table表的記錄達到百萬甚至千萬級後，可以明顯的看到索引優化帶來的速度提公升。

依據上面條件優化和索引優化的兩個原則，當table表的值為如下方案時，可以得出最優的條件順序方案：

欄位a欄位b

欄位c 1

7 11

2 810 3

9 13

-1 0

12最優條件：b<』1』 and a>』0』

最優索引：index abc (b, a, c)

原因：b<』1』作為第一條件可以先過濾掉75%的結果。如果以a>』0』作為第一條件，則只能先過濾掉25%的結果

注意1：欄位c由於未出現於條件中，故條件順序優化與其無關

注意2：最優索引由最優條件順序得來，而非由例子中的sql語句得來

注意3：索引並非修改資料儲存的物理順序，而是通過對應特定偏移量的物理資料而實現的虛擬指標

explain語句是檢測索引和查詢能否良好匹配的簡便方法。在phpmyadmin或其他mysql

客戶端中執行explain+查詢語句，例如 explain select * from table where a>』0』 and b<』1』 order by c;這種形式，即使得開發者無需模擬上百萬條資料，也可以驗證索引是否合理，相關細節請參考mysql

說明。值得提出的是，using filesort是最不應當出現的情況，如果explain得出此結果，說明資料庫為這個查詢專門建立了乙個用以快取結果的臨時表檔案，並在查詢結束後刪除。眾所周知，硬碟i/o速度始終是計算機儲存的瓶頸，因此，查詢中應當盡全力避免高執行頻率的sql語句使用 filesort。儘管，開發者永遠都不可能保證產品中的全部sql語句都不會使用filesort。

限於篇幅，本文件遠遠沒有涵蓋資料庫優化的方方面面，例如：聯合索引與普通索引的可重用性、join連線的索引設計、memory/heap表等。資料庫優化實際上就是在很多因素和利弊間不斷權衡、修改，惟有在成功與失敗經驗中反覆推敲才能得出的經驗，這種經驗往往就是最難能可貴和價值連城的。

5.3.5.

相容性問題

由於mysql

3.23至5.0的變化很大，因此程式中盡量不使用特殊的sql語句，以免帶來相容性問題，並給資料庫移植造成困難。

通常在mysql

4.1 以上版本，phpcms應使用相當的字符集來儲存，例如gbk/big5/utf-8。傳統的latin1編碼雖然有一定的相容性，但仍然不是推薦的選擇。使用相應非預設字符集時，程式每次執行時需要使用set names 『character_set』;來規定連線、傳輸和結果的字符集。

mysql

5.0以上新增了數種sql_mode，預設的sql_mode依伺服器安裝設定不同而不同，因此程式每次執行時需要使用 set sql_mode=』』;來規定當前的sql模式。

資料庫表字段設計效能和效率

資料庫表字段介紹

資料庫表字段命名規範

資料庫表字段命名規範

資料庫表字段設計 效能和效率

資料庫表字段介紹

資料庫表字段命名規範

資料庫表字段命名規範

相關推薦

資料庫表字段設計效能和效率