MySQL表設計時踩過的坑！
前言
有朋友在后臺留言。希望我能說說我在數據庫表設計時踩過的坑。那么，我們今天就來聊聊我在數據庫表設計時踩過的坑，以及現在對數據庫表設計的一點建議。希望能夠幫助到你。
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。
- 選擇合適的數據類型。
- 主外鍵字段類型一定要一致，否則會造成隱式轉化，不走索引，造成生產事故！
- 表以及字段上添加合理的注釋。
- 數據庫表設計時，一定要在外鍵字段以及合適的字段上加索引。
上面是我數據庫表設計時，遇到踩過坑以后的經驗之談。有些坑當時還真花了不少時間來填補。記錄在這里，如果能幫助到你，那就太好了！
