[資料庫]關于設計表時應該注意的問題

如有錯誤歡迎大家指出。這段時間在家裡，做了點修正。

1、慎重選擇表名。

有兩種選擇：

按照多數開發語言的命名規則。比如（mycustomer）。

按照多數開源思想命名規則。比如（my_customer）。

按照咱們中國人的思想。比如（我的客戶）。

第一種有個缺點，很容易忘掉大寫的字母。

第二種則比較好，每個word間用下劃線連接配接，避免遺忘。

第三種建議不要用，雖然很好記。不覺得解析這個表的時候還需要編碼轉化嗎？我個人了解，大家可以補充。

2.  關于編碼的設定。

a．             gbk/gb2312.（适用于純中文存儲）。

b．           utf8.（适用于中英文混合存儲）。

c．            latin1。（适用于純英文存儲）。

d.     其他的。

3. 關于表引擎的選擇。

a.                 myisam.（很多人說她的表級鎖定會帶來好多問題，其實隻要設計好對應的表以及寫好對應的sql查詢就沒有那麼大的問題。）

b.                  innodb. （如果要用到事務，選擇她不會錯。至于多數人講的master/slave結構上用innodb在master的選擇是否正确，就要看你怎麼用了。不能一味的瘋狂使用innodb。除非你想要確定非常高可用性，

）

c.                  csv. （以前我寫過文章，關于這個引擎。個人覺得最主要的是來存儲少量資料以及從excel到mysql的轉換方面會很有用。當然隻要涉及到規則資料的導入，她就可以辦到。）

d.                  blackhole. （覺得最完美的用處在于masetr/slave上面，并且master是一個臨時的專門負責寫的機器。不過缺點也很多，會與myisam或者innodb或者其他的引擎有所沖突，這點自己要做個權衡）。

e.                   memory. （應該說是myisam的兄弟了。不過在讀記憶體總比讀磁盤的速度要快。不過要注意，它不支援動态資料類型）。

f.                   federated. （典型的分布式引擎。我以前文章中有介紹。）

g.    ndb。（網絡版存儲引擎。因為replication 總是有延遲，是以如果系統容不得任何延遲，就用這個吧。）

   h.    folcon。（6.0後用來代替innodb的引擎。）

i.                  其他舊的以及新開發的引擎具體介紹：http://dev.mysql.com/doc/refman/6.0/en/storage-engines.html）。

4. 關于屬性資料類型的選擇。

a.                  int（一個位元組的tinyint，兩個位元組的smallint，三個位元組的mediumint，四個位元組的int，8個位元組的bigint。記住：unsigned不管你定義或者不定義，都不影響内部的存儲位元組大小）

b.                   少于10個字元用char是在合适不過了。（不過要記住在memory引擎裡面會自動把varchar轉化為char）

c.                   我一般用decimal或者numeric來代替float 或者double。因為老闆要求精确的數字。如果不要求精确的，那就用float吧。速度快，占空間小。（decima、float(p)是動态存儲。比如 

 ecimal(10,2)占用5個位元組。float占4個位元組，）

d.                 blob，text,varchar（一般存放文章内容，特别是新聞網站。需要的位元組數是所存儲的字元長度+1。記住blob和varchar是text和char的binary類型）

e.                   enum（在一定範圍内絕佳的代替varchar和char的工具，因為她隻占一到兩個位元組。）

f.                   時間和日期類型（占3個位元組的date，8個位元組的datetime，4個位元組的timestamp，3個位元組的time，1個位元組的year。）。如果要存儲比如‘1983’這樣的年份，用year明顯比varchar或者char要節省空間。因為後者要占5個位元組。

g.                  boolean（用來存儲yes或者no之類的值，占用一個位元組。）

h.                  關于自增字段。目前我們的項目中涉及到好多order by rand()操作。此類語句在資料庫并發大的時候會造成cpu嚴重阻塞，持續産生資料庫死鎖！解決此類問題最好的辦法就是利用自增字段，用程式随即生成數字序列，或者在資料庫端随即生成數字序列。

i.                    關于zerofill。非常好用的前置填補0的存儲，而不是用用對應個數的空串來代替。在需要前置補零的操作中int zerofill可以用來代替char或者varchr。

5.  關于預設值。

a.                  在5.0之後，隻要設定字段為not null，系統自動給出預設值。對應char->’’,int->0,boolean->0等等。

b.                   在5.0之前的版本，需要手動指定預設值，否則會出現一定的異常。到時候查都不好查了。

6.  關于多資料庫建立。

a.                  應該把對應的業務放在各自不同的資料庫裡，而不是所有業務放到一個庫裡面。

b.                   資料庫的命名和表命名一樣。

7.  關于索引。

a.                  設計表初期盡量考慮到應該建立的索引。所有建立的索引一定要測試一下，看是否有必要，否則會翻倍的減少寫資料的性能。

b.                   對于隻有存儲0或者1的列，盡量幹掉索引，單獨分出兩個表。一個代替0，另外一個代替1。或者在一個字段裡面用emum或者char(0)或者char(1)來代替。

   ps： 最後一個要值得注意的，就是盡量所有的字段用not null。雖然mysql可以對null列進行索引，不過我不建議。