關於MySQL表設計應該注意的問題

關於MySQL表設計應該注意的問題

轉自 http://blog.chinaunix.net/u/29134/showart_1316574.html

1、慎重選擇表名。

 

有兩種選擇:

按照多數開發語言的命名規則。比如(myCustomer)。

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

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

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

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

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

2.關於編碼的設定。 

A             GBK/GB2312.(適用於純中文存儲)。

B           UTF8.(適用於中英文混合存儲)。

C            LATIN1。(適用於純英文存儲)。

D.     其他的。

3.關於表引擎的選擇。 

A.                 MYISAM.(很多人說她的表級鎖定會帶來好多問題,其實只要設計好對應的表以及寫好對應的SQL查詢就沒有那麼大的問題。)

B.                  INNODB. (如果要用到事務,選擇她不會錯。至於多數人講的MASTER/SLAVE結構上用INNODBMASTER的選擇是否正確,就要看你怎麼用了。不能一味的瘋狂使用INNODB。除非你想要確保非常高可用性,

C.                  CSV. (以前我寫過文章,關於這個引擎。個人覺得最主要的是來存儲少量數據以及從EXCELMYSQL的轉換方面會很有用。當然只要涉及到規則數據的導入,她就可以辦到。)

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,四個字節的INT8個字節的BIGINT。記住:UNSIGNED不管你定義或者不定義,都不影響內部的存儲字節大小)

B.                   少於10個字符用CHAR是在合適不過了。(不過要記住在MEMORY引擎裏面會自動把VARCHAR轉化爲CHAR

C.                   我一般用DECIMAL或者NUMERIC來代替FLOAT 或者DOUBLE。因爲老闆要求精確的數字。如果不要求精確的,那就用FLOAT吧。速度快,佔空間小。(DECIMAFLOAT(P)是動態存儲。比如:DECIMAL(10,2)佔用5個字節。FLOAT4個字節,)

D.                 BLOBTEXT,VARCHAR(一般存放文章內容,特別是新聞網站。需要的字節數是所存儲的字符長度+1。記住BLOBVARCHARTEXTCHARBINARY類型)

E.                   ENUM(在一定範圍內絕佳的代替VARCHARCHAR的工具,因爲她只佔一到兩個字節。)

F.                   時間和日期類型(佔3個字節的DATE8個字節的DATETIME4個字節的TIMESTAMP3個字節的TIME1個字節的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列進行索引,不過我不建議。

發佈了95 篇原創文章 · 獲贊 4 · 訪問量 22萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章