歡迎光臨
每天分享高質量文章

MySQL表設計踩過的坑!

來自公眾號:andyqian,作者:鞠騫

前言

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

utf8的鍋

場景 : 之前在給客戶做微商城時,需要儲存微信的授權信息,此時就有一個nickname欄位,在設計資料表時,潛意識的將表的儲存格式設置為utf8,生產上線一段時間後偶爾出現儲存異常。經分析,出現異常的原因是:用戶nickname中有email表情符號。utf8格式的資料表儲存不下導致。

經驗提示: 在設計資料表時,一定要註意該欄位儲存的內容,如果允許設置表情,則一定不能使用utf8,而是使用utf8mb4。

選擇合適的型別

  在資料庫表設計時,欄位的型別還真不好設計,這裡簡單說說:

  1. 儲存手機號的欄位,用varchar(20)就已經足夠了,就不應該設計為varchar(100),設置為varchar(100)只會消耗更多的儲存以及記憶體開銷,得不償失啊!

  2. 儲存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。

  • 選擇合適的資料型別。

  • 主外鍵欄位型別一定要一致,否則會造成隱式轉化,不走索引,造成生產事故!

  • 表以及欄位上添加合理的註釋。

  • 資料庫表設計時,一定要在外鍵欄位以及合適的欄位上加索引。

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


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

●輸入m獲取文章目錄

推薦↓↓↓

 

Linux學習

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

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

赞(0)

分享創造快樂