如有錯誤歡迎大家指出。這段時間在家裡，做了點修正。 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的引擎。）
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列進行索引，不過我不建議。