本文首發于個人微信公眾號《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。選擇合適的數據類型。主外鍵字段類型一定要一致，否則會造成隱式轉化，不走索引，造成生產事故！表以及字段上添加合理的注釋。數據庫表設計時，一定要在外鍵字段以及合適的字段上加索引。

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

最后: 祝大家周末愉快！

相關閱讀：

寫會MySQL索引

讀懂MySQL執行計劃

談談MySQL隱式類型轉換

MySQL之事務初識

掃碼關注，一起進步

個人博客:?http://www.andyqian.com

總結

以上是生活随笔為你收集整理的mysql 优惠卷表设计_这些年MySQL表设计踩过的坑！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。