MySQL表設計踩過的坑！-知識星球

來自公眾號：andyqian，作者：鞠騫

有朋友在後臺留言。希望我能說說我在資料庫表設計時踩過的坑。那麼，我們今天就來聊聊我在資料庫表設計時踩過的坑，以及現在對資料庫表設計的一點建議。希望能夠幫助到你。

場景 : 之前在給客戶做微商城時，需要儲存微信的授權資訊，此時就有一個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索引》一文進行檢視！唉，我就吃過不少沒加索引或忘記新增索引的虧，記憶猶新！！！

以上是我資料庫設計表時躺過的坑，下麵小結精簡版本一下:

上面是我資料庫表設計時，遇到踩過坑以後的經驗之談。有些坑當時還真花了不少時間來填補。記錄在這裡，如果能幫助到你，那就太好了！

●本文編號271，以後想閱讀這篇文章直接輸入271即可

●輸入m獲取文章目錄

推薦↓↓↓

Linux學習

更多推薦《18個技術類微信公眾號》

涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

MySQL表設計踩過的坑！