這些年MySQL表設計踩過的坑！
本文首發於個人微信公眾號《andyqian》,期待你的關注！
前言
有朋友在後臺留言。希望我能說說我在資料庫表設計時踩過的坑。那麼，我們今天就來聊聊我在資料庫表設計時踩過的坑，以及現在對資料庫表設計的一點建議。希望能夠幫助到你。
utf8的鍋
場景 : 之前在給客戶做微商城時，需要儲存微信的授權資訊，此時就有一個nickname欄位，在設計資料表時，潛意識的將表的儲存格式設定為utf8，生產上線一段時間後偶爾出現儲存異常。經分析，出現異常的原因是：使用者nickname中有email表情符號。utf8格式的資料表儲存不下導致。
經驗提示： 在設計資料表時，一定要注意該欄位儲存的內容，如果允許設定表情，則一定不能使用utf8，而是使用utf8mb4。
選擇合適的型別
在資料庫表設計時，欄位的型別還真不好設計，這裡簡單說說：
- 儲存手機號的欄位，用varchar(20)就已經足夠了，就不應該設計為varchar(100)，設定為varchar(100)只會消耗更多的儲存以及記憶體開銷，得不償失啊！
- 儲存Boolean型別，使用tinyint就夠了，而不需要設計為int，甚至bigint。
資料型別設計的過大,就會造成沒必要的浪費（磁碟，記憶體,CPU），最主要的是，這是一件費力不討好的事情。
主外來鍵欄位型別不一致
主外來鍵型別不一致，說起來，你可能會不相信，但在資料庫表設計時，稍不留神，就不一致，埋下隱式型別轉換的坑。如下:
使用者表:
create table t_base_user(
oid bigint(20) not null primary key auto_increment comment "主鍵", ....
)
注意此時的主鍵oid為bigint(20)。
使用者地址表：
create table t_base_user_address(
oid bigint(20) not null primary key auto_increment comment "主鍵",
user_id varchar(30) null comment "使用者id" ....
)
你看，此時在t_base_user_address表中的user_id外來鍵欄位,設計時的卻是varchar(30)。你可能覺得你不可能發生這樣的錯誤，說出來也不怕你笑話，我就踩過好幾次這樣的坑，到最後發現慢SQL了，才發現自己中了這樣的坑！！！
註釋
之前在資料庫表設計時，就沒有加註釋的習慣，造成的直接後果是：資料庫設計階段一過，後續資料表的使用中，欄位名就全靠猜了。我們寫程式碼是知道註釋是非常重要的，同樣在設計資料庫表時，註釋也非常重要！一定要記住加註釋，無論是表，還是欄位，索引，都必須加上註釋。
如:
create table t_base_user(
oid bigint(20) not null primary key auto_increment comment "主鍵", ....
)
已有表加註釋
alter table t_base_user modify oid bigint(20) not null primary key auto_increment comment "主鍵"；
加註釋時，還要注意的是：在一些需要計算的欄位上，需要加上計算規則文件的連結。方便後續查詢！
加索引
在之前的文章中也有說過，一個好的資料表設計，在一開始就應該考慮新增索引，這個階段新增索引成本不僅最低。而且還不給後續留下慢查詢，甚至生產事故的隱患！索引怎麼加，索引重不重要，可以檢視《寫會MySQL索引》一文進行檢視！唉，我就吃過不少沒加索引或忘記新增索引的虧，記憶猶新！！！
小結
以上是我資料庫設計表時躺過的坑，下面小結精簡版本一下:
- 允許儲存表情的表，儲存格式設計為utf8mb4，避免使用utf8。
- 選擇合適的資料型別。
- 主外來鍵欄位型別一定要一致，否則會造成隱式轉化，不走索引，造成生產事故！
- 表以及欄位上新增合理的註釋。
- 資料庫表設計時，一定要在外來鍵欄位以及合適的欄位上加索引。
上面是我資料庫表設計時，遇到踩過坑以後的經驗之談。有些坑當時還真花了不少時間來填補。記錄在這裡，如果能幫助到你，那就太好了！
最後: 祝大家週末愉快！
相關閱讀：
掃碼關注，一起進步
個人部落格: http://www.andyqian.com