Mysql範式與數據類型選擇

良好的邏輯設計與物理設計是高性能的基石，當咱們在設計數據表結構的時候，應該跟根據業務邏輯來分析具體狀況，而後設計出比較合理，高效的數據表結構

在數據表結構設計中，不得不提的就是範式與數據類型了

Mysql三範式

• 字段不可分；即字段具備原子性 字段不可再分,不然就不是關係數據庫;
• 有主鍵，非主鍵字段依賴主鍵; 惟一性 一個表只說明一個事物
• 非主鍵字段不能相互依賴；每列都與主鍵有直接關係，不存在傳遞依賴

範式的優勢與缺點

• 優勢

  • 範式化設計更新一般比反範式化更新要快
  • 當數據高度範式化時，就只有少許或者沒有重複數據，這樣修改的時候就只須要修改少許的數據
  • 範式化的表一般比較小，能夠更好的放在內存裏面，操做就會更容易
  • 由於範式化設計以後，冗餘數據較少，因此在執行某些查詢的時候可能就不會用到group by，distinct 這樣也提升了查詢效率
• 缺點
  由於嚴格遵循範式化設計的話。在某些業務場景下可能會查詢多個表。這樣的一樣會使得查詢效率變的很低。並且在某些時候由於多表查詢的緣由，可能某些索引不會被命中。

這裏咱們看到範式化的設計有優勢也有缺點，因此在實際的項目中，咱們一般是混範式化設計。
某些表徹底遵循範式化；某些表遵循部分範式化設計。在設計某些表的時候 會用到反範式化的思想，將某些數據存到同一張表中。這樣能夠減小不少關聯查詢，也能夠更好的去設計索引關係。

好比 users表 與 user_messages表中，都會保存一個 user_account_type字段。這樣的話，在單獨查詢 user_account_type=1的消息總數時就不須要再去關聯 users表了。

數據類型

Mysql支持的數據類型有不少種，因此選擇正確的數據類型對提升性能有着相當重要的做用。可是無論哪一種數據類型咱們都應該參考下面幾個原則

• 更小的一般更好；更小的數據類型一般更快，由於他們佔用更少的磁盤、內存、CPU緩存。
• 簡單就好；操做簡單的數據類型一般須要更少的CPU週期。例如：整型比字符串操做代價更低
• 儘可能避免NULL；若是查詢中包含可爲Null的列，對於Mysql來講更難優化，由於能夠爲null的列使得索引，索引統計和值都變的更加複雜

整數類型

Mysql的整數類型有 TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT。他們使用到的儲存空間分別是,8,16,24,32,64位。值的範圍是-2^(N-1)到2^(N-1)-1
整形能夠選擇UNSIGNED屬性，表示是否有符號，不容許爲負值。
如 TINYINT UNSIGNED 值的範圍 0~255， 而 TINYINT 值的範圍是-128-127。須要注意點是有符號跟無符號使用相同的儲存空間，擁有相同的性能，因此能夠根據實際狀況來選擇類型。

字符串類型

VARCHAR,CHAR是兩種最主要的字符串類型，

• VARCHAR類型用於儲存可變字符串，是常見的字符串類型。它比定長類型更節省空間。
• CHAR定長字符串類型，分配固定長度的空間。在保存某些定長字符串時比VARCHAR更有優點、好比md5定長字符串，由於定長類型字符串不容易產生碎片。

對於 VARCHAR(5)和 VARCHAR(100)儲存 hello的空間開銷是同樣的，那麼是否是咱們就能夠定義長度爲 100呢?固然不是了，更長的列會消耗更多的內存，由於Mysql一般會分配固定大小的內存塊來保存內部值。因此最好的策略就是分配合理的長度，這樣就分配到真正須要的 空間。

日期，時間類型

• DATETIME類型，可以保存1001-9999年，精度爲秒，與時區無關。
• TIMESTAMP類型，保存了從1970-01-01午夜到如今的秒數，只使用了4個字節，只能表示1970-2038年。TIMESTAMP依賴於時區。TIMESTAMP在默認狀況下，若是沒有指定列的值，會把列的值設置爲當前時間，在更新的時候也能夠更新列的值爲當前時間。

一般狀況下應該儘可能使用TIMESTAMP,由於它比DATETIME空間效率更高，有時候咱們會將Unix時間戳保存爲整數值以表示當前時間，實際上並不會帶來任何收益。

上面列舉了幾個經常使用的 mysql類型，在實際使用中能夠根據業務選擇最優的方案。通常狀況下遵循 更小的一般更好, 簡單就好 , 儘可能避免NULL是沒有問題的。

關於mysql的數據類型選擇，就寫到這裏。後面也會寫一些關於索引優化方面的文章，若是問題歡迎你們指出。